Kubernetes HPA弹性伸缩实战：HPA与容器自动扩缩容配置指南

网站流量有峰谷，容器按峰值冗余浪费资源，按谷值部署又扛不住突发。Kubernetes的HPA（Horizontal Pod Autoscaler）按指标自动调整Pod副本数，是网站运维里最常用的弹性手段。这篇讲HPA的完整配置路径：从CPU/内存指标起步，再接入自定义指标，最后和集群级扩缩容联动，形成一套能落地的弹性伸缩方案。

HPA工作原理与扩容计算逻辑

HPA是一个控制循环：控制器周期性读取Pod指标，与设定目标值比较，按公式计算期望副本数。目标副本数 = ceil(当前副本数 × 当前指标值 / 目标指标值)。默认同步周期30秒，指标延迟约1分钟，所以HPA是秒级到分钟级反应，不适合做突发流量的兜底。

HPA扩容是异步的，缩容默认要稳定5分钟后才动作（–horizontal-pod-autoscaler-downscale-stabilization）。生产经验是给Pod加上就绪探针，避免副本扩容了但服务没起来、流量全打到存量Pod上。

基于CPU和内存的HPA配置示例

先用最常用的资源指标，Deployment如下：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Pods
        value: 2
        periodSeconds: 30
    scaleDown:
      stabilizationWindowSeconds: 120

behavior字段控制扩缩容的节奏：扩容不设稳定窗口、每30秒最多加2个Pod，应对突增；缩容留120秒稳定窗口，防止抖动导致来回切换。CPU目标值建议设在60%-70%之间，留出足够缓冲，也给HPA判断的采集误差留空间。

自定义指标HPA：基于QPS与队列深度的扩缩容

CPU指标在IO密集、异步消费场景下失真，需要按业务指标伸缩。常见做法是metrics-server之外接入Prometheus Adapter，把Prometheus里的http_requests_per_second暴露成自定义指标：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-gateway-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-gateway
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_qps
      target:
        type: AverageValue
        averageValue: "200"

对应的Prometheus Adapter需要写rules，把查询结果映射成metric。队列类指标（Kafka积压、DB连接池）更适合用Object类型引用外部对象。按QPS伸缩比按CPU准：QPS直接反映流量，伸缩反应也更平滑。

HPA与集群自动扩缩容的联动

Pod扩到maxReplicas后，节点资源会耗尽，此时要Cluster Autoscaler（CA）接管，按待调度Pod的请求量给集群加节点。两类自动扩缩容分工：HPA管Pod数量，CA管节点数量。生产上常见组合是：HPA把Pod拉到上限，CA补节点，节点就绪后HPA继续往上扩。

需要先给节点池设好min/max限制，并给关键工作负载配PriorityClass，避免抢占时普通任务被挤掉。同时为HPA扩出的Pod设置requests和limits，保证调度器能准确计算节点余量。

弹性伸缩的监控与稳定性检查

上线后重点盯三个指标：HPA实时状态（kubectl get hpa -w）、Pod扩容时长（创建到就绪）、指标采集延迟。定期用压测验证伸缩曲线：流量涨了15秒内有新Pod，流量跌了5分钟内有回收。HPA不是越激进越好，高频伸缩反而造成缓存与连接池反复重建，把稳定窗口和扩缩步长调到与业务波动周期匹配，才是落地的关键。