求助：EKS托管节点组中Deployment副本自动缩容至零如何阻止

Deployment本身不会主动修改副本数，你已经排除了常规水平扩缩容策略，可从以下方向排查并解决：

1. 定位副本数修改的来源 #

先确认Deployment的spec.replicas字段确实被改为0，通过事件日志找到触发者：

kubectl describe deployment <你的Deployment名称> -n <应用命名空间>

查看输出的Events区域，寻找类似Scaled deployment <deployment-name> to 0的记录，其中From字段会标注触发修改的主体（如GitOps控制器、服务账号、定时任务等）。

2. 排查GitOps工具影响 #

如果用了Argo CD、Flux这类GitOps工具，检查代码仓库中对应的Deployment配置文件，确认spec.replicas是否被设为0，或者同步策略是否强制覆盖集群配置。调整仓库中的配置或同步规则即可。

3. 检查AWS Application Auto Scaling #

即使你未手动关联扩缩容策略，可能存在遗留的Application Auto Scaling配置针对该Deployment设置了缩容规则。用AWS CLI检查：

aws application-autoscaling describe-scaling-policies --service-namespace kubernetes --resource-id deployment/<应用命名空间>/<你的Deployment名称>

如果返回相关策略，执行以下命令删除：

aws application-autoscaling delete-scaling-policy --policy-name <策略名称> --service-namespace kubernetes --resource-id deployment/<应用命名空间>/<你的Deployment名称>

4. 排查定时任务或自定义控制器 #

检查集群中是否存在CronJob或自定义控制器，执行了kubectl scale deployment ... --replicas=0这类命令：

• 查看命名空间下的CronJob：

  kubectl get cronjob -n <应用命名空间>
  

• 检查所有命名空间下的自定义控制器Pod：

  kubectl get pods -A -l <控制器标签>
  

找到后删除对应的定时任务或控制器即可。

5. 验证Cluster Autoscaler行为 #

Cluster Autoscaler只会调整节点数量，不会修改Deployment副本数，但如果节点缩容时Pod因调度约束（如nodeSelector、affinity）无法重新调度，可能出现Pod全部被驱逐但未重建的情况。此时：

• 检查Pod的调度配置，确保集群中有符合条件的节点；
• 调整Cluster Autoscaler的缩容延迟（默认10分钟），避免节点过快被回收：修改kube-system下的cluster-autoscaler ConfigMap，调整scale-down-unneeded-time参数。

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