并发策略解决什么
CronJob 按时间表创建 Job。如果上一次任务还没结束就到了下一个调度点，concurrencyPolicy 决定怎么办：Allow 允许并发执行（默认），Forbid 跳过本次，Replace 终止仍在运行的旧任务并启动新任务。备份、对账这类要求互斥的任务适合 Forbid；只关心最新一次结果的采集类任务适合 Replace。它只影响是否创建新 Job，不改变 Job 自身的行为。
基本信息
| 适用平台 | batch/v1 的 CronJob |
|---|---|
| 关键字段 | spec.concurrencyPolicy |
| 取值 | Allow（默认，允许并发）｜Forbid（跳过本次）｜Replace（终止旧的、启动新的） |
| 观察入口 | kubectl get cronjob 与 kubectl get jobs |
| 相关字段 | startingDeadlineSeconds 决定错过调度窗口后是否仍尝试补跑 |
典型使用场景
- 数据库备份：绝不允许两个备份同时跑，用 Forbid 保证互斥
- 对账任务：同一账期只能有一次运行，避免重复处理
- 指标采集：只要最新一次结果，用 Replace 让旧任务让位
- 报表生成：长任务配合 Forbid，避免结果互相覆盖
- 批量清理：任务短且互不影响时用默认的 Allow 提高吞吐
配置与观察
配置与观察
apiVersion: batch/v1
kind: CronJob
metadata:
name: backup
namespace: prod
spec:
schedule: "*/5 * * * *"
concurrencyPolicy: Forbid # 允许 Allow｜跳过 Forbid｜替换 Replace
jobTemplate:
spec:
template:
spec:
restartPolicy: Never
containers:
- name: backup
image: registry.example.com/backup:1.4核对与排查
核对与排查
kubectl get cronjob backup -n prod -o jsonpath='{.spec.concurrencyPolicy}'
kubectl get jobs -n prod | grep backup # 是否出现多个并发 Job
kubectl get cronjob backup -n prod -o jsonpath='{.status}' # 看最近调度时间与活动 Job
kubectl describe cronjob backup -n prod | tail -20取值与适用
| 取值 | 行为 | 适用 |
|---|---|---|
| Allow | 允许并发执行，默认值 | 互不影响的短任务 |
| Forbid | 上次未结束则跳过本次 | 必须互斥的备份与对账 |
| Replace | 终止旧任务并启动新任务 | 只关心最新结果的采集 |
| 未显式声明 | 等同 Allow | 容易在生产里意外堆积 Job |
长任务搭配 Allow 会在资源紧张时段堆积多个 Job：并发数不受 CronJob 约束，需要靠任务时长、调度间隔与资源配额一起控制。
Forbid 跳过时不会创建新 Job，也不一定有醒目事件：排查「任务没跑」要同时看 CronJob 状态里的最近调度时间与是否有仍在运行的 Job。
排查「任务没按点跑」的顺序是：先看 CronJob 的最近调度时间，再看是否有并发策略导致跳过，最后才怀疑控制器与节点时间；这一步分开看能避免把并发策略问题当成调度器故障。