库伯内特斯OOM杀人舱
我有一个简单的容器，它由安装在阿尔卑斯山上的OpenLDAP组成。它被安装为以非root用户身份运行。我能够使用我的本地Docker引擎运行容器而没有任何问题。但是，当我将其部署到我们的库伯内特斯系统时，它几乎立即被OOMKill杀死。我尝试在没有任何更改的情况下增加内存。我还查看了pod的内存使用情况，没有发现任何异常。
服务器启动为slapd-d debug-hldap://0.0.0.0:1389/-u 1000-g 1000，其中1000分别是uid和gid。
节点跟踪显示此输出：
May 13 15:33:44 pu1axb-arcctl00 kernel: Task in /kubepods/burstable/podbac2e0ae-9e9c-420e-be4e-c5941a2d562f/7d71b550e2d37e5d8d78c73ba8c7ab5f7895d9c2473adf4443675b9872fb84a4 killed as a result of limit of /kubepods/burstable/podbac2e0ae-9e9c-420e-be4e-c5941a2d562f
May 13 15:33:44 pu1axb-arcctl00 kernel: memory: usage 512000kB, limit 512000kB, failcnt 71
May 13 15:33:44 pu1axb-arcctl00 kernel: memory+swap: usage 0kB, limit 9007199254740988kB, failcnt 0
May 13 15:33:44 pu1axb-arcctl00 kernel: kmem: usage 7892kB, limit 9007199254740988kB, failcnt 0
May 13 15:33:44 pu1axb-arcctl00 kernel: Memory cgroup stats for /kubepods/burstable/podbac2e0ae-9e9c-420e-be4e-c5941a2d562f: cache:0KB rss:0KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:
May 13 15:33:44 pu1axb-arcctl00 kernel: Memory cgroup stats for /kubepods/burstable/podbac2e0ae-9e9c-420e-be4e-c5941a2d562f/db65b4f82efd556a780db6eb2c3ddf4b594774e4e5f523a8ddb178fd3256bdda: cache:0KB rss:44KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB inactive_anon:
May 13 15:33:44 pu1axb-arcctl00 kernel: Memory cgroup stats for /kubepods/burstable/podbac2e0ae-9e9c-420e-be4e-c5941a2d562f/59f908d8492f3783da587beda7205c3db5ee78f0744d8cb49b0491bcbb95c4c7: cache:0KB rss:0KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB inactive_anon:0
May 13 15:33:44 pu1axb-arcctl00 kernel: Memory cgroup stats for /kubepods/burstable/podbac2e0ae-9e9c-420e-be4e-c5941a2d562f/7d71b550e2d37e5d8d78c73ba8c7ab5f7895d9c2473adf4443675b9872fb84a4: cache:4KB rss:504060KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB inactive_a
May 13 15:33:44 pu1axb-arcctl00 kernel: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
May 13 15:33:44 pu1axb-arcctl00 kernel: [69022] 0 69022 242 1 28672 0 -998 pause
May 13 15:33:44 pu1axb-arcctl00 kernel: [69436] 1000 69436 591 454 45056 0 969 docker-entrypoi
May 13 15:33:44 pu1axb-arcctl00 kernel: [69970] 1000 69970 401 2 45056 0 969 nc
May 13 15:33:44 pu1axb-arcctl00 kernel: [75537] 1000 75537 399 242 36864 0 969 sh
May 13 15:33:44 pu1axb-arcctl00 kernel: [75544] 1000 75544 648 577 45056 0 969 bash
May 13 15:33:44 pu1axb-arcctl00 kernel: [75966] 1000 75966 196457 126841 1069056 0 969 slapd
May 13 15:33:44 pu1axb-arcctl00 kernel: Memory cgroup out of memory: Kill process 75966 (slapd) score 1961 or sacrifice child
May 13 15:33:44 pu1axb-arcctl00 kernel: Killed process 75966 (slapd) total-vm:785828kB, anon-rss:503016kB, file-rss:4348kB, shmem-rss:0kB
我很难相信它真的在运行内存溢出。这是一个简单的LDAP容器，目录树中只有8-10个元素，并且pod在仪表板（镜头）上没有显示内存问题。我们有其他没有这个问题的阿尔卑斯山图像。
我对库伯内特斯相对来说是个新手，所以我希望SO上的用户能给我一些关于如何调试的指导。一旦我知道什么是有帮助的，我可以提供更多信息。正如我提到的，增加内存没有影响。我计划从“突发”切换到“保证”部署，看看这是否有所不同。
======更新-正在工作=====
我相信我混淆了资源“限制”和“请求”的含义。在发表原始帖子之前，我一直在尝试这些变化。通读回复后，我现在部署了具有以下设置的pod：
resources:
limits:
cpu: 50m
memory: 1Gi
requests:
cpu: 50m
memory: 250Mi
从镜头中的内存占用来看，它的使用率保持在715Mi左右。这比我们的其他豆荚高出至少25%。也许LDAP服务器只需要更多。无论如何，我感谢你们所有人的及时帮助。
共有2个答案
我希望SO上的用户可以给我一些关于如何调试的指导。
在开始调试之前，您可以检查（并改进）yaml文件。您可以为以下容器设置默认内存请求和默认内存限制：
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
请求是对容器所需资源的最低数量的出价。它并没有说你将使用多少资源，只是说你需要多少资源。您正在告诉调度器您的容器需要多少资源来完成其工作。请求由Kubernetes调度器用于调度。对于CPU请求，它们还用于配置Linux内核如何调度容器。
限制是容器将使用的最大资源量。限制必须大于或等于请求。如果仅设置限制，则请求将与限制相同。
如果要在pod中放置一个容器，可以如下设置内存限制：
apiVersion: v1
kind: Pod
metadata:
name: default-mem-demo-2
spec:
containers:
- name: default-mem-demo-2-ctr
image: nginx
resources:
limits:
memory: "1Gi"
如果您指定了容器的限制，但没有指定其请求-容器将不会分配默认内存请求值（在这种情况下为256Mi）。
您还可以在pod中放置一个容器，并按如下方式设置内存请求：
apiVersion: v1
kind: Pod
metadata:
name: default-mem-demo-3
spec:
containers:
- name: default-mem-demo-3-ctr
image: nginx
resources:
requests:
memory: "128Mi"
但是在这种情况下，容器的内存限制设置为512Mi，这是名称空间的默认内存限制。
如果你想调试一个问题，你应该知道它为什么会发生。通常情况下，可能会出现问题，例如，由于限制过多或达到了容器限制（我知道您有1个容器，但您应该知道在其他情况下如何继续）。你可以在这里读到关于它的好文章。
您可能会发现使用Prometheus运行集群监控是一个好主意。以下是如何使用普罗米修斯设置Kubernetes监控的指南。您应该对metriccontainer\u memory\u failcnt感兴趣。你可以在这里了解更多。
您还可以阅读有关在Kubernetes集群中设置oomkill警报的页面。
检查您的部署或pod规范以了解资源限制。
如果您的应用程序需要比允许的更多的内存，它将被kubernetes OOMKill。
...
resources:
limits:
memory: 200Mi
requests:
memory: 100Mi
...
等效的JAVA JVM标志，以更好地理解此概念
请求=Xms
极限=Xmx
阅读更多：
https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/
https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
-
我假设没有愚蠢的问题，所以这里有一个我找不到直接答案的问题。 现在的情况 我目前有一个运行1.15的Kubernetes集群。AKS上的x，通过Terraform部署和管理。AKS最近宣布Azure将在AKS上停用Kubernetes的1.15版本，我需要将集群升级到1.16或更高版本。现在，据我所知，直接在Azure中升级集群不会对集群的内容产生任何影响，即节点、豆荚、秘密和当前在那里的所有其他
-
我在Kubernetes是个新手。我想知道在kubernetes环境中最好的生产部署场景是什么。 在过去的学派中，我习惯于将Web服务器（例如Nginx或Apache）放在DMZ层，而将其放在其他层（我们称之为层）。这样，只有web服务器在DMZ上，恶意攻击只能在web服务器VM上进行。 据我所知，K8S部署不再需要这种方法；这是因为K8S自己处理网络、吊舱和流量。所以我在考虑最确定的部署方案。
-
据我所知，作业对象应该在一定时间后收获豆荚。但是在我的GKE集群（库伯内特斯1.1.8）上，“kubectl get pods-a”似乎可以列出几天前的豆荚。 所有这些都是使用乔布斯API创建的。 我确实注意到在使用 kubectl 删除作业后，pod 也被删除了。 我在这里主要担心的是，我将在批量作业中在集群上运行成千上万个pod，并且不想让内部待办系统过载。
-
我试图设置Kubernetes入口，将外部http流量路由到前端pod（路径/）和后端pod（路径/rest/*），但我总是得到400错误，而不是主nginx索引。html。 所以我在第https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer页尝试了谷歌库伯内特斯的例子，但我总是得到400个错误。有什么想法吗？
-
我是Kubernetes的新手，他们的概念我不太清楚：云提供商。 我已经使用RKE（Rancher引擎）安装了我的库伯内特斯集群。 我的集群设置在rancher2的顶部。 我的节点是托管OVH服务器的虚拟机。 我设法让运行中的应用程序具有L7入口和ClusterIP服务，但每次我尝试使用L4负载平衡器时，负载平衡器都处于挂起状态。根据https://github.com/rancher/ranch
-
我已经在Kubernetes上部署了Prometheus，并提供了配置文件作为配置映射资源。该文件作为卷装入普罗米修斯吊舱中。 在集群中更改配置映射后，我用一个空POST请求点击Prometheus服务器endpoint，以便重新加载它（如文档中所述） 然而，当我对配置映射进行更改并重新部署它时，我会经历大约30秒的“滞后”，直到prometheus.yml文件在pod中更新。 我在这里读到，这是