如何实现服务自动扩缩容_Kubernetes HPA实战说明

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:///apis/external.metrics.k8s.io/v1beta1/namespaces/default/ 看是否返回有效 timeseries。

HPA 的“自动”是有延迟、有缓冲、有依赖的——它不感知业务语义，只忠实地执行指标→计算→更新 replicas 的闭环。任何一环的指标不准、延迟高、权限缺，都会让扩缩容变成盲操作。真正稳定的策略，往往靠压测+历史水位+人工干预阈值共同兜底。