Kubernetes HPA 自动扩缩容详解：指标、策略、资源与常见故障

本文只讲 Kubernetes Horizontal Pod Autoscaler，重点覆盖 HPA 原理、Metrics Server、CPU/内存指标、自定义指标、扩缩容策略和生产排障。

一、HPA 是什么

HPA 是 Kubernetes 的水平 Pod 自动扩缩容控制器。它周期性读取指标，根据当前值和目标值计算需要的副本数量，然后修改 Deployment 或其他可扩缩资源的副本数。

HPA 只改变 Pod 副本数，不负责创建节点，也不保证下游数据库、缓存和外部 API 能承受更多流量。如果集群没有空闲资源，HPA 扩容后的 Pod 可能一直 Pending。

二、最基础的 HPA 配置

yaml 复制代码

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

这里的目标是让 Pod 平均 CPU 使用率接近 70%，副本数不低于 2、不超过 10。实际计算还会受到当前副本数、指标采集周期和稳定窗口影响。

三、为什么 requests 很重要

如果使用 CPU 或内存利用率指标，Pod 必须正确设置资源 requests。利用率通常是实际使用量相对于 request 的比例。

yaml 复制代码

resources:
  requests:
    cpu: "200m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

没有合理 requests，HPA 可能无法计算利用率，或者计算出的扩容结果与业务实际容量不一致。requests 太小会导致利用率看起来很高，requests 太大又可能造成扩容迟钝和资源浪费。

四、HPA 支持的指标

1. CPU 和内存

适合基础资源型服务，但不能直接代表请求量和用户体验。

2. 自定义指标

可以根据请求速率、队列长度、并发数、消息积压和业务指标扩缩容。自定义指标需要 Metrics Adapter 或监控系统提供相应接口。

3. 外部指标

例如云队列长度、消息系统积压和外部流量。使用外部指标时必须考虑权限、网络和指标可用性。

五、扩缩容策略

HPA 需要避免频繁扩缩容。生产环境应配置稳定窗口和行为策略：

yaml 复制代码

behavior:
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
      - type: Percent
        value: 100
        periodSeconds: 60
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
      - type: Percent
        value: 25
        periodSeconds: 60

通常扩容希望更快，缩容则更谨慎，避免流量波动导致副本来回变化。应用启动慢时，扩容策略还要结合启动时间、就绪探针和预热机制。

六、HPA 与 Cluster Autoscaler 的关系

HPA 增加 Pod 副本，Cluster Autoscaler 根据 Pending Pod 再增加节点。两者解决的是不同层次的问题：

text 复制代码

流量上升 -> HPA 增加 Pod -> 节点资源不足 -> Cluster Autoscaler 增加节点

只有 HPA 没有节点扩容能力时，扩容的 Pod 可能无法调度；只有节点自动扩容没有 HPA 时，节点增加也不会自动增加应用副本。

七、常见问题排查

1. HPA 显示 unknown

检查 Metrics Server、APIService、证书、网络和 Pod 的 requests 配置：

bash 复制代码

kubectl get hpa
kubectl describe hpa web-hpa
kubectl top pods
kubectl top nodes

2. CPU 很高但 HPA 不扩容

确认目标对象正确、指标可用、requests 存在、HPA 没有达到 maxReplicas，且控制器没有报权限或指标错误。

3. 扩容后 Pod 一直 Pending

检查节点 CPU、内存、亲和性、污点、资源配额和拓扑约束。HPA 只修改副本数，不会自动解决所有调度条件。

4. 副本频繁上下波动

检查指标抖动、启动探针、稳定窗口、缩容策略和请求突发。适当延长缩容稳定窗口，并降低缩容速度。

5. 扩容了但业务仍然变慢

检查数据库连接、缓存、队列、外部 API、网络和限流。应用副本增加不代表所有下游都能承受更高并发。

八、生产实践建议

先为 Deployment 设置准确的 requests 和 limits。
选择能反映业务容量的指标，不只依赖 CPU。
明确 minReplicas 和 maxReplicas 的容量依据。
为慢启动应用配置合理探针和预热时间。
扩容快、缩容慢，避免抖动。
配合 Cluster Autoscaler 或预留节点资源。
监控 HPA 当前副本、期望副本、指标值和事件。
评估数据库、缓存和消息系统的承载能力。
压测验证扩缩容延迟和最大容量。

九、总结

HPA 是 Kubernetes 中根据指标自动调整 Pod 副本数的控制器。它的效果取决于指标质量、requests 配置、扩缩容策略、调度资源、应用启动速度和下游依赖。

真正可靠的自动扩缩容不是把 maxReplicas 设置得很大，而是知道业务高峰需要多少容量、扩容需要多久、下游能承受多少请求，以及扩容失败时如何降级和告警。

CSDN 发布时先上传 k8s-hpa-autoscaling.png，再替换图片路径。