Job 与 CronJob：批处理与定时任务

为什么不能拿 Deployment 跑一次性任务#

假设你要跑一个数据库迁移脚本，或者生成一份日报。第一反应可能是「用 Deployment，把命令写进 command」。跑起来你会发现它永远跑不完——脚本退出后，Pod 状态变成 Completed，然后 Deployment 立刻又拉一个新的起来，如此循环。

原因在于两者的语义完全不同：

Deployment 的 Pod 重启策略被强制要求是 Always，它天然不适合「跑完就退出」的进程。常驻服务用 Deployment，一次性任务用 Job，按时间表重复的用 CronJob。

Job 的四个关键字段#

Job 的难点不在怎么写，而在「要跑几个、能不能并行、失败了怎么办」。四个字段覆盖了这四件事：

completions: 5 配 parallelism: 2 的意思是：一共要完成 5 个 Pod，同时最多跑 2 个，完成一个就补一个。如果 parallelism 大于 completions，实际并发会被 completions 限制住。

还有一个必须显式写的字段：template.spec.restartPolicy。Job 的 Pod 只允许 Never 或 OnFailure：

• Never：容器失败后新建一个 Pod，旧 Pod 保留失败现场，日志好查。
• OnFailure：在同一个 Pod 里重启容器，Pod 数量不会暴涨。

另外 ttlSecondsAfterFinished 很实用：它让 Job 完成后过一段时间自动被清理，连带删掉它的 Pod，避免集群里堆满 Completed 的 Pod。

一张图看懂 CronJob → Job → Pod#

三个资源的职责是分层的：CronJob 只负责「什么时候创建」，Job 负责「跑几次、失败了怎么办」，Pod 负责「真正执行命令」。搞清这条链路，排查时就知道该看哪一层。

CronJob  report-hourly                 ← 定时器：只做「创建 Job」这件事
  │  spec.schedule: "*/5 * * * *"
  │  spec.concurrencyPolicy: Forbid    ← 决定上一轮没跑完时怎么办
  │  spec.jobTemplate:                 ← 每次到点就复制一份，变成 Job
  ▼
Job  report-hourly-28934567            ← 一次执行记录：管完成数、并发、重试
  │  spec.completions / parallelism / backoffLimit
  │  spec.template:                    ← 由 Job 控制器创建 Pod
  ▼
Pod  report-hourly-28934567-x7k2q      ← 真正跑容器的东西
  │  restartPolicy: Never | OnFailure
  ▼
Succeeded / Failed                     ← 结果保留在 Pod 里，等 TTL 或历史上限清理

时间轴（任务耗时 6 分钟，调度间隔 5 分钟，于是前后两轮会重叠）
  09:00       09:05       09:10       09:15
    │           │           │           │
  [Job A ────6min────]
               [Job B ────6min────]
                           [Job C ────6min────]

concurrencyPolicy 的三种行为（看 09:05 这一刻）：
  Allow    Job A 还在跑 → 照常启动 Job B，两个同时跑（默认值）
  Forbid   Job A 还在跑 → 09:05 这一轮直接跳过，等 09:10 再判断
  Replace  先终止 Job A 的 Pod，再启动 Job B（旧任务半途而废）

动手：写一个 Job#

apiVersion: batch/v1
kind: Job
metadata:
  name: report-once
  namespace: demo
spec:
  backoffLimit: 3
  activeDeadlineSeconds: 120
  ttlSecondsAfterFinished: 600
  template:
    metadata:
      labels:
        app: report-once
    spec:
      restartPolicy: Never
      containers:
        - name: report
          image: busybox:1.36
          command:
            - sh
            - -c
            - |
              echo "job start: $(date)"
              echo "generate report for demo"
              sleep 3
              echo "job done"

kubectl apply -f job-report.yaml
kubectl get jobs,pods -n demo
kubectl logs job/report-once -n demo

kubectl get jobs 的 COMPLETIONS 列从 0/1 变成 1/1，STATUS 变成 Complete，就说明任务成功结束。kubectl logs job/report-once 会输出 job start 到 job done 三行——logs 支持直接写 job/<名字>，不用先去查 Pod 名。

任务完成后 Pod 不会自动消失，这是有意设计的：留着给你看日志。不想等 ttlSecondsAfterFinished 就手动删：kubectl delete job report-once -n demo。

CronJob：把 Job 按时间表重复#

CronJob 就是「按 cron 表达式定期创建 Job」的控制器。它的 schedule 用标准 cron 格式，五个字段，没有秒：

几个常见写法：

@yearly、@monthly、@weekly、@daily、@hourly 这些宏也可以直接用。写六个字段（多一个秒）会直接被 API Server 拒绝。

另外三个控制行为的字段：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: report-hourly
  namespace: demo
spec:
  schedule: "*/5 * * * *"
  timeZone: "Asia/Shanghai"
  concurrencyPolicy: Forbid
  startingDeadlineSeconds: 60
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      backoffLimit: 2
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: report
              image: busybox:1.36
              command:
                - sh
                - -c
                - 'echo "tick $(date)"'

kubectl apply -f cronjob-report.yaml
kubectl get cronjobs -n demo
kubectl get jobs -n demo -w

kubectl get cronjobs 的 SCHEDULE 是 */5 * * * *，SUSPEND 是 False，ACTIVE 在有任务运行时大于 0。等最多 5 分钟，就能看到 kubectl get jobs 里冒出一个名字形如 report-hourly-28934567 的 Job（后缀是时间戳换算出来的数字）。

时区与并发策略的注意事项#

这两个配置的坑最隐蔽，因为配错了任务照样「跑成功」，只是跑的时间点或次数不对。

• 时区：cron 表达式默认按 kube-controller-manager 的时区解释，而控制器通常跑在 UTC 环境里，于是你写的「凌晨 3 点」实际是 UTC 03:00，在国内就是上午 11 点。spec.timeZone 在 1.27 起稳定可用，写上 "Asia/Shanghai" 才和你的直觉一致；更旧的集群会忽略这个字段，只能自己把时间换算成 UTC。
• 并发：Allow 是默认值，任务耗时超过间隔时就会叠着跑，一起压数据库。耗时不确定的定时任务建议用 Forbid；用 Replace 要想清楚「旧任务被中途杀掉」是否可以接受。
• 错过窗口：startingDeadlineSeconds 太小（比如 1），控制器重建、节点重启这类抖动就会让这一轮被直接跳过；不设时它只受「最多补 100 个错过的任务」限制。

动手练习：完成、失败重试与手动触发#

kubectl create namespace demo

apiVersion: batch/v1
kind: Job
metadata:
  name: job-ok
  namespace: demo
spec:
  backoffLimit: 2
  ttlSecondsAfterFinished: 600
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: work
          image: busybox:1.36
          command: ["sh", "-c", "echo start; sleep 5; echo done"]

kubectl apply -f job-ok.yaml
kubectl get job job-ok -n demo -w              # COMPLETIONS 从 0/1 走到 1/1
kubectl get pods -n demo -l job-name=job-ok    # STATUS: Completed
kubectl logs -n demo -l job-name=job-ok        # start / done

apiVersion: batch/v1
kind: Job
metadata:
  name: job-fail
  namespace: demo
spec:
  backoffLimit: 2
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: work
          image: busybox:1.36
          command: ["sh", "-c", "echo trying; exit 1"]

kubectl apply -f job-fail.yaml
kubectl get pods -n demo -l job-name=job-fail -w
kubectl describe job job-fail -n demo | grep -A5 Events
kubectl get job job-fail -n demo

kubectl apply -f cronjob-report.yaml
kubectl create job --from=cronjob/report-hourly manual-run -n demo
kubectl get job manual-run -n demo              # COMPLETIONS 1/1
kubectl logs job/manual-run -n demo             # tick <当前时间>

kubectl delete job job-ok job-fail manual-run -n demo
kubectl delete cronjob report-hourly -n demo
kubectl get jobs,pods -n demo

常见坑与排错#

自测题#

小结#

• Deployment 管「一直运行」，Job 管「跑完结束」，CronJob 管「按时创建 Job」，三者语义不能混用。
• completions 定总量、parallelism 定并发、backoffLimit 定重试、activeDeadlineSeconds 定超时，ttlSecondsAfterFinished 负责自动清理。
• Job 的 Pod 必须显式写 restartPolicy，只能是 Never 或 OnFailure。
• CronJob 的 schedule 是五字段标准 cron，没有秒；时区要看 timeZone 是否被集群支持，并发策略默认 Allow 意味着允许重叠。
• kubectl create job --from=cronjob/<名字> 是验证定时任务最省事的方式。

相关章节：第 6 章 Deployment：副本、滚动更新与回滚 讲的是常驻负载；第 15 章 排障手册 里的固定排查顺序同样适用于 Job 的 Pod。

练习#

1. 把 job-report.yaml 的 completions 改成 5、parallelism 改成 2，观察 kubectl get pods 里 Pod 的出现节奏和 kubectl get jobs 的 COMPLETIONS 变化。
2. 把 Job 里的命令改成 exit 1，观察 backoffLimit 生效的过程，并用 kubectl describe job 找出最终失败的原因。
3. 写一个 schedule: "*/1 * * * *" 的 CronJob，配 concurrencyPolicy: Forbid，观察 ACTIVE、LAST SCHEDULE 两列在几分钟内的变化。

到这里，我们已经能描述「什么任务、跑几个副本、跑多久」了。但 Pod 最终要落在哪台节点上，是由谁决定的？下一章我们讲调度：节点选择、亲和性、污点与容忍。