Job 的重试机制
Job 用来执行一次性的批处理任务。Pod 失败后，Job 控制器会按退避策略重试：间隔从大约十秒开始逐次加倍，达到上限后固定；总重试次数由 backoffLimit 控制，默认是六次。超过上限后 Job 被标记为失败并停止重试，等待人工介入，不会无限重跑。
基本信息
| 适用平台 | Kubernetes 1.21+，使用 batch/v1 |
|---|---|
| 重试上限 | backoffLimit，默认 6 次 |
| 退避间隔 | 从约 10 秒指数增长，达到上限后固定 |
| 容器重启策略 | Never 或 OnFailure，必须显式设置 |
| 停止原因 | 达到重试上限或超过最长运行时间 |
典型使用场景
- 数据导出任务偶发网络抖动失败，靠自动重试恢复
- 批处理脚本需要最终成功，同时避免无限重跑打满资源
- 排查任务为何反复重启，区分业务报错与节点侧原因
- 给长跑任务设置最长运行时间，防止卡死占用配额
- 并行任务中个别分片失败，需要单独重试或人工补跑
配置示例
配置示例
spec:
backoffLimit: 4 # 最多重试 4 次
activeDeadlineSeconds: 3600 # 任务总时长上限
template:
spec:
restartPolicy: Never # 失败生成新 Pod，保留现场
containers:
- name: task
image: registry.example.com/task:3.1查看失败原因
查看失败原因
kubectl get job batch-x -o jsonpath='{.status.conditions[*].reason}' # 是否达到重试上限
kubectl describe job batch-x | tail -20 # 事件里能看到重试次数
kubectl logs job/batch-x --tail=100 # 业务侧报错
kubectl get pods -l job-name=batch-x # 失败 Pod 是否保留现场参数与现象读法
| 配置 | 含义 | 经验取值 |
|---|---|---|
| backoffLimit | 失败重试次数上限 | 结合任务幂等性与失败代价设定，默认 6 |
| restartPolicy: Never | 失败生成新 Pod | 需要保留每次失败的现场时使用 |
| restartPolicy: OnFailure | 在同一 Pod 内重启容器 | Pod 数量不增长，但现场会被覆盖 |
| activeDeadlineSeconds | 任务总时长上限 | 长跑任务应设置，避免永久占用配额 |
| completions 与 parallelism | 成功次数与并发度 | 并行度要与重试次数一起评估 |
容器重启策略决定失败现场的保留方式：选择 Never 时每次失败都会留下一个新 Pod 便于取证，选择 OnFailure 只在同一个 Pod 内重启容器，环境信息会丢失。
重试上限设得很大又始终定位不到根因时，任务会反复拉镜像重跑，既消耗资源也刷满集群事件。先看日志确认失败原因，再决定是否放宽重试。