Pod因超出内存限制被OOMKilled后，Kubernetes的调度与恢复机制？

一、OOMKilled后的调度逻辑 #

Pod被Linux内核标记为OOMKilled后，是否重启、调度到哪个节点，核心由Pod重启策略（restartPolicy）和所属控制器类型决定：

• 若Pod由Deployment、StatefulSet、DaemonSet这类控制器管理：
  • 当restartPolicy为Always（默认）或OnFailure时，控制器会尝试重启Pod。重启的Pod优先调度到原节点（只要节点能满足requests资源要求，且无污点、亲和性限制）；若原节点资源不足或无法调度，才会转向其他符合条件的节点。
  • 若restartPolicy设为Never，Pod会直接终止，不会触发重启。
• 若为无控制器管理的独立Pod：
  • 同样遵循restartPolicy，但没有控制器兜底，终止后不会被重新创建。

二、测试中未出现新Pod的原因 #

你在AKS集群中未观察到新Pod，大概率是以下情况之一：

1. 重启策略限制：Pod的restartPolicy被设置为Never，或者控制器配置了不重启OOM终止的容器。
2. 退避机制触发：Kubernetes对频繁崩溃的Pod会启动CrashLoopBackOff退避策略，重启间隔会逐步拉长（10s→20s→40s…直到上限），你可能在间隔周期内没看到新Pod启动。
3. 集群资源不足：原节点无法满足Pod的requests资源要求，且集群内其他节点也无可用资源，导致Pod处于Pending状态，未被你注意到。
4. 控制器副本配置：比如Deployment的replicas设为1时，控制器会尝试重启现有Pod实例，而非创建新副本；若重启后容器再次OOM，就会持续处于CrashLoopBackOff状态，不会生成新Pod。

三、你的资源配置说明 #

你提供的资源限制配置：

resources:
  requests:
    memory: "64Mi"
    cpu: "0.1"
  limits:
    memory: "128Mi"
    cpu: "0.3"

其中memory: 128Mi是内存硬限制，当Pod内存占用超过该值时，Linux内核会直接触发OOM Killer终止Pod进程，无缓冲阶段。而CrashLoopBackOff是Pod被终止后，控制器尝试重启但容器再次快速崩溃（比如重启后立刻再次OOM）时，才会进入的状态。

四、核心恢复机制总结 #

Kubernetes针对OOMKilled Pod的恢复逻辑：

• 控制器管理的Pod，按restartPolicy尝试重启，优先原节点调度，失败则转向其他节点。
• 触发CrashLoopBackOff后，通过逐步拉长重启间隔，避免频繁占用集群资源。
• 若Pod无法被调度（资源不足、节点污点等），会处于Pending状态，直到有合适节点可用。
• 独立Pod或restartPolicy: Never的Pod，OOMKilled后直接终止，无自动恢复逻辑。

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