K8s CronJob 不执行或报错：集群排错步骤与常见原因
CronJob 在 Kubernetes 集群中负责按时间表创建 Job，再由 Job 拉起 Pod 执行任务。
当它“不执行”或“执行报错”时，问题可能出在 CronJob 对象本身、Job 控制器、Pod 调度或容器内部。
下面按从外到内的顺序，给出可逐条执行的排查命令。
先确认 CronJob 的状态和调度时间
执行以下命令查看当前命名空间下的所有 CronJob：
kubectl get cronjob -n 重点关注三列：SCHEDULE 是否是你期望的 cron 表达式，SUSPEND 是否为 False，LAST SCHEDULE 是否有最近一次调度时间。
如果 SUSPEND 为 True，说明任务被手动挂起，需要恢复：
kubectl patch cronjob -n -p '{"spec":{"suspend":false}}' 如果 LAST SCHEDULE 始终为
kubectl describe cronjob -n 在输出中检查 Events 区域，常见提示包括权限不足、无法创建 Job、cron 格式错误等。kubectl describe 不会展示容器内部日志，它只反映控制器层面的问题。
检查 Job 和 Pod 的创建情况
CronJob 到点后应自动创建一个 Job。
列出最近的 Job：
kubectl get jobs -n --sort-by=.metadata.creationTimestamp 如果能看到新 Job 但状态为 0/1，说明 Job 已创建但 Pod 未成功运行。
继续查看 Pod：
kubectl get pods -n -l job-name= 根据 Pod 状态分情况处理：
Pending：通常是资源不足或节点选择器/亲和性不满足。用kubectl describe pod查看 Events，重点看-n FailedScheduling的原因。ImagePullBackOff或ErrImagePull：镜像地址错误、私有仓库凭据缺失或网络不通。检查imagePullSecrets是否配置，或先在节点上手动docker pull验证拉取是否正常。CrashLoopBackOff：容器启动后反复退出。查看日志定位：kubectl logs，-n --previous --previous能看到上一次崩溃的日志。Completed但结果不符：容器正常退出但业务逻辑有问题，需要检查容器内执行脚本和退出码。
权限、并发与历史记录限制
在服务器 K8s 集群 CronJob 排错中，权限和并发配置是最容易被忽略的两类原因。
RBAC 权限不足：如果 CronJob 的 Pod 需要调用 Kubernetes API（例如创建其他资源），但 ServiceAccount 没有对应 Role 或 RoleBinding，Pod 会在启动后因权限被拒绝而报错。
确认 ServiceAccount 是否存在并绑定正确角色：
kubectl get sa -n
kubectl get rolebinding -n | grep 并发策略：CronJob 的 concurrencyPolicy 控制前后两次任务是否允许同时运行。Allow 允许并发，Forbid 禁止并发，Replace 会替换上一次未完成的任务。
如果任务执行时间超过调度间隔，Forbid 会导致后续调度被跳过，表现为“任务有时不执行”。
确认当前策略：
kubectl get cronjob -n -o jsonpath='{.spec.concurrencyPolicy}' 历史记录清理：successfulJobsHistoryLimit 和 failedJobsHistoryLimit 只影响保留的 Job 数量，不会阻止新任务创建。
如果发现旧 Job 堆积，可以适当调小这两个值，但不要设为 0，否则排错时没有历史记录可查。
时区与调度时间偏差
CronJob 的调度时间基于控制器的时区。
在较新的 Kubernetes 版本中，可以通过 spec.timeZone 指定时区；
旧版本默认使用 UTC。
如果你发现任务在“错误的时间”执行，先确认集群版本和时区设置：
kubectl version --short
kubectl get cronjob -n -o jsonpath='{.spec.timeZone}' 没有设置 timeZone 时，cron 表达式按 UTC 解释。
例如你期望每天北京时间 08:00 执行，cron 应写为 0 0 * * *（UTC 00:00）而不是 0 8 * * *。
设置时区需要集群版本支持，不确定时可以先在测试环境验证。
验证与复查清单
修复后不要只看一次结果，建议按以下顺序复查：
- 恢复 CronJob 的
suspend为false。 - 等待一个调度周期，确认
LAST SCHEDULE更新。 - 检查新 Job 是否创建，Pod 是否进入
Running再到Completed。 - 查看 Pod 日志，确认业务输出符合预期。
- 如果再次失败，回到
kubectl describe和 Events 重新定位。
常见疑问
CronJob 到了时间但完全没有 Job 产生，先查什么？
先执行 kubectl describe cronjob 看 Events，再确认 suspend 是否为 true、cron 表达式是否合法。
控制器层的问题通常能在 Events 里直接看到。
Pod 日志显示权限拒绝，但 ServiceAccount 看起来存在，怎么办？
检查 Role 的 rules 是否覆盖了实际调用的 API 资源，以及 RoleBinding 的 subjects 是否指向正确的 ServiceAccount 和命名空间。
权限问题需要同时确认 Role 内容和绑定关系。
任务执行时间较长，后续调度被跳过是正常的吗？
如果 concurrencyPolicy 设为 Forbid，上一次任务未结束时新调度会被跳过，这是预期行为。
需要并发或替换时，改为 Allow 或 Replace，但要评估对业务的影响。
如何快速确认是调度问题还是容器内部问题？
看 Job 是否创建。
Job 没创建是调度层问题，Job 创建了但 Pod 失败是容器或资源问题，Pod 成功但结果不对是业务逻辑问题。
按这个分界逐层排查，能避免在错误的方向上浪费时间。
