启用自动扩缩容仍遇CPU不足及Pod调度失败问题求助

一、Node.js服务Insufficient cpu告警问题 #

• 核心原因：Autopilot集群的Pod调度依据资源请求值（resources.requests）而非实际使用率。哪怕你的应用仅返回'hi'，如果Pod的CPU请求设置超过了调度时集群内节点的剩余CPU资源，就会触发告警。Autopilot随后会自动扩容节点，Pod得以运行，但后续构建时，新Pod调度前若没有匹配的节点资源，仍会触发告警。
• 排查与修复步骤：
  1. 检查Pod资源配置：查看Deployment的YAML中resources.requests.cpu的设置，若请求值过高（比如默认0.5vCPU），可适当调低（比如0.1vCPU），降低调度时的资源门槛。
  2. 检查集群LimitRange：若集群配置了默认资源请求（通过LimitRange），会自动给Pod分配默认CPU请求，可通过kubectl get limitrange查看并调整。
  3. 后续告警处理：Autopilot节点扩容后不会立即缩容，但每次新Pod调度时，若节点剩余资源刚好不足，仍会短暂触发告警，属于正常调度流程，调低资源请求可减少告警频率。

二、MongoDB Pod存储卷挂载失败问题 #

• 访问模式误区：GCE持久化磁盘（PD）不支持ReadWriteMany访问模式，仅支持ReadWriteOnce（单节点挂载），修改为ReadWriteMany反而会导致调度失败，因为没有匹配的存储后端。
• 排查与修复步骤：
  1. 查看Pod详细事件：执行kubectl describe pod <mongo-pod-name>，找到存储卷挂载的具体错误信息，常见原因包括旧Pod未彻底释放磁盘、PV/PVC绑定异常、磁盘配额不足。
  2. 检查PVC与PV状态：执行kubectl get pvc，确认PVC处于Bound状态；若为Pending，需检查PVC的存储类（storageClassName）是否为standard-rwo（GCE PD默认存储类）。
  3. 清理残留资源：若之前的Mongo Pod删除后磁盘未正确卸载，可删除现有PVC并重新创建（注意备份数据），避免磁盘挂载冲突。
  4. 检查Autopilot存储限制：Autopilot对单节点挂载的磁盘数量、单磁盘大小有上限，确保PVC的storage请求在允许范围内（比如单磁盘最大10TB，单节点最多挂载16块PD）。

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