HPA 水平自动扩缩容

流量高峰时人工去 scale 副本数，既慢又容易错过；低谷时多开的副本又在浪费资源。HPA（HorizontalPodAutoscaler，水平 Pod 自动伸缩）持续观察 Pod 的实际指标，自动增减副本数量，让应用规模随负载自动变化。

原理：指标从哪来

HPA 依赖 metrics-server 收集节点与 Pod 的 CPU/内存指标，周期性地把「当前平均利用率」与目标值比较，算出期望副本数交给 Deployment 执行。因此集群必须已部署 metrics-server：

kubectl top nodes       # 能输出指标说明 metrics-server 正常
# 输出：NAME     CPU(cores)   MEMORY(bytes)
#       node01   850m         3.2Gi
kubectl top pods

期望副本数大致按「当前副本数 × 当前利用率 ÷ 目标利用率」计算，并受最小/最大值约束。

编写 HPA：autoscaling/v2

autoscaling/v2 是目前稳定的 API 版本，用 metrics 数组声明扩缩依据。最常用的是 CPU 平均利用率触发：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60    # 平均利用率超过 60% 扩容

minReplicas/maxReplicas 圈定副本数范围；指标目标也可写成 AverageValue 表示绝对值（如每个 Pod 平均 100m CPU）。

观察与验证

创建后查看 HPA 状态，TARGETS 列是当前值/目标值：

kubectl apply -f hpa.yaml
kubectl get hpa myapp-hpa
# 输出：NAME        REFERENCE          TARGETS    MINPODS   MAXPODS   REPLICAS
#       myapp-hpa   Deployment/myapp   32%/60%    2         10        2
kubectl describe hpa myapp-hpa        # 事件里能看到扩缩容动作

用压测把 CPU 打上去，REPLICAS 会逐渐增长，压力下降后回落。

配合 requests 才有意义

averageUtilization 的分母是 Pod 的 CPU requests：实际用量 ÷ requests 才是利用率。容器没写 requests 时 HPA 无法计算利用率，也不会扩缩，所以给容器配置合理的资源请求是 HPA 生效的前提。

扩缩保护与冷却

HPA 自带一些防抖机制，避免副本数来回震荡：

• 扩容与缩容都有默认冷却窗口，短时间内不会连续反向操作。
• 缩容更保守：可配置 stabilizationWindowSeconds 延长观察时间，防止流量一波动就砍副本。
• 单次调整幅度有限制，不会一次性扩到 maxReplicas。
• 副本数永远被限制在 minReplicas 与 maxReplicas 之间，不会无限膨胀。

小结：HPA 靠 metrics-server 取指标、按利用率自动扩缩副本，autoscaling/v2 里用 metrics 声明目标、min/max 圈范围；由于利用率基于 requests 计算，容器必须写资源请求，否则 HPA 形同虚设。