Kubernetes Job 怎样设置失败重试次数

Kubernetes Job 的失败重试次数由 spec.backoffLimit 控制。直接设置一个整数即可，例如 backoffLimit: 3 表示 Job 在失败计数达到 3 时进入失败状态；不设置时默认值是 6。需要注意，这个字段位于 Job 的 spec 下，不是 Pod 模板的 spec 下。

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

先确定 backoffLimit 的含义

backoffLimit 是 Job 控制器用来判断“还要不要创建替代 Pod”的失败计数上限。以 backoffLimit: 3 为例，失败 Pod 或符合计数规则的容器重试累计到 3 后，Job 会被标记为失败，仍处于 Pending 或 Running 的 Pod 也会被终止。

如果只是想限制失败次数，先从一个较小、可解释的数值开始，再根据任务的瞬时故障概率调整。把它设得很大并不会修复程序本身的逻辑错误，只会让失败任务等待更久。

写出一个可控的 Job 清单

下面的示例让容器直接以非零状态退出，方便观察 Job 的失败边界。调试阶段使用 restartPolicy: Never，让一次容器失败对应一个失败 Pod，计数更直观。

apiVersion: batch/v1
kind: Job
metadata:
  name: retry-demo
spec:
  # 失败计数达到 3 后，Job 进入 Failed
  backoffLimit: 3
  template:
    spec:
      # 调试时保留失败 Pod，便于查看日志
      restartPolicy: Never
      containers:
        - name: worker
          image: busybox:1.36
          # 用固定退出码模拟任务失败
          command: ["sh", "-c", "echo task failed; exit 1"]

应用清单时可使用下面的命令；这里的命令只负责创建 Job 和查看状态，不代表文章在本机执行过。

# 创建 Job，清单中的 backoffLimit 会由控制器读取
kubectl apply -f retry-demo.yaml

# 查看 Job 的完成数、失败数和最终条件
kubectl get job retry-demo -o wide

# 查看失败 Pod 的原因和日志，保留现场便于排查
kubectl get pods -l job-name=retry-demo
kubectl logs job/retry-demo --all-containers=true

理解失败计数与退避等待

Job 控制器不会无间隔地创建替代 Pod。官方文档给出的退避序列是 10 秒、20 秒、40 秒，之后继续增长但最长不超过 10 分钟。失败计数达到上限前，等待时间会让“设置了重试”看起来不像立即重试。

如果把 Pod 的 restartPolicy 改成 OnFailure，容器会在原 Pod 中重新启动；此时控制器还会把 Pending 或 Running Pod 中各容器的重试计入判断。两种策略的差异不是“一个重试、一个不重试”，而是重试发生在容器内还是通过新 Pod 完成。

调试失败程序时，Never 通常更容易保留失败 Pod 的现场；如果使用 OnFailure，要确保程序能够处理同一 Pod 内的重复启动，并把日志交给可靠的日志系统。

用 activeDeadlineSeconds 设总时限

backoffLimit 限制失败次数，activeDeadlineSeconds 限制 Job 的总运行时长。两者同时存在时，达到时间上限会先停止后续重试，即使失败计数还没有达到 backoffLimit。

spec:
  # 最多允许 5 次失败计数
  backoffLimit: 5
  # Job 总运行时间超过 100 秒后结束
  activeDeadlineSeconds: 100
  template:
    spec:
      # 每次失败由新的 Pod 承担，便于区分失败现场
      restartPolicy: Never
      containers:
        - name: worker
          image: busybox:1.36
          # 示例任务：持续运行，实际项目应替换成业务命令
          command: ["sh", "-c", "sleep 30; exit 1"]

这两个字段解决的是不同问题：前者控制失败次数，后者控制等待和执行的时间预算。若任务具有明确的最长处理时间，建议同时设置，避免网络故障或逻辑错误让 Job 长时间占用资源。

排查重试次数看起来不对

1. 先看字段层级。确认 backoffLimit 在 Job 的 spec 下，restartPolicy 在 spec.template.spec 下。
2. 再看 Pod 状态。使用 kubectl get pods -l job-name=retry-demo 区分是多个失败 Pod，还是同一 Pod 内的容器重启。
3. 最后看终止原因。如果 Job 同时设置了 activeDeadlineSeconds，超时可能先于重试上限触发；如果设置了并行度，多个 Pod 也可能同时运行。

还要记住，Job 失败是终态，不会因为设置了 restartPolicy 就自动重新启动整个 Job。修复配置或程序后，应创建新的 Job，或者由上层流程按自己的策略重新提交。

常见问题

backoffLimit 不设置时是多少？

普通 Job 默认是 6；如果使用按索引设置的失败上限，默认语义会有所不同，不能只按普通 Job 的规则推断。

backoffLimit 是 Pod 重启次数吗？

不完全是。Never 时主要观察失败 Pod 数量，OnFailure 时还会统计相关容器的重试，因此应结合 restartPolicy 一起理解。

怎样让失败任务更快结束？

根据任务最长可接受运行时间设置 activeDeadlineSeconds，并用 backoffLimit 限制失败次数；不要只把失败上限调得很大。