GCP Autopilot模式Kubernetes集群Pod无法调度、自动扩缩容失效

问题根因 #

从你提供的Pod事件信息可直接定位故障根源：

1. 单个Pod总资源请求为3核CPU + 10Gi内存（odoo-service请求2核8Gi + cloud-sql-proxy请求1核2Gi），现有2个集群节点的剩余CPU、内存均无法满足调度要求
2. 集群自动扩缩容触发失败进入退避期：日志中4 in backoff after failed scale-up标识此前集群尝试扩容新节点失败，目前处于扩容冷却周期，暂不会触发新的扩容操作
3. 该Pod QoS等级为Guaranteed，调度时要求节点有完全匹配的预留资源，进一步提高了调度门槛
4. 你无法直接删除Pending Pod是因为该Pod由ReplicaSet托管，删除后会被控制器自动重建，所以看起来删除操作不生效

调试操作步骤 #

• 确认GCP项目资源配额：
  执行gcloud container clusters describe [集群名] --zone [集群所在可用区]查看集群节点配置上限，同时核对项目Compute Engine对应可用区的CPU、内存配额是否已经耗尽，这是Autopilot模式扩容失败最常见的原因
• 查看自动扩缩容详细日志：
  执行kubectl describe configmap cluster-autoscaler-status -n kube-system查看扩容失败的具体错误，确认是配额不足、可用区无对应规格资源还是权限配置问题
• 核对节点实际资源占用：
  执行kubectl describe nodes查看每个节点的已分配资源，确认节点剩余资源确实无法承载该Pod的总请求

修复方案 #

• 临时恢复方案：调低Pod的资源请求值，修改对应Deployment的resources.requests配置，将总CPU请求降到2核以内、总内存降到8Gi以内，调整后Pod会自动重建并完成调度
• 解决扩容失败问题：
  1. 若为项目配额不足，提交GCP配额申请提升对应可用区的CPU、内存配额
  2. 若为当前可用区无匹配Pod资源规格的计算资源，可调整集群的可用区配置，或调整Pod的资源请求适配当前可用区的在售实例规格
  3. 若此前扩容为偶发失败，等待30分钟内扩容退避期结束后，自动扩缩容会再次尝试扩容节点
• 解决Pod无法删除问题：若不需要该服务，直接删除对应的Deployment即可，命令为kubectl delete deployment odoo-cluster-dev，无需单独删除Pod

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