Kubernetes Job 实战:一次性批处理任务的 completions、parallelism、backoffLimit,以及和 CronJob 的区别

Kubernetes Job 实战:一次性批处理任务的 completions、parallelism、backoffLimit,以及和 CronJob 的区别用 Deployment 跑一个数据迁移脚本,你会发现它跑完退出后被不停重启——因为 Deployment 的使命是「让 Pod 永远活着」,而批处理任务的本质是「跑完就该结束」。这两种语义天生冲突。Kubernetes 为「跑一次就完事」的任务专门准备了Job:它保证 Pod 成功运行到结束,失败了按规则重试,完成后不再拉起。这篇把 Job 的几个核心字段和常踩的坑讲清楚。为什么不能用 Deployment 跑批处理先看错误示范。你把一个「导一次数据」的脚本塞进 Deployment:# 反例:别这么干apiVersion:apps/v1kind:Deploymentmetadata:name:data-migratespec:replicas:1template:spec:containers:-name:migrateimage:myapp:latestcommand:[python,migrate.py]脚本跑完退出码 0,Pod 进入Completed,但 Deployment 的控制器发现「怎么没有活着的 Pod」,立刻又拉一个——于是你的迁移脚本被反复执行,数据可能被重复导入。Deployment 适合长期运行的服务,不适合会主动结束的任务。一个最小的 JobJob 的 YAML 和 Deployment 很像,但语义完全不同:apiVersion:batch/v1kind:Jobmetadata:name:data-migratespec:template:spec:containers:-name:migrateimage:myapp:latestcommand:[python,migrate.py]restartPolicy:Never# Job 里只能是 Never 或 OnFailure,不能是 AlwaysbackoffLimit:4# 失败最多重试 4 次restartPolicy必须是Never或OnFailure(不能像 Deployment 那样用默认的Always,否则创建时直接报错)。跑起来看状态:kubectl apply-fjob.yaml kubectl getjobs# 看 COMPLETIONS 列,如 1/1 表示完成kubectl get pods# Job 创建的 Pod,完成后是 Completedkubectl logs job/data-migrate# 直接看 Job 的日志backoffLimit:失败重试到几次就放弃任务可能因为临时故障(网络抖动、依赖没起来)失败。backoffLimit控制整个 Job 层面允许的失败次数,默认 6。达到上限后 Job 被标记为Failed,不再重试。spec:backoffLimit:4template:spec:restartPolicy:Never# ...两个容易混淆的点:restartPolicy和backoffLimit是两层重试。restartPolicy: OnFailure是在同一个 Pod 内重启容器;restartPolicy: Never则是每次失败新建一个 Pod。backoffLimit统计的是整个 Job 的失败总数。生产上多用Never,因为每次失败换新 Pod,日志和现场都留得下来,便于排查。重试有指数退避:失败后等待时间是 10s、20s、40s……逐步拉长,最长封顶 6 分钟。所以别指望失败后立刻重跑。想给任务加个「最长跑多久,超了就杀」的兜底,用activeDeadlineSeconds:spec:activeDeadlineSeconds:600# 整个 Job 最多跑 600s,超时直接失败,优先级高于 backoffLimitbackoffLimit:4completions 与 parallelism:批量任务的两种并行模式单个任务用上面的配置就够了。但如果你要「处理 100 个文件」「跑 10 次采样」,需要completions(总共要成功几次)和parallelism(同时最多跑几个)。模式一:固定完成次数,串行或并行跑 N 次spec:completions:10# 总共要成功 10 个 Podparallelism:3# 同时最多 3 个 Pod 在跑template:spec:restartPolicy:Nevercontainers:-name:workerimage:myapp:latestcommand:[python,process.py]Kubernetes 会维持最多 3 个 Pod 并行,一个成功就补一个,直到累计 10 个成功。适合「同样的任务重复跑固定次数」。模式二:工作队列模式,只设 parallelism如果任务自己从队列(Redis、RabbitMQ)里领活,领完就没了,那就不设completions,只设parallelism:spec:parallelism:5# 5 个 worker 并行消费队列template:spec:restartPolicy:Nevercontainers:-name:consumerimage:queue-worker:latest这时只要有任意一个Pod 成功退出(代表队列空了),Job 就认为整体完成,会等其余 Pod 也退出后结束。这是典型的「多消费者抢队列」模式。用 ttlSecondsAfterFinished 自动清理Job 完成后,Pod 默认不会自动删除——这是故意的,好让你查日志。但攒多了会占满 etcd 和kubectl get pods的视野。用ttlSecondsAfterFinished让它完成后自动清理:spec:ttlSecondsAfterFinished:3600# 完成/失败 1 小时后,Job 及其 Pod 自动删除template:spec:restartPolicy:Never# ...没有这个字段的话,记得手动kubectl delete job xxx,否则集群里会堆一堆Completed的僵尸。Job vs CronJob:一次性 vs 定时重复初学者最常问的问题:两者啥关系?一句话——CronJob 是「按时间表反复创建 Job」的调度器。Job:你手动或由流程触发一次,跑一次就结束。适合数据迁移、一次性批处理、CI 里的构建步骤。CronJob:按 cron 表达式定时,每到点自动创建一个 Job。适合每天备份、每小时清理、周期报表。CronJob 的spec.jobTemplate里装的就是一个 Job 定义:apiVersion:batch/v1kind:CronJobmetadata:name:nightly-backupspec:schedule:0 2 * * *# 每天凌晨 2 点jobTemplate:spec:# 这里面就是一个完整的 Job specbackoffLimit:2template:spec:restartPolicy:OnFailurecontainers:-name:backupimage:backup-tool:latest所以理解了 Job,CronJob 只是多了个「定时创建」的外壳。要跑一次选 Job,要周期性跑选 CronJob。排查:Job 卡住不完成怎么办最常见几种情况和定位手段:# 1. 看 Job 事件,是不是 Pod 建不出来(资源不足、镜像拉不到)kubectl describe job># 2. 看 Pod 状态,Pending 就是调度问题,CrashLoopBackOff 就是程序崩kubectl get pods-ljob-namedata-migrate# 3. 看失败 Pod 的日志找根因kubectl logspod-name如果 Job 一直不 Completed 又不 Failed,通常是程序没正确退出(比如脚本跑完还阻塞在某个连接上没退出),检查你的程序结尾有没有正常exit 0——Pod 不退出,Job 永远认为它还在跑。小结批处理任务用Job别用Deployment,后者会把「跑完就退出」的 Pod 反复拉起。restartPolicy只能Never(失败换新 Pod,推荐)或OnFailure(原地重启容器);backoffLimit控整个 Job 的失败上限,重试带指数退避。加activeDeadlineSeconds做超时兜底;它优先级高于 backoffLimit。批量并行:completions定总成功次数,parallelism定同时并发数;工作队列模式只设parallelism。用ttlSecondsAfterFinished自动清理完成的 Job,否则手动删,别攒僵尸。CronJob 定时反复创建 Job;一次性用 Job,周期性用 CronJob。一句话记忆:Deployment 保活、Job 保「跑完」;Job 跑一次,CronJob 按点反复跑。