Kubernetes HPA实战：Pod弹性扩缩容配置与优化

Kubernetes HPA工作原理：从指标采集到副本调整

HPA（HorizontalPodAutoscaler）是Kubernetes内置的Pod弹性扩缩容组件。HPA通过metrics服务器周期采集Pod指标，按当前副本数、目标值与当前值计算期望副本数，然后调整Deployment或StatefulSet的副本数。计算规则是：期望副本数向上取整（当前副本数乘以当前指标值除以目标指标值），默认每15秒采样一次、每30秒评估一次，缩容有5分钟冷却窗口。

HPA最常用的指标是CPU使用率，autoscaling/v2版本扩展了内存、自定义指标与外部指标，Pod副本数由此可以响应QPS、队列深度、延迟等业务指标，不再局限于资源利用率。

HPA配置实战：CPU指标与自定义指标配置

一份同时配置CPU与自定义QPS指标的HPA：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "200"

自定义指标需要Metrics Adapter或Prometheus Adapter把指标暴露给HPA。部署kube-prometheus后，用Prometheus Adapter的rules把http_requests_per_second映射为Pod指标即可。

若Pods类型指标未配置，HPA只按CPU运行；多种指标共存时，HPA取计算结果的最大值。

HPA扩缩容抖动优化：稳定窗口与指标平滑

HPA生产上最常遇到的问题：流量尖峰触发扩容，流量回落立即缩容，然后再次扩容，形成抖动。解决思路分两层：用behavior把缩容稳定窗口加长，降低单次评估的过激反应；指标侧做平滑，比如QPS用5分钟窗口的平均值而不是瞬时值。

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
    - type: Percent
      value: 10
      periodSeconds: 60

上面的配置表示缩容前先稳定300秒，且每分钟最多缩容10%。秒杀类业务可以反向调快扩容策略，把scaleUp的policies放宽。

生产环境的HPA扩展：外部指标与预测式扩缩

纯CPU指标适合无状态Web服务，对有状态服务或突发型任务不够用。此时接入外部指标，比如Prometheus中的队列长度、订单积压等业务指标。还要注意HPA与ClusterAutoscaler配合，Pod扩了但节点不够，扩容就卡在Pending状态，集群层面要同步扩容节点。

预测式扩缩容可以在高峰期前提前扩容，借助KEDA（Kubernetes Event-driven Autoscaling）的ScaledObject，按cron表达式或预测模型调整最小副本数。KEDA底层就是生成HPA资源，兼容现有配置。弹性扩缩容的效果取决于指标定义质量，建议观察生产流量一周后再定阈值。