升级到Kubernetes 1.21后CronJob清理作业报错问题求助

算力阿峰

2026-10-13

报错原因

你遇到的是Kubernetes 1.21版本默认启用CronJob v2控制器后出现的典型乐观锁冲突问题，具体成因如下：

该报错the object has been modified; please apply your changes to the latest version and try again是Kubernetes资源版本校验的标准报错，本质是多个主体同时修改同一个CronJob资源时，后提交的修改携带的resourceVersion已经落后于etcd里存储的最新版本，被Kubernetes API服务拒绝。
Kubernetes 1.21首次将CronJob v2控制器设为默认，1.21.3及更早的小版本中，该控制器存在已知的状态同步竞争缺陷：控制器在清理旧Job、更新CronJob运行状态的过程中，会重复触发状态提交，自己和自己产生竞争，进而打印该错误日志。
如果你集群中存在其他自动化工具（比如GitOps同步工具、自定义控制器、定时执行kubectl apply的脚本）也在同步修改该CronJob的标签、注解或配置，会进一步放大冲突的概率。
你观察到Job清理、运行逻辑正常，是因为控制器遇到该报错后会自动将该CronJob加入重试队列，重试后通常都能成功提交修改，仅会产生错误日志，不会影响核心功能。

你之前执行删除重建CronJob没有效果，是因为该问题和CronJob配置本身的正确性无关，属于控制器侧的运行时冲突，重建无法解决。

解决方法

你可以按照优先级依次尝试以下方案：

升级Kubernetes 1.21小版本
如果你当前使用的Kubernetes 1.21小版本低于1.21.4，优先将集群升级到最新的1.21稳定补丁版，上述CronJob v2控制器的原生竞争缺陷已经在后续补丁中修复。
排查并消除并发修改行为
检查集群中是否存在其他同时修改该CronJob资源的逻辑：

确认Argo CD、FluxCD等GitOps工具的同步策略是否会定时覆盖该CronJob配置
确认是否有自定义Operator、定时脚本在调用Kubernetes API修改该CronJob的元数据或配置
调整上述逻辑的执行时机，避免和CronJob控制器的同步周期（默认每分钟一次）重叠即可。

显式配置历史任务保留条数
在你的CronJob配置中显式添加successfulJobsHistoryLimit和failedJobsHistoryLimit字段，不要使用默认值，避免控制器重复计算默认值触发不必要的状态更新，参考配置如下：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: vet-messenger-batch-prod-hourly
spec:
  schedule: "0 * * * *"
  # 新增以下两个字段，数值根据你的需求调整
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: vet-messenger-batch-prod
              image: REDACTED/vet-messenger:prod
              command: ["yarn", "batch:start:prod"]
              imagePullPolicy: Always
              env:
                - name: AWS_ACCESS_KEY_ID
                  valueFrom:
                    secretKeyRef:
                      name: k8s-container-runner-prod
                      key: aws_access_key_id
                - name: AWS_SECRET_ACCESS_KEY
                  valueFrom:
                    secretKeyRef:
                      name: k8s-container-runner-prod
                      key: aws_secret_access_key
                - name: AWS_REGION
                  value: us-east-1
          restartPolicy: Never
      backoffLimit: 1

修改后重新执行kubectl apply -f提交配置即可。
4. 临时回退到旧版本CronJob控制器
如果以上方案都无法解决问题，可以临时回退到v1版本CronJob控制器规避报错：在kube-controller-manager的启动参数中添加--feature-gates=CronJobControllerV2=false，等后续升级到Kubernetes 1.22+版本后再切回v2控制器即可，1.22及以上版本的CronJob v2控制器稳定性已经得到充分验证。

内容的提问来源于stack exchange，提问作者Craig Riecke