AWS EKS集群prod命名空间Pod自动重启且副本数异常增加排查求助

可能的问题原因及对应解决步骤 #

1. 残留的CronJob/Job资源未彻底清理 #

虽然已移除目标CronJob，但可能存在以下遗留问题：

• CronJob删除时未清理关联的Finalizer，导致资源未完全终止，仍在后台触发任务；
• 历史生成的Job未被彻底删除，部分异常Job仍在周期性执行；
• 其他命名空间的CronJob拥有跨命名空间修改资源的RBAC权限，意外操作了prod命名空间。

解决步骤：

• 检查全集群CronJob：kubectl get cronjobs --all-namespaces，确认无针对prod命名空间的定时任务；
• 清理prod下的历史Job：kubectl get jobs -n prod列出所有Job，删除可疑旧任务：kubectl delete job <job-name> -n prod；
• 强制清理残留CronJob的Finalizer：如果之前的CronJob仍有记录，执行kubectl patch cronjob <old-cronjob-name> -n prod -p '{"metadata":{"finalizers":null}}'。

2. 节点或集群层面的定时运维脚本 #

之前的滚动重启逻辑可能被写入了EKS节点的crontab，或存在其他自动化工具（如Terraform、Ansible）的定时任务，在午夜触发Deployment修改。

解决步骤：

• 登录prod Pod所在的EKS节点，检查root用户及应用相关用户的crontab：crontab -l，排查是否有修改K8s资源的定时脚本；
• 检查团队使用的自动化工具（如Ansible Tower、Terraform Cloud）的任务日志，确认午夜时段无针对prod Deployment的变更操作；
• 查看K8s API Server审计日志（若已启用），定位变更来源：

  kubectl logs -n kube-system <api-server-pod-name> | grep -E "prod.*deployment.*(scale|patch)" | grep -E "23:59|00:[0-9]{2}"
  

3. Argo CD应用配置的隐藏覆盖或异常同步 #

虽然Helm Chart副本数设为1，但Argo CD的应用配置可能存在以下问题：

• Application资源中配置了values覆盖，将副本数设为2，且该配置在午夜被触发生效；
• 使用了外部配置源（如Helm Secrets），该源在午夜发生变更导致副本数被覆盖；
• 自动同步策略配置错误，导致Argo CD在同步时错误调整副本数（需反向验证：临时禁用自动同步，观察午夜是否仍出现变更）。

解决步骤：

• 查看Argo CD Application的详细配置：kubectl get application <app-name> -n argocd -o yaml，检查spec.source.helm.values或spec.source.helm.valueFiles中是否存在副本数覆盖；
• 查看Argo CD应用的历史同步记录，确认午夜时段的同步操作是否有异常变更；
• 临时禁用Argo CD的自动同步功能，观察次日午夜是否仍会出现副本数变更，以此排除Argo CD的影响。

4. 应用自身逻辑或第三方依赖的异常触发 #

部分应用可能在启动时调用K8s API修改自身Deployment的副本数，而午夜的Pod重启（可能由节点维护、证书过期等原因触发）导致该逻辑执行。

解决步骤：

• 检查应用代码或启动脚本，确认是否存在调用K8s API修改replicas字段的逻辑；
• 检查Pod使用的证书、配置文件是否在午夜时段过期，导致Pod重启；
• 查看Pod的启动日志：kubectl logs <pod-name> -n prod --previous，排查重启时是否有异常行为触发副本数变更。

5. Kubernetes Deployment的滚动更新策略或PDB的意外影响 #

若Deployment的rollingUpdate策略配置了maxSurge为1，结合Pod中断预算（PDB）的限制，可能在重启时临时将副本数增至2，但正常情况下重启完成后会回退到1。如果未回退，可能是更新过程中出现异常。

解决步骤：

• 查看Deployment的滚动更新配置：kubectl get deployment <deploy-name> -n prod -o yaml | grep -A5 rollingUpdate；
• 检查Pod中断预算配置：kubectl get pdb -n prod，确认是否存在过于严格的PDB导致副本数无法回退；
• 手动触发一次Deployment滚动更新，观察副本数是否会自动回退到1，验证配置逻辑是否正常。

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