Kubernetes CronJob启动失败：‘超时’与‘Job已存在’问题排查

嘿，我来帮你拆解下这两个困扰你的CronJob错误，都是K8s 1.9.x版本里比较典型的问题，结合AWS环境的特性，咱们一步步来分析：

1. 报错：Error creating job: jobs.batch "dev-cron-1516702680" already exists #

这个问题的核心原因是Kubernetes 1.9.x版本的CronJob控制器存在重试逻辑缺陷：

• 当CronJob尝试创建Job时，如果第一次请求因为超时（就是你遇到的第二个错误）没有收到API Server的确认，控制器会自动重试创建请求；但实际上第一次请求可能已经成功在etcd中创建了Job记录，这时候重试就会触发“Job已存在”的报错。
• 再加上你的concurrencyPolicy设为Allow，控制器会允许并发创建Job，进一步放大了这个重复创建的概率。

对应解决方案： #

• 调整并发策略：如果你的定时任务不需要同时运行多个实例，把concurrencyPolicy改成Forbid（不允许并发，前一个Job未完成则跳过新的）或者Replace（用新Job替换未完成的旧Job），这样控制器不会频繁尝试创建新Job。
• 升级K8s版本：这个重试逻辑的bug在Kubernetes 1.9.7及以上的小版本已经修复，建议你把集群升级到1.9.x的最新稳定版，或者直接升级到1.10+的版本，从根源上解决问题。
• 临时清理重复Job：如果已经出现重复的Job，可以手动删除：

  kubectl delete job dev-cron-1516702680 -n dev
  

2. 报错：Error creating job: Timeout: request did not complete within allowed duration #

这个超时问题主要和API Server/etcd的响应延迟或者你的配置限制有关：

• 你的startingDeadlineSeconds设为10秒，这个时间太短了——AWS环境下，控制节点如果资源紧张（CPU/内存不足）、etcd磁盘IO性能差（比如用了低性能的EBS卷），都会导致API请求的响应时间超过10秒，触发超时。
• 另外，K8s 1.9.x的API Server本身对请求的超时处理也比较严格，遇到集群负载高的时候很容易触发这类报错。

对应解决方案： #

• 延长启动截止时间：把startingDeadlineSeconds从10改成60（甚至更长，比如300），给CronJob控制器足够的时间完成Job创建请求。
• 检查控制节点资源：登录AWS控制台查看控制节点的CPU、内存使用率，如果持续偏高，考虑升级实例类型，或者增加控制节点数量（高可用集群）。
• 检查etcd健康状态：用以下命令查看etcd组件状态：

  kubectl get componentstatuses
  

  如果etcd状态异常，检查它的磁盘IO、CPU使用率，必要时更换更高性能的EBS卷（比如gp3或者io2）。

针对你的YAML配置的修改建议 #

这里给你调整后的关键配置片段，你可以直接替换原配置：

spec:
  concurrencyPolicy: Forbid  # 替换原Allow，避免并发创建
  startingDeadlineSeconds: 60  # 延长超时时间
  # 其他配置保持不变

内容的提问来源于stack exchange，提问作者Reynaldi Wijaya