第一次在 Kubernetes 里跑定时任务的时候我差点直接用一个 Deployment 来承载每天晚上执行的统计脚本。脚本明明跑完了一堆 Pod 还围在那里挂着我看着它们发呆任务都结束了你怎么还赖着不走后来才意识到Kubernetes 里管常驻服务和管跑完就结束的任务用的完全是两套控制器。前者是 Deployment后者就是这一章要聊的 Job 与 CronJob。这一章面向零基础快速上手。你只需要知道 Pod 和 YAML 长什么样就可以继续往下走。核心就两件事Job 负责跑一次性任务CronJob 负责按计划定时触发 Job。我们会从 Job 的运行逻辑讲起再讲 CronJob 的调度方式然后给出完整的 YAML 示例、操作命令和排错技巧。读完你会发现一次性任务和定时任务没那么玄乎它们只是换了一种方式回答同一个问题任务做完之后接下来应该发生什么。1. 为什么需要 Job 控制器先搞懂一次性任务与常驻服务的区别1.1 Deployment 管永不停止Job 管做完即走Deployment 解决的是集群里必须有 Pod 在跑的问题。你声明 3 个副本Deployment 就会确保任何时刻都有 3 个。哪怕某个 Pod 被误删它也会立刻新建一个补上。它对 Pod 的默认预期是一直运行一旦容器里的进程退出了Deployment 反而会认为故障了然后按照重启策略把容器重新拉起来。对 nginx 这类 Web 服务来说这个逻辑是对的宕机自动恢复正是我们想要的。但批处理任务的逻辑完全相反。想象一个场景每天早上 6 点把前一天产生的订单数据汇总、清洗写入数仓。这个任务跑完之后我们希望它就安静地结束而不是再被重新拉起执行一遍。如果你用 Deployment 去跑它会把这个已经执行完的 Pod当作故障去修复于是一个已经完成的脚本被反复重启每次重启都完整重跑一遍后果轻则重复计算重则产生脏数据这就是生产事故。Job 就是 Kubernetes 为这种跑完就结束的场景专门设计的控制器。Job 会创建 Pod然后等待 Pod 里的进程结束根据退出码判断这趟任务算不算成功。任务成功Job 就保持在 Completed 状态任务失败Job 会按照你配置的重试策略去新建或重启 Pod直到任务成功或者重试次数耗尽。维持多少个副本在线不是它的目标成功完成几次任务才是。这个语义差异是理解 Job 一切行为的前提。1.2 退出码Job 判定成败的唯一标准这里有一个必须记住的核心结论Job 不关心你的 Pod 里跑的是什么业务它只关心容器主进程最终退出时的退出码。退出码是 0它就是成功退出码非 0它就是失败。你可以把 Job 理解成一个只看结果不看过程的管理者——脚本里打印了多少行日志它不管只要主进程以 0 退出它就认定这件事干完了。这个设计带来两个重要推论。第一你的容器镜像启动命令必须是执行完就退出的任务型命令而不是常驻进程。比如一行perl script.pl可以但nginx -g daemon off;就不行因为后者根本不会退出Job 会一直看着它运行中直到达到超时时间。第二Pod 的重启策略在 Job 里被限制为Never或OnFailure不允许使用Always。原因很简单Always代表无论如何都重启这对常驻服务合理但任务型 Pod 如果成功跑完还被重启那就等于自己拉自己的后腿。关于退出码还有一个实操里容易踩的坑容器命令行里用到管道、循环或者多命令组合时最终退出码取的是最后一条命令的结果。比如你写的是backup.sh | gzip backup.gzShell 返回的退出码是 gzip 的不是 backup.sh 的。假如 backup.sh 失败了但 gzip 成功了Shell 照样返回 0Job 就会误判成功。正确做法是在脚本开头加上set -o pipefail或者把每一步的执行结果都显式检查一遍。这个细节在你排查备份任务为什么明明失败了却显示 Completed时会感激自己的。2. Job 的关键参数与运行模式2.1 三个核心参数怎么配合completions、parallelism 与 backoffLimitJob 有三个最核心的字段几乎覆盖所有使用场景值得花时间逐个吃透参数默认值作用completions1期望成功结束的 Pod 总数parallelism1允许同时运行的 Pod 数量上限backoffLimit6失败后允许重新尝试的次数activeDeadlineSeconds无整个 Job 的最大存活时间ttlSecondsAfterFinished无完成后自动清理 Pod 的等待秒数三个参数组合起来可以覆盖生产中绝大多数批处理需求。最简单的单次任务全部默认即可跑一个 Pod 就算完事。固定数量并行的任务比如要处理 10 个数据块可以设completions: 10和parallelism: 3Kubernetes 会保证最多同时有 3 个 Pod 在跑但最终累计有 10 个 Pod 成功结束才算 Completed。先跑完的 Pod 退出后控制器立刻补一个新的进来直到凑满 10 个这个配额。这种一边退出一边补入的节奏与 Deployment 的始终维持副本数完全是两码事你多观察几次 Pod 的变化就会体会出来。第三种是工作队列模式completions干脆不设置。此时每个 Pod 启动后自己去任务队列里抓任务抓不到就退出。Kubernetes 不关心每个 Pod 具体处理了多少个任务只要看到至少有一个 Pod 成功结束就认为 Job 完成。这类场景通常配合消息队列、Redis 队列或数据库任务表使用适合处理任务总数不固定、由 worker 自行认领的情况。三种模式没有优劣之分纯粹取决于你对任务总量的预判总量已知用固定completions总量未知用工作队列。2.2 重启策略怎么选Never 还是 OnFailurerestartPolicy是 Job 里最容易让初学者纠结的字段。它有两条路可以走对应完全不同的失败恢复方式。Never模式下容器以非零码退出后Job 会创建一个全新的 Pod 来重试旧的失败 Pod 会以 Failed 状态留在原地保留退出状态和日志。OnFailure模式下容器失败后 Job 会在同一个 Pod 内重启容器Pod 本身不会被重建宿主机上只是经历一次容器的 Stop 和 Start。我在实际项目里默认选Never。最大的理由是保留现场。容器一旦以非零码退出如果你用的是OnFailure下一次运行时的日志很可能把上一次的日志覆盖而当你没有把日志写入持久化存储时失败现场被冲掉排查问题会非常被动。Never会把失败的 Pod 留在那里你随时可以kubectl logs pod看到退出前的最后状态。代价是失败 Pod 会逐渐积累需要手动清理或者靠ttlSecondsAfterFinished自动清理。OnFailure也不是没有价值。如果你的容器镜像很大、每次创建 Pod 的调度开销不低那么在同一个 Pod 里重启容器确实比重建整个 Pod 来得更快。另外有些应用在失败时会留下崩溃状态文件你希望这些状态保留在同一份本地文件系统里OnFailure更合适。我的建议是第一次调试时用Never等逻辑成熟后再根据重试开销决定要不要切换。2.3 容易被忽略的两个参数activeDeadlineSeconds 与 ttlSecondsAfterFinished这两个参数一个管上限一个管结尾实战价值极高但在很多入门教程里反而被一笔带过。activeDeadlineSeconds给整个 Job 设置了一个生存时限。从 Job 创建开始计时一旦超过这个时间还没完成Job 会被强制标记为失败并停止创建新的 Pod、终止还在运行的 Pod。它是防止死循环或外部依赖卡死的神器。我见过一个数据归档 Job 因为上游接口一直不返回Pod 挂着不退出整整占用了三天集群资源就是因为当初少了这个字段。建议所有 Job 都设置上哪怕只是给个保守的宽限时间也比失控强。ttlSecondsAfterFinished则负责打扫战场。Job 完成后如果设置了该字段完成任务或失败任务对应的 Pod 会在指定秒数之后被自动清理掉省去手动kubectl delete job的麻烦。这里强调一下清理的是 Job 及其下的 Pod 对象不是你的业务数据。另外需要确认你的集群版本默认开启了 TTL 清理机制当前主流版本基本都默认开启但如果还在用很老的版本要先检查一下相关特性开关的状态否则设置了也不会生效。3. 从零到一运行你的第一个 Job3.1 最简单示例用 Perl 算圆周率的一次性 Job不铺开讲复杂场景先从官方经典的圆周率例子开始跑一个真正的一次性任务。准备如下 YAML保存为pi-job.yamlapiVersion: batch/v1 kind: Job metadata: name: pi-job spec: template: spec: containers: - name: pi image: perl:5.34 command: [perl, -Mbignumbpi, -wle, print bpi(2000)] restartPolicy: Never把文件保存好后依次执行创建和查询命令观察状态变化kubectl apply -f pi-job.yaml kubectl get jobs正常情况下你会看到类似这样的输出NAME COMPLETIONS DURATION AGE pi-job 1/1 38s 42sCOMPLETIONS那一列显示1/1代表期望成功完成 1 个、已经完成 1 个Job 成功结束。接着用标签找到它创建的 Pod 并查看日志kubectl get pods -l job-namepi-job kubectl logs pod-name这里有个细节值得注意Job 创建的 Pod标签是job-name不是app或者别的什么。如果你习惯了kubectl logs deployment/xxx这种写法在 Job 这里是不适用的必须通过 Pod 标签定位或者直接用kubectl logs job/pi-job。kubectl logs job/xxx这种资源类型写法在较新版本中已经支持用起来更方便。跑完以后这个 Job 和它对应的 Pod 会一直以 Completed 状态待在集群里。实验环境里你可以留着它慢慢观察也可以直接kubectl delete job pi-job清理掉。3.2 并行 Job 实战completions 与 parallelism 的配合效果单发 Job 只能覆盖最简单的场景现实里更多是有一批活并行干。假设一个模拟项目里需要为一批商品图生成缩略图总共 10 张图最多允许 3 个 Pod 同时处理。YAML 可以这样写apiVersion: batch/v1 kind: Job metadata: name: thumb-gen spec: completions: 10 parallelism: 3 template: spec: restartPolicy: Never containers: - name: worker image: busybox:1.36 command: - /bin/sh - -c - | echo start thumbnail task sleep 5 echo task done加上completions: 10和parallelism: 3之后你会发现kubectl get pods会分批出现 Pod有 3 个同时在跑每完成一个就补一个直到累计 10 个成功退出整个 Job 变成 Completed。这个过程中每个 Pod 执行的是同一份处理逻辑但实际场景里它们到底处理哪张图通常会通过环境变量、启动参数或者从任务队列中领取来区分。上面这段用sleep 5模拟处理耗时方便你清晰观察 Pod 的创建和退出节奏。第一次跑并行 Job 时我建议你有意识地把parallelism从 1、3、5 递增着试同时盯着事件变化。你可以直观地看到完成一个、补一个和同时起三个的区别这种体感比背文档有用得多。调参的过程会让你真正理解completions管的是总量parallelism管的是并发上限两者可以独立调节。3.3 工作队列模式让 Worker 自己认领任务前面说的completions属于固定总数模式。有些任务在开始前根本不知道总量是多少比如一批待发送的邮件、一批实时产生的消息数量随时可能增加。这时适合用工作队列模式。工作队列模式下completions不设置parallelism通常设为希望同时运行的 Worker 数。每个 Worker Pod 启动后不断从队列里取任务直到队列为空才退出while true; do task$(redis-cli -h redis-svc --raw LPOP task_queue) if [ -z $task ]; then break fi process_task $task done这里用--raw模式是因为redis-cli默认会在队列为空时打印字符串(nil)而不是空串如果你用普通模式判断-zWorker 永远等不到退出条件。这个细节不留意就会出现队列明明空了Pod 却一直空转的诡异现象。工作队列模式特别适合流量有波动的场景任务多的时候 Worker 多干一会儿任务少的时候 Worker 很快发现队列空了各自退出整个集群不会傻等一个固定数量。需要提醒的是这个模式对队列服务的可用性要求很高。如果队列本身也部署在 Kubernetes 里一旦 Redis 挂掉Worker 会一直重试或空转。配合activeDeadlineSeconds就能避免无限等待。真正常用的做法是上游任务由另一个服务写入队列Job 负责消费两端的节奏通过消息确认机制来保障幂等。4. CronJob让任务按计划执行4.1 先看懂 CronJob 的调度表达式CronJob 是在 Job 外面包了一层调度器它按时间规则创建 Job。时间规则写在schedule字段里格式和 Linux 的 crontab 完全一样分 时 日 月 星期五个字段从左到右分别是第 1 位分钟范围 0-59第 2 位小时范围 0-23第 3 位一个月中的第几天范围 1-31第 4 位月份范围 1-12第 5 位星期范围 0-60 表示周日常用的写法可以记这么几个例子计划表达式含义0 2 * * *每天凌晨 2 点整*/5 * * * *每 5 分钟一次30 3 * * 1每周一凌晨 3 点 30 分0 0 1 * *每月 1 号 0 点整0 */2 * * *每 2 小时整点一次我踩过的第一个坑是把第 1 位和第 5 位搞混5 * * * *是每小时的第 5 分钟执行一次不是每 5 分钟一次。每 5 分钟应该写成*/5 * * * *。看起来只差一个斜杠实际调度结果天差地别在测试环境验证计划表达式时尤其要警惕。还有一个零基础容易忽略的大坑CronJob 默认按 kube-controller-manager 所在环境的本机时区调度很多集群环境默认是 UTC。如果你按照本地时间凌晨 2 点来预期任务执行时间可能发现任务总在早上某个偏移时刻才跑甚至干脆对不上。集群版本足够新1.27 以上时可以在 CronJob 里加scheduleTimeZone字段直接指定 IANA 时区名比如Asia/Shanghai。老版本就只能通过计算 UTC 偏移来反推 schedule或者把控制器时区统一改掉。不要在这个问题上较劲直接用显式时区最省心。4.2 CronJob 的容错与并发控制参数schedule负责决定什么时候跑但真正决定任务能不能稳定跑完的是另外几个参数。startingDeadlineSeconds解决了调度被推迟的情况。如果调度时间到了但集群当下无法立刻拉起 Job比如控制面繁忙、节点资源不够、集群刚从维护中恢复调度就会被推迟。这个参数指定了最多推迟多久超过就不再补跑。如果不设置理论上 CronJob 会一直补跑错过的任务补跑太多反而容易引发任务堆积。生产环境里我一般会给它设一个比调度间隔稍长的值比如每小时任务设startingDeadlineSeconds: 3600逻辑就是晚一小时以内补跑超过一小时宁可错过这次。concurrencyPolicy控制上一次任务还没结束时下一个调度周期要不要再开新的。可选值有Allow、Forbid、Replace三个。对大多数批处理任务我建议用Forbid尤其是备份、统计这类任务。如果上一次因为数据量大而超时你又设置Allow两个备份进程会同时往同一个目标目录写数据互相覆盖等到发现时备份早就坏了。用Forbid虽然意味着本次调度被跳过但至少数据不会乱。successfulJobsHistoryLimit和failedJobsHistoryLimit控制历史 Job 的保留条数。默认成功保留 3 条、失败保留 1 条。如果不清理旧的 Job 和 Pod 会一直存在虽然已经结束但会持续占用列表和少量存储。我的习惯是成功保留 3 到 5 条用于排查失败保留 1 到 2 条足够。4.3 实战每天凌晨备份 MySQL 的完整 CronJob把上面讲的参数全部用起来一个典型的定时备份 CronJob 长这样apiVersion: batch/v1 kind: CronJob metadata: name: db-backup spec: schedule: 0 2 * * * scheduleTimeZone: Asia/Shanghai concurrencyPolicy: Forbid startingDeadlineSeconds: 3600 successfulJobsHistoryLimit: 3 failedJobsHistoryLimit: 1 jobTemplate: spec: backoffLimit: 2 ttlSecondsAfterFinished: 3600 template: spec: restartPolicy: Never containers: - name: backup image: mysql:8.0 command: - /bin/sh - -c - | set -e mysqldump --single-transaction -h db-svc -u root -p$MYSQL_PASSWORD mydb /backup/mydb-$(date %Y%m%d).sql echo backup finished env: - name: MYSQL_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password volumeMounts: - name: backup-storage mountPath: /backup volumes: - name: backup-storage persistentVolumeClaim: claimName: backup-pvc逐段拆解一下设计意图。schedule: 0 2 * * *配合scheduleTimeZone: Asia/Shanghai确保每天北京时间凌晨 2 点执行避免 UTC 时区偏差。concurrencyPolicy: Forbid防止上一次备份未完成时再开新一轮避免备份文件互相覆盖。startingDeadlineSeconds: 3600的含义是如果调度延迟在 1 小时以内就补跑超过 1 小时就放弃本轮防止积压太多未执行的备份任务。jobTemplate内部的backoffLimit: 2表示备份失败后最多重试 2 次。数据库备份这类任务失败后人工介入往往比机器盲试更可靠所以不要把重试次数调得太大。ttlSecondsAfterFinished: 3600让完成后的备份 Pod 在 1 小时后自动消失不会堆积。容器命令里最关键的几行是set -e和mysqldump ... mydb-$(date %Y%m%d).sql。set -e保证脚本中任何一条命令返回非零时立即退出否则 Shell 可能吞掉部分失败信号。备份结果被写到 PVC 挂载目录这样即使 Pod 被清理备份文件还留在持久卷里。数据库密码不要写死在 YAML 里应该用 Secret 引用这也是代码评审时我反复强调的原则。如果你现在还没有准备好 PVC可以先用emptyDir验证流程但真实备份一定要配持久化存储否则 Pod 一删备份数据也跟着没了。5. 常见问题排查与避坑清单5.1 Job 一直 Running 不结束怎么办最容易遇到的怪现象就是 Job 状态一直 RunningPod 不退出。常见原因按优先级排是这么几种容器镜像的默认启动命令是常驻服务。比如你直接用了 nginx 镜像但没有传自定义 commandnginx 起来了当然不会退出Job 自然永远 Running。业务脚本里存在死循环或长时间阻塞。比如脚本等待外部接口响应而接口一直没有返回。应用产生了大量输出但进程迟迟没有结束。排查手段也很直接先kubectl get pods确认这个 Job 的 Pod 状态再kubectl logs pod看它到底在打印什么。如果日志半天没动静可以kubectl exec -it pod -- /bin/sh进到容器里看进程列表定位具体卡在哪条命令上。找到原因后要么修脚本要么给 Job 加上activeDeadlineSeconds作为最后一道安全网。我在生产环境里见过太多死循环脚本吃满 CPU的案例超时字段不是可选项是必选项。5.2 容器反复失败但 Job 没有新 Pod如果 Job 已经显示 Failed但你没看到任何重试十有八九是backoffLimit被耗尽了。用kubectl describe job name查看 Events里面会明确写出类似Job has reached the specified backoff limit的原因。这时候再去逐个看失败 Pod 的退出码和日志答案通常很直接镜像不存在、启动参数拼错、环境变量引用为空、存储卷挂载不上这些都会导致启动即崩。我特别想提醒一个点backoffLimit不等于容器重启次数它统计的是重新尝试创建或重启 Pod 的次数。如果你用的是restartPolicy: Never每次失败都会创建一个新 Pod那么第 7 次失败默认backoffLimit6后 Job 就不再继续了。如果你的任务确实需要很多次尝试就显式调高这个值但同时也要反思为什么它会连续失败这么多次是不是配置本身有问题。5.3 CronJob 到点没跑先查这四件事定时任务没按计划执行是最让人头疼的。先冷静按顺序排查kubectl get cronjob name看 CronJob 的状态和LastScheduleTime。如果LastScheduleTime一直不更新说明调度压根没触发。kubectl get jobs --watch看最近有没有这个 CronJob 创建的 Job。有时候任务其实跑了只是 Pod 失败了看起来像没跑。检查suspend字段是不是被误设成了 true。这个字段是暂停开关很多人调试完忘记改回来CronJob 就悄悄罢工了。检查concurrencyPolicy: Forbid下是否有上一次 Job 还没结束。只要旧的还在运行新的调度就会被跳过Events 里一般会有相应提示。如果以上都正常就回到时区问题。用上一节提到的scheduleTimeZone显式指定时区或者把 UTC 偏移换算清楚再去核对表达式。定时任务的最大特点就是错过不易察觉所以对时间问题一定要保持敏感。5.4 Job 历史记录堆积怎么治理CronJob 默认清理策略是保留最近 3 条成功历史、1 条失败历史。如果你手动创建 JobKubernetes 并不会自动清理它只负责把任务跑完。时间一长kubectl get jobs的输出会拉得很长甚至影响命令行操作体验。我的习惯是设置ttlSecondsAfterFinished让完成后的 Job 在指定秒数后自动消失。如果集群版本不支持这个字段也可以写一个简单脚本定时手动清理kubectl delete job --all或者针对某个 CronJob 清理历史kubectl delete job -l cronjob-namedb-backup手动清理时注意Job 下面的 Pod 会一并删除。如果任务日志还没捞完记得先看完日志再删。5.5 排查命令速查表你想要的结果使用命令查看所有 Jobkubectl get jobs查看某个 Job 的详情和事件kubectl describe job name列出 Job 产生的 Podkubectl get pods -l job-namename查看 Pod 输出日志kubectl logs pod查看整个 Job 下所有 Pod 的日志kubectl logs -l job-namename --tail-1查看 CronJob 配置kubectl get cronjob name -o yaml手动触发一次 CronJob 调度kubectl create job --fromcronjob/name manual-001手动触发 CronJob 的命令在新版本里很实用。调试定时任务时不用傻等下一个调度周期直接创建一次手动 Job 来验证业务逻辑是否正常比调整 schedule 再改回来高效得多。6. 生产环境使用 Job 与 CronJob 的几条经验6.1 脚本必须幂等Job 重试机制的第一道防线Job 的重试机制带来一个常见隐患失败重试时任务会重新执行。如果你的脚本把处理到一半的数据直接写入数据库第二次执行就会看到一个不完整的中间态。所以这类任务脚本的第一原则就是幂等——同一个输入执行多少次结果都一致。实现幂等没有银弹但有几类常见做法要么在写入前先清理旧数据再写入新数据要么用数据库唯一键或事务保证重复写入时直接覆盖而不是叠加要么给每条任务记录打上唯一 ID处理前先查重。无论选哪种都要在准备阶段想好等任务已经跑出脏数据再补救代价会高得多。6.2 给任务加资源限制与超时兜底Job 里的 Pod 如果出现异常可能会吃掉大量 CPU 或内存直接影响同节点的其他服务。我的建议是所有作业型 Pod 都显式声明resources.requests和resources.limits同时设置activeDeadlineSeconds。一旦任务超过合理时间宁可尽早失败、让告警出来也不要让一个失控的 Pod 占着集群资源一整天。没有资源限制的 Job 就像没有刹车的车平时没事出问题时就是大事。6.3 告警设计从任何失败都叫改成失败到底才叫Job 失败时会触发事件但一次失败不一定是坏事backoffLimit存在的意义就是让它重试。如果你对每一次失败事件都告警半夜很容易被误报吵醒。我在项目里的做法是用监控指标去判断 Job 最终进入 Failed 状态也就是backoffLimit耗尽时才触发告警。对于 CronJob额外关注调度延迟如果LastScheduleTime长时间不更新说明调度环节出了问题这类告警通常意味着控制器或配额故障需要第一时间处理。6.4 零基础上手 Job/CronJob 的学习顺序建议如果这是你第一次接触 Job 和 CronJob我给一个循序渐进的测试路径先跑一遍最简单的圆周率 Job确认你能看到 Completed 状态和日志然后把completions改成 5 跑一次观察 5 个 Pod 怎么创建和退出再套一个schedule: */5 * * * *的 CronJob等 5 分钟看它自动创建 Job 的过程。每个参数都改成不同值跑一遍比看 10 遍文档都管用。我个人在实际操作中最大的体会是Job 和 CronJob 虽然概念不复杂但它们的完成语义与 Deployment 完全不同。你只有亲手跑过一次容器退出、Job 变成 Completed的过程才会真正理解这批工具有多顺手。以后凡是遇到要跑脚本、做迁移、发通知、算报表这类活我第一反应都是先把它装进 Job再考虑要不要套一层 CronJob这个习惯帮我省掉了大量手动运维的精力。