Kubernetes OOMKilled 与多个容器答案

【问题标题】：Kubernetes OOMKilled with multiple containersKubernetes OOMKilled 与多个容器
【发布时间】：2022-02-23 16:55:08
【问题描述】：

我在 Kubernetes 集群 (AWS EKS) 中运行我的服务。最近，我在吊舱中添加了一个新容器（边车）。之后，我开始观察OOMKilled，但指标没有显示任何高内存使用情况。这是配置：

Containers:
  side-car:
    Container ID:   ...
    Image:          ...
    ...
    State:          Running
      Started:      Mon, 21 Feb 2022 09:11:07 +0100
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Thu, 17 Feb 2022 18:36:28 +0100
      Finished:     Mon, 21 Feb 2022 09:11:06 +0100
    Ready:          True
    Restart Count:  1
    Limits:
      cpu:     1
      memory:  2Gi
    Requests:
      cpu:        1
      memory:     2Gi
    ...
    ...
  my-service:
    Container ID:   ...
    ...
    ...
    ...

    State:          Running
      Started:      Thu, 17 Feb 2022 18:36:28 +0100
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     3
      memory:  3Gi
    Requests:
      cpu:      2
      memory:   3Gi

边车和我的服务都设置了内存限制（和请求）。在OOMKilled 期间，没有一个容器使用超过请求/限制的内存。例如。在一种情况下，边车使用 20MiB，我的服务：800MiB，远低于限制。 Kubernetes 仍然重新启动了容器（边车）。只是为了记录，在添加边车之前，我的服务运行没有问题，没有观察到OOMKilled。

【问题讨论】：

标签： kubernetes containers

【解决方案1】：

也许您的 Sidecar 容器确实存在一些您无法发现的性能问题，并且在某些时候它确实请求超过限制？

查看OOM kill due to container limit reached

   State:          Running
      Started:      Thu, 10 Oct 2019 11:14:13 +0200
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137

退出代码 137 很重要，因为它意味着系统终止容器，因为它试图使用比它更多的内存限制。

为了监控这一点，您必须始终查看内存的使用情况与极限相比。一个 pod 使用的节点内存的百分比是通常是一个不好的指标，因为它没有说明与限制内存使用是。在 Kubernetes 中，限制适用于容器，而不是 pod，因此监控容器与容器的内存使用情况。该容器的限制。

【讨论】：

【解决方案2】：

您很可能看不到内存使用量何时超过限制，因为通常以定义的时间间隔提取指标（cAdvisor，目前是事实上的source for metrics，仅每 10 次刷新一次数据-15 秒默认）。

如何进一步排除故障？连接到运行 sidecar 容器的相应节点并查看内核日志。您可以使用tail /var/log/syslog -f | grep -i kernel（this movie 中有一个示例）。您应该会看到如下两行，这将表明容器的 cgroup 限制被违反的后果，并且相应的进程终止：

Jan 16 21:33:51 aks-agentpool-20086390-vmss00003K kernel: [ 8334.895437] Memory cgroup out of memory: Killed process 14300 (dotnet) total-vm:172050596kB, anon-rss:148368kB, file-rss:25056kB, shmem-rss:0kB, UID:0 pgtables:568kB oom_score_adj:-997
Jan 16 21:33:51 aks-agentpool-20086390-vmss00003K kernel: [ 8334.906653] oom_reaper: reaped process 14300 (dotnet), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

特别注意 anon-rss 和 file-rss 值，并将它们的总和与您为 sidecar 容器设置的限制进行比较。

如果您可以控制在 sidecar 容器中运行的代码，那么您可以添加一些检测代码来以足够小的间隔打印出使用的内存量，然后简单地将其输出到控制台。一旦容器被 OOMKilled，您仍然可以访问日志以查看发生了什么（使用 --previous 标志和 kubectl logs 命令）。请查看this answer 了解更多信息。

仅出于完整性考虑：您的系统可能会在内存上运行得如此低，以至于以某种方式调用 OOM 杀手并选择终止您的 sidecar 容器（描述了这种情况here）。不过，在您的情况下，这极不可能，因为据我了解，您会反复终止 sidecar 容器，这很可能仅表明该容器存在问题。

【讨论】：