调优 HorizontalPodAutoscaler 避免副本抖动

配置 behavior 策略、合理的利用率目标与最小副本数，让自动扩缩在突发流量下保持稳定而不是反复震荡。

概述

自动扩缩是一个控制回路，默认每十五秒比较一次观测利用率与目标值并调整副本数。这个回路刻意保持简单，因此如果没有约束，它会跟随噪声行动。两分钟的流量尖峰抬升利用率，HPA 扩容；尖峰结束利用率回落，HPA 又缩容；下一次尖峰重复同样的循环。每一轮都要付出冷启动与调度抖动的代价，而用户看到的延迟并没有因为新 Pod 及时生效而改善。

步骤

定义带利用率目标、副本边界与缩容行为的 HPA：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: payments
  namespace: prod
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payments
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 25
          periodSeconds: 60

确认 HPA 能读到指标且副本数稳定：

kubectl get hpa payments -n prod
kubectl top pods -n prod -l app=payments

检查容器是否设置了 CPU request：

kubectl get deployment payments -n prod \
  -o jsonpath='{.spec.template.spec.containers[*].resources.requests.cpu}'

压测并观察副本变化：

kubectl get hpa payments -n prod -w

验证

压测期间副本数应上升，压测结束后缓慢下降而不是瞬间回落；整个过程不应出现反复的扩容缩容循环。HPA 显示的当前利用率应为具体百分比，若为 unknown，通常是 metrics-server 缺失或未设置 CPU request。长时间停在 maxReplicas 是一种容量事故，应单独告警而不是视为扩缩成功。

注意事项

CPU 利用率只是负载的代理指标，I/O 密集型服务更适合按队列深度或请求速率扩缩。
扩缩速度受 Pod 就绪时间限制，启动慢仍会造成延迟尖峰。
minReplicas 应按零预热情况下必须承接的流量设定，而不是按平均值。
缩容策略应配合百分比限制，避免一次移除过多副本。
自定义指标需要额外的 adapter，且要确认指标在流量变化时确实提前反应。