AKS集群升级遇PodDrainFailure失败，副本数修改后自动回退求助

问题核心 #

AKS集群升级触发PodDrainFailure，根源是某PDB的Allowed Disruptions为0；手动将对应Deployment副本数改为2后，PDB允许中断数临时变为1，但副本数很快自动回退为1，导致问题复发。

副本数自动回退的常见原因及解决方法 #

1. 水平Pod自动扩缩容（HPA）干预 #

如果Deployment关联了HPA，且HPA的minReplicas设为1，手动调整副本数到2后，HPA会根据预设的扩缩容规则（比如CPU/内存使用率）将副本数拉回最小值。

• 检查HPA配置：

  kubectl get hpa <deployment_name>
  

• 临时调整HPA最小副本数：

  kubectl scale hpa <deployment_name> --min=2
  

• 或临时禁用HPA缩容：

  kubectl annotate hpa <deployment_name> autoscaling.kubernetes.io/scale-down-disabled=true
  

2. GitOps工具（Argo CD/Flux）同步覆盖 #

如果Deployment由GitOps工具管理，集群中的配置会和Git仓库中的定义自动同步。手动修改集群内的副本数后，工具会将其覆盖回仓库中设定的1。

• 检查GitOps应用状态（以Argo CD为例）：

  argocd app get <app_name>
  

• 解决方法：先在Git仓库中修改Deployment的spec.replicas为2，再触发GitOps工具同步，确保集群配置与仓库一致。

3. 其他自动化配置工具/脚本 #

存在定时任务、运维脚本或自定义控制器自动修改Deployment副本数，也会导致手动配置被覆盖。

• 查看Deployment事件记录，定位修改源：

  kubectl describe deployment <deployment_name>
  

  检查Events中是否有Scaled down replica set类事件，记录中的触发方即为修改源，针对性调整该工具/脚本的逻辑。

临时应急方案（用于紧急完成AKS升级） #

如果暂时无法解决副本数回退问题，可直接修改PDB的允许中断数，跳过驱逐限制：

kubectl patch pdb <pdb_name> -p '{"spec":{"maxUnavailable":1}}'

完成集群升级后，再恢复PDB配置并彻底解决副本数自动回退的根源问题。

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