Job 是什么
Job 管理的是「跑到成功就结束」的任务：它会创建容器、等待执行完毕，进程正常退出即视为完成；失败则按设定的次数重试。这与常驻服务完全相反——服务要一直运行，任务要的是收敛结果。数据迁移、批处理、初始化脚本这类工作，正确做法都是交给它，而不是塞进常驻容器里靠启动脚本执行。
完成与并行的两个维度
一个维度是要成功完成几次，另一个维度是同时允许多少个实例在跑。前者决定总工作量，后者决定并发度。比如一百个分片的任务可以设定总量一百、并发十个，控制器会持续补位直到全部完成。重试次数限制了失败后还能再试几次，超过就整体判定失败。
基本信息
| 适用环境 | 任何 Kubernetes 发行版，属于批处理接口组 |
|---|---|
| 完成条件 | 成功完成的实例数达到设定值 |
| 并行控制 | 同时运行的实例数上限 |
| 重试机制 | 失败后按次数上限重试，耗尽后判定失败 |
| 重启策略限制 | 只能设为从不重启或失败时重启，不能设为总是重启 |
| 清理方式 | 可设定完成后自动清理，或手工删除对象 |
典型使用场景
- 数据库迁移：版本升级前执行结构变更脚本，完成后再发布应用
- 批量数据处理：把历史数据分片并行处理，缩短总耗时
- 一次性初始化：为新环境创建索引、初始化存储桶与基础数据
- 发布前的校验任务：确认依赖可用后再进入发布流程
- 定时任务的实际执行体：由定时对象按时间创建任务对象
- 回填与修复：对历史数据做一次性修正并输出结果统计
Job 清单
Job 清单
apiVersion: batch/v1
kind: Job
metadata:
name: db-migrate
spec:
completions: 1 # 需要成功完成的实例数
parallelism: 1 # 同时运行的实例数
backoffLimit: 6 # 失败重试上限
ttlSecondsAfterFinished: 3600 # 完成后一小时自动清理
template:
spec:
restartPolicy: OnFailure # 注意：不能设为总是重启
containers:
- name: migrate
image: registry.example.com/migrate:1.8.0
command: ["./migrate", "up"]操作与观察
操作与观察
kubectl apply -f job.yaml # 提交任务
kubectl get job db-migrate -o wide # 看完成进度计数
kubectl get pods -l job-name=db-migrate # 任务产生的实例
kubectl logs job/db-migrate # 查看执行输出
kubectl delete job db-migrate # 手工清理，保留实例便于查日志关键字段读法
| 字段 | 含义 | 设置建议 |
|---|---|---|
| completions | 需要成功完成的实例数 | 单次任务填一，分片任务填总分片数 |
| parallelism | 同时运行的实例数 | 按下游承受能力设置并发 |
| backoffLimit | 失败重试上限 | 任务必须可重复执行 |
| restartPolicy | 实例退出后的处理方式 | 只能选从不重启或失败时重启 |
| ttlSecondsAfterFinished | 完成后多久自动清理 | 便于自动回收不占资源 |
任务失败重试会重新运行整个容器，因此任务逻辑必须可重复执行，重复运行的副作用要提前设计好。
默认会保留已完成任务的实例，便于查看日志；设置自动清理后日志会一并消失，排障期先不要开启。