Kubernetes CronJob 怎样避免任务并发运行

如果一个 Kubernetes CronJob 每分钟触发一次，而任务本身要运行两分钟，默认配置可能让前一个 Job 还没结束时又创建新的 Job。要避免同一个 CronJob 的任务重叠，最直接的设置是 spec.concurrencyPolicy: Forbid：上一轮未完成时跳过这次调度，不创建并行 Job。

官方地址：https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/

只想避免同一个 CronJob 的 Job 同时运行时，用 Forbid；如果允许新一轮替换旧任务，才考虑 Replace。Forbid 是跳过，不是把每一次错过的执行排成队等待。

• 默认行为：Allow 允许同一个 CronJob 的多个 Job 并发运行。
• 防重叠：Forbid 在上一轮未完成时跳过本轮调度。
• 替换任务：Replace 会用新 Job 替换仍在运行的 Job，适合旧结果可以被新结果取代的任务。

先确认并发问题来自同一个 CronJob

concurrencyPolicy 只作用于同一个 CronJob 创建的 Job。两个名称不同的 CronJob，即使 schedule 一样，也不会因为其中一个设置了 Forbid 就互相等待。因此，先看清楚 Job 的 owner 关系和 CronJob 名称，再决定是否需要修改配置。

从资源关系看，CronJob 保存 schedule 和 Job 模板，控制器按模板创建 Job，Job 再负责 Pod 和容器。并发策略位于 CronJob 层，约束的是同源 Job，不是整个命名空间的全局互斥。

在 CronJob 中设置 Forbid

下面的清单把任务设置为每分钟触发一次，并明确指定 Forbid。示例中的容器命令只是一个持续一段时间的占位任务，目的是让读者能看出重叠窗口；实际项目应替换成自己的备份、同步或报表命令。

apiVersion: batch/v1
kind: CronJob
metadata:
  name: report-refresh
spec:
  schedule: "*/1 * * * *" # 每分钟创建一次执行机会
  concurrencyPolicy: Forbid # 上一轮未完成时跳过本轮，不创建并行 Job
  startingDeadlineSeconds: 50 # 只接受调度后 50 秒内的迟到执行
  jobTemplate:
    spec:
      backoffLimit: 1 # 失败后最多再尝试一次，避免错误任务无限重试
      template:
        spec:
          restartPolicy: Never # 让 Job 负责失败结果，不在 Pod 内无限重启
          containers:
            - name: report-refresh
              image: busybox:1.36
              command: ["sh", "-c"]
              args:
                - |
                  # 用占位任务模拟一个需要较长时间的报表刷新
                  echo "refresh started"
                  sleep 90
                  echo "refresh finished"

这里最关键的是两处：concurrencyPolicy: Forbid 决定重叠时跳过，startingDeadlineSeconds 决定迟到多久仍可接受。它们不是同一个开关，前者解决重叠，后者限制延迟执行。

用 kubectl 查看配置和同源 Job

应用清单后，先查看 CronJob 的配置，再列出它创建的 Job。下面命令只展示检查方法，不代表本文在真实集群中执行过。

# 创建或更新 CronJob 配置
kubectl apply -f report-refresh.yaml

# 查看并发策略、调度表达式和最近状态
kubectl get cronjob report-refresh -o wide
kubectl describe cronjob report-refresh

# 只筛选这个 CronJob 产生的 Job，避免把其它任务混进判断
kubectl get jobs -l cronjob-name=report-refresh \
  -o custom-columns=NAME:.metadata.name,ACTIVE:.status.active,SUCCEEDED:.status.succeeded,FAILED:.status.failed

判断时关注三点：CronJob 的并发策略是否显示为 Forbid；同一时间是否只有一个相关 Job 处于 active；上一轮运行时，新的计划时间是否没有产生第二个同源 Job。若任务已经完成，后续时间点仍可以创建新的 Job，这不属于并发。

Forbid、Replace 和 Allow 到底怎么选

三种策略的差别不在于“哪个更严格”，而在于重叠发生时你希望保留什么结果：

别把跳过的调度误解成自动排队

使用 Forbid 时，如果到了计划时间而上一轮 Job 仍在运行，这个时间点会被视为 missed schedule。官方文档说明，上一轮完成后是否产生迟到执行，还要结合 startingDeadlineSeconds 判断；因此不能把 Forbid 理解成“每个时间点都保证最终执行一次”。

例如任务每分钟运行一次，但一次执行持续三分钟：

• 第 1 分钟创建 Job A。
• 第 2、3 分钟因为 Job A 仍在运行，新的同源执行机会可能被跳过。
• Job A 完成后，控制器是否接受某个迟到时间点，要看截止时间和控制器的调度判断。

如果业务不能丢失每个时间窗口，不能只靠 Forbid；应让任务具备幂等能力，并在业务记录中保存窗口、状态和补偿策略。Kubernetes 官方也提醒 CronJob 调度是近似的，任务应设计成幂等。

生产环境还要补上的三个边界

1. 任务本身要幂等：即使设置了 Forbid，调度器仍不是业务数据库锁，任务应能安全处理重复或迟到输入。
2. 不要把它当全局锁：它只约束同一个 CronJob；多个 CronJob、手工创建的 Job 或外部系统触发的任务不在同一策略范围内。
3. 谨慎使用 Replace：如果旧任务写入文件、数据库或外部系统时不能被安全中断，替换可能留下半成品，应该优先使用 Forbid 或业务层协调。

修改 CronJob 只会影响之后启动的新 Job，已经运行的 Job 和 Pod 不会因为修改了模板或策略而自动改变。排查时要把“新配置”和“已有执行”分开看。

常见问题

Forbid 会让错过的任务自动补跑吗？

不等于自动排队。它首先阻止重叠创建；错过的时间点是否在任务完成后被接受，还要受 startingDeadlineSeconds 和 CronJob 控制器的调度判断影响。

多个 CronJob 设置 Forbid 后会互相等待吗？

不会。并发策略只约束同一个 CronJob 创建的 Job。多个 CronJob 之间需要独立的业务协调机制。

任务只要不并发，就不需要幂等了吗？

仍然需要。CronJob 的调度是近似的，可能出现重复或没有创建的情况；幂等让任务在重试、迟到或人工恢复时更安全。