K8s HPA环境下新Deployment Pod异常，如何避免停机处理？

一、先解决Pod启动失败的核心问题 #

1. 处理CPU资源不足 #

• 先查节点CPU使用情况：kubectl describe nodes，重点看Allocated resources下的CPU请求/限制占比
• 应急方案：
  • 云集群直接扩容节点组，快速补充CPU资源；自建集群可临时添加新节点
  • 临时调低新Deployment的Pod CPU请求（确保业务能正常运行的前提下），修改Deployment的spec.template.spec.containers[].resources.requests.cpu，让调度器能找到合适节点

2. 处理节点污点未容忍 #

• 先查节点污点：kubectl describe node <节点名称> | grep Taints，记下污点的key、value和effect
• 在新Deployment的Pod模板里添加容忍配置：

  tolerations:
  - key: "你的污点key"
    operator: "Equal"
    value: "你的污点value"
    effect: "NoSchedule" # 对应污点的effect，可能是NoSchedule/NoExecute/PrefersNoSchedule
  

二、避免发布停机的优化操作 #

1. 调整滚动更新策略 #

默认滚动更新可能在新Pod起不来时仍尝试替换旧Pod，改成以下配置确保零停机：

strategy:
  rollingUpdate:
    maxSurge: 1 # 最多额外创建1个Pod（不超过HPA的MAXPODS）
    maxUnavailable: 0 # 发布期间必须保持所有Pod可用
  type: RollingUpdate

这样新Pod必须成功进入Running状态并就绪后，才会删除旧Pod。

2. 结合HPA做冗余发布 #

当前HPA的MIN=3、MAX=5，副本数3且CPU使用率远低于阈值，发布前：

• 先手动扩容到4：kubectl scale deployment web --replicas=4，留足冗余
• 再执行发布，就算新Pod起不来，仍有3个旧Pod正常提供服务
• 问题解决后，HPA会自动把副本数调回3（因为CPU使用率低）

3. 紧急情况的正确回滚方式 #

别直接删Deployment，用回滚命令快速恢复：

• 回滚到上一个正常版本：kubectl rollout undo deployment web
• 查看回滚进度：kubectl rollout status deployment web
  这个操作会逐步恢复旧Pod，不会导致全量停机

三、长期优化建议 #

• 给Pod配置合理的CPU/内存请求和限制，让调度器能精准分配资源
• 梳理节点污点规则，明确哪些Pod需要容忍哪些污点，提前配置到Deployment模板里
• 检查HPA指标采集是否正常（比如metrics-server是否运行），当前CPU使用率0%可能是指标采集有问题，调整HPA阈值到更合理的范围
• 配置就绪探针（readinessProbe），确保新Pod真正就绪后才会被流量接管

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