如何配置Kubernetes防止Job发生OOM时被反复重启

backoffLimit参数的准确计数规则 #

backoffLimit统计的是初始运行失败后允许的额外重试次数，不包含任务的首次初始运行。网传“设置backoffLimit为1即可实现首次失败不重试”的说法是错误的，对应计数逻辑如下：

• backoffLimit: 0：初始运行失败后不允许任何重试，总运行次数为1
• backoffLimit: 1：初始运行失败后允许1次额外重试，总运行次数为2
• backoffLimit: N：初始运行失败后允许N次额外重试，总运行次数为N+1

当前配置restartPolicy: Never + backoffLimit: 0仍出现OOM后反复重试的问题，不是参数含义理解错误，是默认配置存在场景适配问题：

• 1.26之前版本K8s的Job默认podReplacementPolicy为TerminatingOrFailed，会在Pod还未完成终止流程（比如OOM后容器清理、节点状态上报延迟）时提前创建新Pod，这部分提前创建的Pod不会被计入backoffLimit计数，导致重试次数超限
• 1.24及更早版本存在OOM退出事件的计数漏算bug，kubelet上报的OOMKill终止原因没有被Job控制器正确识别为失败，不会扣减重试额度

满足需求的正确配置 #

不需要放弃Job资源，按如下配置即可实现“确定性失败（比如固定内存占用触发OOM）后直接标记Job为Failed状态、不再重试，同时保留节点故障时自动调度到其他节点恢复的能力”：

apiVersion: batch/v1
kind: Job
spec:
  backoffLimit: 0
  # 1.26及以上版本必须配置，仅在Pod确认进入终态后才判断是否创建新Pod，从根源避免计数漏算
  podReplacementPolicy: Failed
  # 兜底配置，设置为比任务正常最长运行时间多20%左右的秒数，极端场景下超时后直接标记Job失败
  activeDeadlineSeconds: 3600
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: task-container
        # 其余业务容器配置、资源限制按实际需求填写

配置生效后，触发OOM这类确定性失败时，Job会直接进入Failed状态保留现场，不会再自动创建重试Pod，可后续按需调整内存限制新建Job，或者删除现有失败Job。如果遇到工作节点宕机的场景，Job控制器会等待节点状态确认、原Pod判定为失联终止后，自动在健康节点重新创建Pod运行任务，满足故障自愈需求。

不建议替换为普通Pod的原因 #

不要改用普通Pod实现该需求：普通Pod的生命周期与所在节点强绑定，一旦节点发生宕机，普通Pod会长期停留在Unknown/Terminating状态，不会被自动调度到其他健康节点重启，完全无法满足节点故障下任务自动恢复的要求。

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