Kubernetes CronJob 实战:并发策略、失败重试与「任务卡住」排查

Kubernetes CronJob 实战:并发策略、失败重试与「任务卡住」排查定时任务谁都写过——数据库备份、清理过期文件、每小时同步一次报表。搬到 K8s 上,很多人直接照着文档抄一个 CronJob YAML,跑起来看着挺好,直到有一天出事:上一次备份还没跑完,下一次又启动了,两个进程同时写同一个文件把数据搞坏了;或者任务失败后疯狂重启,一晚上拉起几百个 Pod。这些坑都不是 K8s 的 bug,而是几个关键字段没配对。这篇把 CronJob 最容易踩的三块——并发策略、失败处理、历史堆积——讲清楚。一个能跑但有隐患的最小例子先看最朴素的写法:apiVersion:batch/v1kind:CronJobmetadata:name:db-backupspec:schedule:0 2 * * *# 每天凌晨 2 点,标准 cron 语法jobTemplate:spec:template:spec:restartPolicy:OnFailurecontainers:-name:backupimage:myorg/backup:1.0command:[/bin/backup.sh]它能跑,但缺了三样关键配置:并发策略、重试上限、历史清理。默认值往往不是你想要的,下面逐个补。坑一:任务跑太久,下一次又启动了CronJob 只负责「到点创建一个 Job」,它不管上一个 Job 有没有跑完。如果你的备份要跑 90 分钟,而 schedule 是每小时一次,那到点就会又起一个,两个备份并行。concurrencyPolicy就是管这个的,三个取值:Allow(默认):允许并发,上一个没跑完照样起新的。Forbid:上一个还在跑,这次直接跳过,不创建。Replace:上一个还在跑,杀掉旧的用新的替换。备份、数据同步这类「同时跑会互相踩」的任务,几乎都该用Forbid:spec:schedule:0 * * * *concurrencyPolicy:Forbid# 上一次没结束就跳过这一次到底选 Forbid 还是 Replace?问自己一个问题:旧任务的结果还有用吗?备份 job 跑到一半有价值(至少备了一部分),别杀,用Forbid跳过新的;而「同步最新状态」这种任务旧的已经过时了,用Replace拿新的顶掉旧的更合理。坑二:失败后无限重试,Pod 越拉越多Job 失败会重试,重试次数由backoffLimit控制,默认是 6。但很多人不知道:如果脚本本身有 bug 秒退,6 次重试很快就烧完,然后 Job 被标记为 Failed 不再重试——这还算好的。真正的坑是 Pod 层的restartPolicy和 Job 层的backoffLimit叠加,理解不清就会看到一堆 Pod。正确的配法:限制重试次数,再加一个activeDeadlineSeconds兜底——任务跑超过这个时间(不管是卡住还是死循环)就强制终止,避免一个任务永远挂着:jobTemplate:spec:backoffLimit:3# 最多重试 3 次,别用默认的 6activeDeadlineSeconds:600# 单次任务超过 10 分钟强杀,防卡死template:spec:restartPolicy:Never# 配合 backoffLimit,失败就新建 Pod 而非原地重启containers:-name:syncimage:myorg/sync:2.1restartPolicy只能是Never或OnFailure(CronJob 里不能用Always)。用Never时每次失败会新建一个 Pod,失败的 Pod 会留下来方便你kubectl logs看日志;用OnFailure是原地重启同一个 Pod,日志会被覆盖。排查阶段推荐Never,能留住失败现场。坑三:成功的 Job 堆了几百个,kubectl 一片刷屏CronJob 每次执行都会留下一个 Job 对象和对应的 Pod。跑了一个月,kubectl get jobs出来几百行。用这两个字段控制保留数量:spec:successfulJobsHistoryLimit:3# 成功的只留最近 3 个failedJobsHistoryLimit:3# 失败的留 3 个,方便回溯默认成功保留 3、失败保留 1。失败的建议调大一点(比如 3~5),多留几个失败现场好排查;成功的留 1~3 足够。排查:CronJob「不触发」怎么定位线上最常见的求助是「我的 CronJob 到点没跑」。按这个顺序查:# 1. 看它有没有被暂停,以及上次调度时间kubectl get cronjob db-backup# SUSPEND 那列如果是 True,就是被人 suspend 了# 2. 看事件,最能说明问题kubectl describe cronjob db-backup# 常见:concurrencyPolicyForbid 时会看到 Cannot determine if job needs to be started: Too many missed start times# 3. 看它实际创建出来的 Job 和 Podkubectl getjobs--selectorjob-name kubectl logs job/job-name有个特别隐蔽的坑:如果 controller 因为节点故障错过了太多次调度(默认超过 100 次 miss),CronJob 会彻底停止调度并报 “Too many missed start times”。startingDeadlineSeconds就是防这个的——它规定「错过后多久内还允许补跑」,设一个合理值(比如 200 秒)能让偶尔的错过被容忍,而不是一次雪崩后彻底罢工:spec:startingDeadlineSeconds:200# 错过调度后 200 秒内仍尝试补启动注意别把它设得比调度间隔还长,否则一次长时间故障恢复后会挤着补跑一堆。小结concurrencyPolicy:会互相踩的任务用Forbid;旧结果无用、要最新的用Replace。默认Allow很少是你想要的。backoffLimit别用默认 6,配合activeDeadlineSeconds给单次任务设超时,防死循环/卡死。restartPolicy: Never会留住失败 Pod 的日志,排查期更友好。successfulJobsHistoryLimit/failedJobsHistoryLimit控制历史堆积,失败的多留几个。不触发时按「SUSPEND → describe events → 实际 Job 日志」三步查;startingDeadlineSeconds避免错过太多次后彻底罢工。一句话记忆:CronJob 只管「到点建 Job」,并发、重试、超时、历史全靠字段兜底——默认值大多不是生产该用的值。