Kubernetes OOM 查杀 pod答案

【问题标题】：Kubernetes OOM killing podKubernetes OOM 查杀 pod
【发布时间】：2021-05-14 20:17:32
【问题描述】：

我有一个简单的容器，它由安装在 Alpine 上的 OpenLDAP 组成。它安装为以非 root 用户身份运行。我可以使用本地 Docker 引擎毫无问题地运行容器。然而，当我将它部署到我们的 Kubernetes 系统时，它几乎立即被杀死，因为 OOMKilled。我试过增加内存而不做任何改变。我还查看了 pod 的内存使用情况，没有发现任何异常情况。

服务器以slapd -d debug -h ldap://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 没有在仪表板 (Lens) 上显示内存问题。我们还有其他没有此问题的 Alpine 图像。

我对 Kubernetes 比较陌生，所以我希望 SO 上的用户能给我一些关于如何调试它的指导。一旦我知道什么是有用的，我可以提供更多信息。正如我提到的，增加内存没有影响。我计划从“突发”部署切换到“保证”部署，看看这是否会有所不同。

===== 更新 - 正在工作 =====

我相信我混淆了资源“限制”与“请求”的含义。在发布原始帖子之前，我一直在尝试对这些进行多种变体。阅读完回复后，我现在使用以下设置部署了 pod：

  resources:
    limits:
      cpu: 50m
      memory: 1Gi
    requests:
      cpu: 50m
      memory: 250Mi

查看 Lens 中的内存占用情况，它的使用率稳定在 715Mi 左右。这比我们的其他 pod 至少高出 25%。也许 LDAP 服务器只是需要更多。无论如何，我感谢大家的及时帮助。

【问题讨论】：

感谢您提供有关此主题的出色参考资料。我现在有这个工作，看起来（他羞怯地说）只不过是需要更大内存占用的 pod。我将使用当前设置更新原始帖子。

标签： kubernetes cgroups

【解决方案1】：

检查您的部署或 pod 规范以了解资源限制。

如果您的应用程序需要的内存超出了允许的范围，它将被 kubernetes OOMKilled。

...
resources:
  limits:
    memory: 200Mi
  requests:
    memory: 100Mi
...

等效的 JAVA JVM 标志以更好地理解此概念

请求 = Xms

限制 = Xmx

https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

【讨论】：

【解决方案2】：

我希望 SO 上的用户能给我一些关于如何调试的指导。

在开始调试之前，您可以检查（并改进）您的 yaml 文件。 您可以为容器like this设置默认内存请求和默认内存限制：

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
spec:
  limits:
  - default:
      memory: 512Mi
    defaultRequest:
      memory: 256Mi
    type: Container

请求是对您的容器所需资源的最低数量的出价。它并没有说你将使用多少资源，只是说你需要多少。你告诉调度器你的容器需要多少资源来完成它的工作。请求用于 Kubernetes 调度程序的调度。对于 CPU 请求，它们还用于配置 Linux 内核如何调度容器。

limit 是您的容器将使用的资源的最大数量。限制必须大于或等于请求。如果只设置限制，请求将与限制相同。

如果你想在pod里放一个容器，可以设置内存限制like this：

apiVersion: v1
kind: Pod
metadata:
 name: default-mem-demo-2
spec:
 containers:
 - name: default-mem-demo-2-ctr
   image: nginx
   resources:
     limits:
       memory: "1Gi"

如果您指定了 Container 的限制，但没有指定它的请求 - 不会为 Container 分配默认的内存请求值（在这种情况下为 256Mi）。

你也可以在pod里放一个容器，设置内存请求like this：

apiVersion: v1
kind: Pod
metadata:
  name: default-mem-demo-3
spec:
  containers:
  - name: default-mem-demo-3-ctr
    image: nginx
    resources:
      requests:
        memory: "128Mi"

但在这种情况下，Container 的内存限制设置为 512Mi，这是命名空间的默认内存限制。

如果你想调试一个问题，你应该知道它发生的原因。通常OOM可能会出现问题，例如由于限制过度使用或达到容器限制（我知道您有 1 个容器，但您应该知道在其他情况下如何进行）。你可以阅读关于它的好文章here。

您可能会发现运行集群监控是个好主意，例如使用Prometheus。这是guide 如何使用 Prometheus 设置 Kubernetes 监控。您应该对指标container_memory_failcnt 感兴趣。你可以阅读更多关于它here。

您还可以阅读this page 了解在 Kubernetes 集群中设置 oomkill-alerting。

【讨论】：