为何Kubernetes会OOM Kill Pause容器？GKE集群异常咨询

首先咱们得明确一个核心规则：Guaranteed QoS等级的Pod里，所有容器（包括pause基础设施容器）的OOM score adj都应该被kubelet设置为-998——这是Kubernetes的标准行为，目的是让这类高优先级Pod在OOM场景下被优先保护。但你遇到的pause容器OOM score为0并被杀死的情况，大概率是以下几个原因导致的：

1. Kubernetes 1.12.7版本的已知Bug #

你使用的1.12.7是一个非常老旧的版本（早已停止官方支持），这个版本的kubelet存在关于pause容器OOM score配置的遗漏问题。在部分资源配置场景下，kubelet会跳过对pause容器的OOM score adj设置，导致pause容器继承了Linux进程的默认OOM score值（0）。这类问题在后续的1.13+版本中已经被官方修复。

2. 节点内存彻底耗尽的极端场景 #

当节点内存被完全榨干时，内核的OOM killer会绕过kubelet设置的规则。此时kubelet本身可能因为内存不足已经无法正常运行，完全失去对OOM决策的干预能力。内核会优先选择占用内存极小的进程（比如仅占4kB RSS的pause容器）进行杀死，以此快速释放少量内存，让系统恢复基本运行能力。

3. cgroup配置异常 #

如果节点的cgroup层级出现损坏，或者kubelet在创建Pod的cgroup时发生异常，可能导致pause容器的/proc/<pid>/oom_score_adj文件没有被正确写入-998的值。你可以在发生OOM的节点上执行以下命令验证：

cat /proc/605624/oom_score_adj

如果输出是0而非-998，就说明kubelet的配置没有生效。

建议的解决步骤 #

• 优先升级Kubernetes版本：升级到1.13及以上的稳定版本（推荐1.16+的长期支持版本），直接修复老版本kubelet的已知Bug。
• 验证节点内存状态：通过Datadog等监控工具查看OOM事件发生时的节点内存使用率，确认是否是节点内存彻底耗尽导致的极端情况。如果是，需要调整Pod的资源请求/限制，或者扩容节点内存。
• 检查kubelet日志：查看节点上kubelet的日志，搜索是否有关于pause容器配置的错误信息（比如无法写入OOM score adj的报错），帮你定位具体的配置异常原因。

内容的提问来源于stack exchange，提问作者Matt