为什么我的Kubernetes CronJob Pod执行过程中会被主动杀死？

问题排查结论与解决方案 #

首先明确你提到的参数疑问 #

• 首次拉镜像耗时40秒不会触发startingDeadlineSeconds限制：这个参数是CronJob层面的调度超时阈值，仅用于判断「错过预设调度时间的任务」是否还需要补执行，和Pod启动后的镜像拉取、运行耗时完全无关。
• 也不会触发activeDeadlineSeconds限制：你配置的360秒是Job的总运行时长上限，从Job创建到第一个Pod被杀死仅耗时1分16秒，远低于阈值。

核心问题根因方向 #

你配置的restartPolicy: Never + backoffLimit: 0组合下，Job只要检测到Pod内容器非0退出，就会直接标记任务失败。从事件看两次Pod启动后都在10秒左右被终止，本质是容器内进程异常退出触发了Job的失败逻辑。

可落地的排查步骤 #

1. 获取容器退出码定界方向
   执行以下命令查看失败Pod的退出码：

kubectl get pod development-scale-down-manual-xwp1k-b858c -o jsonpath='{.status.containerStatuses[0].state.terminated.exitCode}'

• 若退出码为137：说明进程被SIGKILL信号终止，优先排查两个方向：对应节点是否存在内存/CPU压力（执行kubectl describe node aks-burst-37275452-vmss00000d查看节点Pressure状态）、是否有集群级别的Pod清理规则（比如节点污点驱逐、安全策略拦截）。
• 若退出码为其他非0值：说明是容器内的业务进程主动异常退出，优先排查权限/网络问题。

2. 业务进程异常排查方向
   你本地运行正常、集群运行失败，大概率是集群运行环境和本地有差异：

• 确认scaler-secrets中存储的SP认证信息是否正确、是否有对应Azure资源的操作权限；
• 确认运行Pod的AKS节点是否有访问Azure管理API的出站权限，尤其是你第一次运行Pod的aks-burst节点组，是否配置了特殊的网络策略、NSG规则限制了出站访问；
• 不要使用latest标签的镜像，固定具体的镜像版本号，避免集群拉取的镜像和本地测试的镜像版本不一致。

3. 调试窗口不足的解决方案
   临时修改CronJob的容器启动命令，让进程退出后容器不立刻销毁，方便你进入容器排查日志和运行环境：

command: ["/bin/sh", "-c"]
args: ["你的原启动命令; sleep 300"]

修改后重新触发任务，容器进程退出后会等待5分钟才会终止，你有足够时间执行kubectl exec进入容器查看运行日志、手动执行Azure CLI命令复现问题。

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