HPA是Horizontal Pod Autoscaler，仅自动扩缩Deployment、StatefulSet或ReplicaSet的副本数，不调整节点数量、不修改容器资源请求/限制，且默认不支持HTTP QPS或延迟等业务指标，需通过metrics-server和prometheus-adapter暴露自定义指标。
HPA 是什么，它能自动扩缩容哪些资源
HPA（Horizontal Pod Autoscaler）只负责调整 Deployment、StatefulSet 或 ReplicaSet 的副本数，不碰节点数量、不改容器资源配置（如 requests/limits），也不支持自定义指标以外的“业务逻辑触发”。它本质是周期性读取指标（CPU、内存或自定义指标），再套公式算出目标副本数。
常见误解：以为 HPA 能根据 HTTP QPS 或延迟自动扩缩——默认不能，必须先接入 metrics-server + prometheus-adapter 或类似组件暴露对应指标。
为什么 kubectl get hpa 显示 unknown 或 missing metrics
这是最常卡住的一步。HPA 无法获取指标时会卡在 unknown 状态，原因通常有三个：
-
metrics-server没装，或没运行在kube-system命名空间且未被 HPA 默认发现 - Pod 未设置
resources.requests（CPU/内存必须设requests，否则指标无基准，HPA 拒绝计算） - 指标类型与 HPA 配置不匹配：比如用
resource: memory但 Pod 只设了 CPU requests
验证方式：kubectl top pods 能查到数据，HPA 才可能工作；如果报 error: Metrics not available for pod，优先排查 metrics-server 日志和 RBAC 权限。
写 HPA YAML 时最容易错的三个参数
HPA 的行为高度依赖这几个字段，稍有偏差就导致不扩、乱扩或抖动：
-
minReplicas和maxReplicas：不是“建议值”，而是硬边界。设成1和1就等于关掉了扩缩容 -
targetAverageUtilization：针对resource类型指标（如 CPU），它算的是「所有 Pod 实际使用量 / requests 的平均百分比」，不是绝对值。设成80表示“让所有 Pod 平均 CPU 利用率尽量靠近 80%”，而非“超过 80% 就扩容” -
behavior.scaleUp.stabilizationWindowSeconds：默认 0，意味着每次采集都可能立刻扩容，极易因瞬时毛刺造成抖动。生产环境建议设为300（5 分钟）以上，配合selectPolicy: Max控制步长
示例片段：
behavior:
scaleUp:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 100
periodSeconds: 60自定义指标扩缩容必须绕过的两个坑
要用 QPS、队列长度等业务指标，光配 HPA 不够，中间链路更易断：
- Prometheus 中指标名带
{}或 label 过多，prometheus-adapter默认不转发。需在 adapter 的rules配置中显式seriesQuery+resources映射，否则 HPA 查不到指标 - HPA 引用指标时用的是
metricName，但该名字必须和 adapter 输出的name完全一致（区分大小写），且selector.matchLabels必须能匹配到对应 Pod 的 label，漏一个就显示failed to get metric
调试技巧：直接调 curl http:// 看是否返回有效 timeseries。
HPA 的“自动”是有延迟、有缓冲、有依赖的——它不感知业务语义，只忠实地执行指标→计算→更新 replicas 的闭环。任何一环的指标不准、延迟高、权限缺，都会让扩缩容变成盲操作。真正稳定的策略，往往靠压测+历史水位+人工干预阈值共同兜底。
