HPA 不扩容是什么情况
HPA 按指标自动调整副本数，但它依赖一条完整链路：metrics-server 采集指标、用 requests 作分母算利用率、与 target 阈值比较、再被 min/max 边界钳制。任何一环缺失都会表现为「压力上来了副本数却不动」，所以排查应从链路端点往回走，而不是先调阈值。
基本信息
| 看状态 | kubectl describe hpa 看 Current/Target 与 Events |
|---|---|
| 指标来源 | metrics-server 提供 Pod 与节点的资源指标 |
| 分母 | CPU 利用率按 requests 计算，未设 requests 则指标 unknown |
| 边界 | minReplicas 与 maxReplicas 决定调整范围 |
| 行为策略 | behavior 的稳定窗口主要影响缩容速度 |
| API 版本 | autoscaling/v2 才支持多指标与 behavior |
不扩容的原因与处置
| 现象 | 原因 | 处置 |
|---|---|---|
| Current 显示 unknown | requests 未设或指标取不到 | 补 requests，检查 metrics-server |
| 有数值但不越过 target | 阈值偏高或负载未达预期 | 核对目标利用率与真实压测值 |
| 已等于 maxReplicas | 上限钳制 | 提高上限并确认节点还有资源 |
| 副本涨了但服务没变快 | 新 Pod 卡 Pending 或未就绪 | 查调度与就绪探针 |
| Events 报 failed to get metrics | metrics-server 异常 | 看其日志与聚合层状态 |
排查命令
排查命令
kubectl get hpa # 看 Current 与 Targets
kubectl describe hpa web # Events 常有明确原因
kubectl top pods # 指标管道是否真有数据
kubectl get deploy web -o jsonpath='{.spec.replicas} {.status.readyReplicas}'
kubectl logs -n kube-system deploy/metrics-server --tail=50 # 指标服务是否报错
kubectl get apiservice v1beta1.metrics.k8s.io # 聚合层是否可用典型使用场景
- 压测时 CPU 打满但副本不动，需要先确认指标是否真的采到
- 新服务刚配 HPA 就不工作，常见原因是漏写 resources.requests
- 副本扩出来了请求仍超时，实际卡在调度或就绪探针
- 缩容过于激进导致流量抖动，需要调 behavior 的稳定窗口
- 多指标联合扩缩容不生效，需要确认是否用了 v2 版本与正确的指标类型
resources.requests 没设时 CPU 利用率没有分母，HPA 会一直显示 unknown；先补齐 requests 再谈阈值调优，顺序颠倒会浪费大量时间。
扩容生效不等于服务立刻变快：新 Pod 要经过调度、镜像拉取、就绪探针三段，期间容量并未增加，容量规划要把这段预热时间算进余量。
只盯 HPA 不看 Deployment 会得出错误结论：扩出的 Pod 卡在 Pending 或未就绪时，副本数上升而真实容量没提升。