Kubernetes中Pod与Container触发OOMKilled的场景及疑问

为什么单个容器超内存限制时，Pod 会被杀死而非仅该容器？ #

首先明确：Kubernetes 的内存限制是容器级的，Pod 的“总内存限制”只是各容器限制的总和，仅用于节点调度时判断资源是否足够，并非直接的 Pod 级强制限制。

正常情况下，容器超自身内存限制只会被单独 OOMKilled，但出现 Pod 被杀死的情况，通常是以下两种场景：

• 节点级 OOM 触发：当节点整体内存耗尽时，kubelet 会启动 OOM 评分机制（基于oom_score_adj），按 Pod 优先级、资源请求/使用情况打分，得分高的 Pod 会被优先终止。哪怕只是单个容器超内存引发节点内存不足，也可能让整个 Pod 被选中。
• Pod 重启策略与容器依赖：如果 Pod 内容器是紧密耦合的（比如共享 PID 命名空间，或主容器依赖辅助容器），某个容器被 OOM 终止后，Pod 的重启策略（默认Always）可能触发整个 Pod 重启，而非仅单个容器。另外，如果容器终止导致 livenessProbe 检测失败且超过阈值，也会触发 Pod 重启。

单容器 Burstable Pod 交替重启的原因 #

Burstable QoS 类 Pod 的特点是内存请求（requests）小于限制（limits），节点允许它使用超出请求的内存，但节点内存紧张时，这类 Pod 是优先回收对象。

你观察到的“容器先重启，每第二次 Pod 被杀死重启”现象，本质是 kubelet 的容器重启次数阈值与 Pod 重启机制共同作用的结果：

1. 第一次超内存：容器触发 OOMKilled，kubelet 按 Pod 重启策略尝试重启单个容器，此时 Pod 未终止，重启计数仅针对容器。
2. 第二次超内存：短时间内容器重启次数达到 kubelet 阈值（默认10分钟内5次），kubelet 判断该容器无法正常启动，就会终止整个 Pod 并重新创建，此时 Pod 的重启计数增加。

另外，Burstable Pod 的 OOM 评分更高，第二次超内存时如果节点内存刚好紧张，可能直接触发节点级 OOM 回收，杀死整个 Pod。

Pod 被 OOM 杀死的实际场景 #

• 节点内存耗尽：节点上所有 Pod 总内存超节点可用内存，kubelet 按 OOM 评分杀死优先级低、资源超请求多的 Pod，Burstable 类优先级低于 Guaranteed 类。
• 容器超内存引发节点级 OOM：单个容器超内存占用大量节点内存，导致节点整体内存不足，触发节点 OOM 回收，整个 Pod 被选中杀死。
• 容器重启次数超限：短时间内容器多次因 OOM 重启，达到 kubelet 重启次数限制，触发 Pod 级重启（杀死原 Pod 并新建）。
• 第三方资源约束触发：如果使用了垂直Pod自动扩缩容（VPA）等工具配置了Pod级资源约束，特定条件下也可能触发Pod被OOM杀死。

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