Job 是什么
Job 描述“跑到成功为止”的一次性任务，和 Deployment 那种常年值守的副本模型相反：Pod 正常退出后算一次完成，达到 completions 指定的成功次数，Job 才算完成。失败会按 backoffLimit 重试，整体超时由 activeDeadlineSeconds 兜住；容器的重启策略只能是 Never 或 OnFailure，写成 Always 会被 API 直接拒绝。
基本信息
| completions | 需要成功完成的 Pod 总数，默认 1 |
|---|---|
| parallelism | 同时运行的 Pod 数，默认 1，调大要求任务本身可并发 |
| backoffLimit | 失败重试次数上限，默认 6，超限后 Job 标记为 Failed |
| activeDeadlineSeconds | 整体运行时长上限，超时后任务被终止 |
| restartPolicy | 只能 Never 或 OnFailure；Never 换新 Pod，OnFailure 重启同一 Pod |
| 清理 | ttlSecondsAfterFinished 可让完成的 Job 连同 Pod 自动回收 |
典型使用场景
- 数据库结构迁移：发布流程里的前置一次性任务
- 离线数据导出与批处理：按数据分片并发跑多个 Pod
- 运维脚本的一次性执行：不用手敲 exec 进容器
- CronJob 的执行单元：定时任务的每次触发都是一个 Job
- 压测或数据回填：需要控制并发度又要求全部成功
Job 示例
Job 示例
apiVersion: batch/v1 # 批处理 API 组
kind: Job
metadata:
name: db-migrate
spec:
backoffLimit: 3 # 失败最多重试 3 次
activeDeadlineSeconds: 600 # 整体超过 10 分钟即终止
template:
spec:
restartPolicy: Never # 一次性任务不能写 Always
containers:
- name: migrate
image: registry.example.com/team/app:1.2.3
command: ["./migrate", "--up"]关键字段读法
| 字段 | 含义 | 默认与注意 |
|---|---|---|
| completions | 需要成功完成的 Pod 数 | 默认 1，多分片任务需显式设置 |
| parallelism | 并发运行的 Pod 数 | 默认 1，调大前确认任务支持并发 |
| backoffLimit | 失败重试上限 | 默认 6，超限后 Job 状态为 Failed |
| restartPolicy | 容器重启策略 | 只能 Never 或 OnFailure |
| activeDeadlineSeconds | 整体超时上限 | 超时即终止，注意与重试次数叠加 |
排查失败的 Job：kubectl describe job 看 Events，kubectl logs job/<名> 看业务输出；日志分散在多个 Pod 时按 Pod 分别看。
任务成功后 Pod 默认保留，方便回看日志；长期堆积会占用对象配额，建议设置 ttlSecondsAfterFinished 或统一清理。
两种重启策略影响日志分布：OnFailure 在同一个 Pod 里反复重启容器，日志集中好读；Never 每次失败都新建 Pod，日志分散，要按 Pod 逐个收集。