HPA 与发布的关系
HPA（Horizontal Pod Autoscaler）按指标自动扩缩副本数，与发布同时进行时会互相干扰：副本数变化让「按副本比例」估算的金丝雀流量漂移，观测结论失真；发布新增副本与自动扩容同时向同一资源池要容量，新 Pod 可能长时间 Pending。处理思路是解耦：金丝雀改用权重路由，发布期为 surge 预留资源，并持续盯 HPA 事件。
基本信息
| 干扰一 | 副本比例法金丝雀的流量比例随伸缩漂移 |
|---|---|
| 干扰二 | 扩容抢占配额，新 Pod 排队 Pending，就绪变慢 |
| 建议 | 金丝雀用权重路由；发布期监控 HPA 事件 |
| 容量 | 为 maxSurge 预留资源，不依赖 HPA 临时兜底 |
| 观测 | kubectl get hpa -w 与 describe 事件、调度失败事件 |
典型使用场景
- 大促与活动前发布：流量本就在爬坡，先确认资源池余量再动发布
- 按副本比例灰度的集群：伸缩会改变真实流量比例，应改用权重路由
- 资源紧张的命名空间：maxSurge 常因配额不足 Pending，发布前核对配额
- 多服务同窗口发布：多个 HPA 同时扩容，叠加争夺同一节点池
- 伸缩参数调整后：行为与稳定窗口变化会改变发布期节奏，需要重新评估
观察与排查
观察与排查
kubectl get hpa web -w # 持续观察副本数与目标指标变化
kubectl describe hpa web | tail -20 # 查看伸缩事件与触发原因
kubectl get events --field-selector reason=FailedScheduling # 查调度失败
kubectl get pods -l app=web -o wide | grep Pending # 找长期未就绪的新 Pod发布期 HPA 干扰对照
| 干扰 | 表现 | 对策 |
|---|---|---|
| 副本比例漂移 | 灰度流量比例随伸缩变化 | 改用基于权重的路由 |
| 配额竞争 | 新 Pod Pending、扩容受阻 | 发布前核对配额与节点余量 |
| 伸缩震荡 | 指标抖动导致反复扩缩 | 配置伸缩行为与稳定窗口 |
| 就绪变慢 | 新 Pod 与扩容实例抢资源 | 预留资源或错开发布窗口 |
maxSurge 与 HPA 同时向同一资源池要容量：发布窗口与扩容窗口叠加时，先确认可分配资源再开始发布。
金丝雀用权重路由时，副本数怎么变都不影响流量比例，能把发布推进与自动伸缩彻底解耦。