云原生 Job 失败重试 怎样处理

云原生 Job 失败后“会不会自动重试”，答案取决于失败发生在容器、Pod 还是 Job 这一层。生产环境最容易误判的是：restartPolicy: OnFailure 先在同一个 Pod 内重启容器；Pod 终止后，Job controller 才可能创建新 Pod；当失败次数达到 backoffLimit 或总时长达到 activeDeadlineSeconds，Job 会进入失败终态，不会自己变回运行中。

官方地址：https://kubernetes.io/docs/concepts/workloads/controllers/job/

因此，稳定的处理方式不是盲目把重试次数调大，而是先划清三层边界，再决定哪些错误值得重试、最多重试多久，以及失败后保留什么日志。

先判断失败发生在哪一层

可以把一次 Job 任务拆成三层看：

• 容器层：restartPolicy: OnFailure 允许 kubelet 在同一个 Pod 中重新启动失败容器。
• Pod 层：restartPolicy: Never 时，Pod 失败后由 Job controller 创建新的 Pod，失败 Pod 会计入 Job 的重试计数。
• Job 层：达到失败上限或时间上限后，Job 标记为 Failed；这不是新的自动 Job，也不会因为修改了配置而自动恢复。

排查时不要只看 kubectl get job 的一行状态。先看 Pod 是否反复出现，再看容器重启次数和退出码，最后对照 Job 的 status.failed、conditions 与事件。这样才能判断是应用短暂退出，还是配置错误一直被重新提交。

用 backoffLimit 控制普通失败重试

普通 Job 可以从一个明确的失败上限开始。下面的示例让任务最多累计 3 次失败，并限制单次 Job 的总运行时间。restartPolicy: Never 便于保留每个失败 Pod 的日志，也便于区分每次尝试。

apiVersion: batch/v1
kind: Job
metadata:
  name: report-export
spec:
  # 失败 Pod 累计达到 3 次后，Job 进入 Failed
  backoffLimit: 3
  # 超过 15 分钟仍未完成，停止继续创建重试 Pod
  activeDeadlineSeconds: 900
  template:
    spec:
      # 调试阶段保留失败 Pod，便于查看退出码和日志
      restartPolicy: Never
      containers:
        - name: exporter
          image: example/report-export:1.0
          command: ["/app/export"]

backoffLimit 不是“每个 Pod 都重试 3 次”的意思，而是 Job 级别的失败计数上限。Kubernetes 会使用指数退避创建失败 Pod，等待时间从 10 秒、20 秒、40 秒增长，最长封顶 6 分钟；默认的 backoffLimit 是 6。对外部接口或数据库有瞬时抖动的任务，可以留出有限重试；对参数错误、文件格式错误这类确定性失败，则不应无限加大上限。

还要注意 OnFailure 的计数方式：同一 Pod 中容器的重启也会参与失败判断。调试期间使用 Never 通常更容易保留现场；任务本身必须能安全地重复执行，避免第二次运行重复写入或覆盖不完整结果。

用总时限和故障策略划出生产边界

只有重试次数还不够。某次任务可能一直处于运行状态，或者连续重试的等待时间已经超过业务窗口，此时要用 activeDeadlineSeconds 给整个 Job 加总时限。它优先于 backoffLimit：时间到了，即使失败次数还没用完，也会停止继续重试。

如果不同退出码代表不同故障，可以使用 podFailurePolicy。例如退出码 42 表示程序配置错误，直接结束 Job；节点抢占等中断则忽略计数，让 Job 创建替代 Pod：

spec:
  # 失败 Pod 的默认累计上限
  backoffLimit: 4
  template:
    spec:
      # Pod failure policy 要求使用 Never
      restartPolicy: Never
      containers:
        - name: worker
          image: example/batch-worker:2.1
          command: ["/app/worker"]
  podFailurePolicy:
    rules:
      - action: FailJob
        onExitCodes:
          # 42 表示确定性的配置错误，不再浪费重试资源
          containerName: worker
          operator: In
          values: [42]
      - action: Ignore
        onPodConditions:
          # 节点中断不消耗 backoffLimit
          - type: DisruptionTarget

规则按顺序匹配，命中后不会继续检查后面的规则。FailJob 适合不可重试的逻辑错误，Ignore 适合不应消耗重试额度的中断，未命中时才按默认失败计数处理。这里的“忽略”不是让错误消失，而是让控制器重新安排 Pod，同时把真正的应用错误与基础设施扰动分开。

发布前检查状态、事件和日志

配置完成后，建议按同一个 Job 名称检查四类信息。命令只用于查看状态，不要用删除重建来代替原因分析：

# 先看 Job 的完成数、失败数和终态条件
kubectl get job report-export -o wide

# 查看控制器记录的失败原因和时间上限信息
kubectl describe job report-export

# 找出本次 Job 产生的全部 Pod，观察是否出现多个失败尝试
kubectl get pods -l job-name=report-export -o wide

# 查看某个失败 Pod 的容器退出原因；替换成实际 Pod 名称
kubectl describe pod 

# 保留失败现场后再读取应用日志
kubectl logs  -c exporter

看到多个失败 Pod 不一定代表配置失效，可能只是任务正在按退避重试；看到一个 Pod 的 RESTARTS 增长，也不等于 Job 已经创建了新的 Pod。最终要以 Job 的 Failed 或 Complete 条件为准，并结合事件确认是退出码、驱逐、资源限制还是超时。

常见问题

为什么设置了 backoffLimit，容器仍然在同一个 Pod 里重启？

因为 Pod 模板使用了 restartPolicy: OnFailure。这是容器层重启，只有达到 Job 的失败判断条件后，控制器才会结束该 Pod 或进入 Job 终态。需要保留失败现场时，可在调试阶段改用 Never 并接入日志系统。

Job 进入 Failed 后会自动重新开始吗？

不会。backoffLimit 和 activeDeadlineSeconds 触发的是 Job 的永久失败状态。应先修复配置或程序，再由发布系统重新提交一个新的 Job，避免在原对象上误以为它会自行恢复。

总结来说：短暂故障用有限的 backoffLimit，明确的程序错误用 podFailurePolicy 尽早止损，业务窗口用 activeDeadlineSeconds 截断总时长；同时使用 restartPolicy: Never 保留现场，才能把“重试”变成可解释、可审计的生产行为。