不扩容怎么查
HPA 不扩容通常是链路上某一环断了，而不是策略本身写错。按「指标是否可得 → 当前副本与就绪数 → 是否已到上限 → 目标值是否合理」的顺序逐层核对，多数问题在前两步就能定位。常见的四种情况是：指标管道异常导致 TARGETS 显示 unknown、容器没有 requests 导致使用率无法计算、副本数已达 maxReplicas、以及新副本迟迟不就绪使有效容量没有真正增加。
现象与原因对照
| 现象 | 常见原因 | 核查方式 |
|---|---|---|
| TARGETS 显示 unknown | 指标管道异常，或容器未声明 requests | 先确认 kubectl top 是否可用，再看 Pod 的 resources |
| 副本等于 maxReplicas | 上限封顶 | 读 spec.maxReplicas 与当前副本数 |
| 扩容后使用率仍高 | 新副本未就绪或流量持续上涨 | 对比 READY 列与就绪副本数 |
| 副本反复增减 | 稳定窗口太短或指标抖动 | 检查 behavior 中 scaleDown 的稳定窗口 |
| 完全没有任何事件 | HPA 未绑定到正确目标 | 确认 scaleTargetRef 的名称与类型 |
典型使用场景
- 压测不扩：先确认指标是否可得，再确认分母 requests 是否存在
- 线上突发未被吸收：核对是否撞上 maxReplicas，或扩容速度被策略限制
- 副本增加但延迟未降：检查新副本是否真正就绪，未就绪的副本不参与负载
- 反复抖动：定位指标来源与稳定窗口设置，避免按瞬时毛刺扩缩
- 多版本共存：确认 HPA 绑定的目标类型与名称无误，防止扩缩了别的对象
按层排查
按层排查
kubectl get hpa -A # 一眼看 TARGETS 列是否为 unknown
kubectl describe hpa web-hpa | sed -n '/Conditions:/,/Events:/p' # Conditions 与 Events 有具体原因
kubectl top pod -l app=web --containers # 指标是否可得
kubectl get deploy web -o jsonpath='{.spec.replicas} {.status.readyReplicas}'
kubectl get deploy web -o jsonpath='{.spec.template.spec.containers[*].resources}' # requests 是否声明
kubectl get hpa web-hpa -o jsonpath='{.spec.maxReplicas} {.spec.behavior}' # 上限与扩缩行为关键字段读法
| 字段 | 含义 | 异常信号 |
|---|---|---|
| TARGETS | 当前指标值 / 目标值 | unknown 表示拿不到数据或无法计算 |
| MINPODS / MAXPODS | 副本上下限 | 当前副本等于上限时不会继续扩 |
| REPLICAS | 当前副本数 | 与 Deployment 的实际副本对不上说明目标绑定异常 |
| Conditions | HPA 的判定说明 | 含 ScalingLimited、FailedGetResourceMetric 等具体原因 |
| behavior | 扩缩速度与稳定窗口 | 窗口过短会导致抖动 |
HPA 与 Deployment 分工明确：HPA 写 spec.replicas，Deployment 负责落实。若同时用流水线或 Operator 声明同一 Deployment 的副本数，两边会互相覆盖，表现为副本数忽上忽下或被改回固定值。
扩容生效到指标回落之间有一个观察窗口：新副本从创建到就绪需要时间，这段时间使用率仍然偏高。判断扩容是否有效要预留这段延迟，否则会误判为「扩了没用」而继续调大策略。