即使未达到Pod限制，Pod内部的进程也会被OOMKilled

2024-05-04 • 问答

我们是整个Kubernetes领域的新成员，但到目前为止，GKE中有许多服务正在运行。今天，我们看到了一些奇怪的行为，尽管pod本身具有足够的可用资源，并且没有达到其极限，但其中一个pod内运行的进程之一被杀死了。

限制的定义如下：

resources:
  requests:
    cpu: 100m
    memory: 500Mi
  limits:
    cpu: 1000m
    memory: 1500Mi

在吊舱内部，正在运行Celery（Python），而这一特定任务正在消耗一些运行时间较长的任务。

在执行一项任务期间，芹菜过程突然被杀死，这似乎是由OOM引起的。 GKE群集操作日志显示以下内容：

Memory cgroup out of memory: Kill process 613560 (celery) score 1959 or sacrifice child
Killed process 613560 (celery) total-vm:1764532kB,anon-rss:1481176kB,file-rss:13436kB,shmem-rss:0kB

该时间段的资源图如下所示：

可以清楚地看到，CPU或内存使用率均未接近pod定义的限制，因此我们对为何发生任何OOMKilling感到困惑。进程本身被杀死，而不是实际的pod，也感到困惑吗？

这个特定的OOM是否确实在操作系统内部而不是Kubernetes中发生？如果是这样，是否有解决此特定问题的解决方案？

关于您的陈述：

进程本身被杀死，这一事实也令人感到困惑。不是实际的Pod？

计算资源（CPU /内存）是为容器而不是Pod配置的。

如果Pod 容器被OOM杀死，则this CSS Tricks article。基础容器由kubelet根据其容器the Pod is not evicted重新启动。 Pod仍将存在于同一节点上，并且Restart Count将递增（除非您使用RestartPolicy: Never，这不是您的情况）。

如果在吊舱上执行kubectl describe，则新生成的容器将处于Running状态，但是您可以在Last State中找到上一次重启的原因。另外，RestartPolicy重启了多少次：

State:          Running
  Started:      Wed,27 Feb 2019 10:29:09 +0000
Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137
  Started:      Wed,27 Feb 2019 06:27:39 +0000
  Finished:     Wed,27 Feb 2019 10:29:08 +0000
Restart Count:  5

资源图可视化可能与内存的实际使用有所不同。由于它使用1 min interval (mean)采样，因此如果您的内存突然增加超过上限，可以在您的平均内存使用率在图中绘制为高峰值之前重新启动容器。如果您的Python容器使用的内存短暂/间断，则即使这些值不在图中，也很容易重新启动。

使用kubectl top，您可以查看为Pod注册的最新内存使用情况。尽管可以更精确地看到特定时间点的内存使用情况，但请记住，它是从metrics-server获取具有you can check的值的：

从Kubelets抓取指标的间隔（默认值到60s）。

如果您的容器使用了“尖峰”式的内存，您可能仍会看到它正在重新启动，甚至没有看到kubectl top上的内存使用情况。

即使未达到Pod限制，Pod内部的进程也会被OOMKilled

qiaoqinag 回答：即使未达到Pod限制，Pod内部的进程也会被OOMKilled

大家都在问