Kubernetes HPA与VPA自动伸缩实战：流量洪峰下的资源调度策略

Kubernetes自动伸缩为什么是流量洪峰的必修课

Kubernetes集群面对突发流量时，手动扩容根本来不及响应——从发现指标异常到手动执行kubectl scale，再到Pod就绪，整个过程可能需要5-10分钟，这期间服务可能已经过载。HPA（Horizontal Pod Autoscaler）和VPA（Vertical Pod Autoscaler）是Kubernetes内置的自动伸缩机制，合理配置后可以在30秒内完成扩容响应。这篇文章拆解HPA与VPA的配置实战。

HPA核心机制：从CPU利用率到自定义指标

HPA通过监控Pod的资源利用率或自定义指标，动态调整Deployment的副本数。基础配置：

apiVersion: autoscaling/v2
kind: HorizontalPodAutrosaler
metadata:
  name: web-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  minReplicas: 3
  maxReplicas: 50
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

上述配置的含义：当Pod平均CPU利用率超过70%时触发扩容，低于70%时触发缩容。但这个配置存在几个常见问题：

问题1：扩容滞后——默认HPA检查间隔为15秒，扩容决策到Pod就绪需要时间。解决方式是设置适当的冷却时间，避免频繁伸缩：

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300  # 缩容稳定窗口5分钟
    policies:
    - type: Percent
      value: 10
      periodSeconds: 60              # 每分钟最多缩10%
  scaleUp:
    stabilizationWindowSeconds: 0     # 扩容无延迟
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15              # 每15秒可扩100%
    - type: Pods
      value: 4
      periodSeconds: 15
    selectPolicy: Max                 # 取两种策略的最大扩容速度

基于自定义指标的精准伸缩

CPU利用率只能反映计算资源消耗，无法直接反映业务负载。对于Web服务，QPS（每秒请求数）和请求延迟是更直接的伸缩指标。配置自定义指标需要Prometheus Adapter：

# Prometheus Adapter配置（config.yaml）
rules:
- seriesQuery: 'http_requests_total{namespace!="",pod!=""}'
  resources:
    overrides:
      namespace: {resource: "namespace"}
      pod: {resource: "pod"}
  name:
    matches: "http_requests_total"
    as: "http_requests_per_second"
  metricsQuery: 'sum(rate(http_requests_total{namespace="<<.Namespace>>"}[2m])) by (pod)'

HPA引用自定义指标：

metrics:
- type: Pods
  pods:
    metric:
      name: http_requests_per_second
    target:
      type: AverageValue
      averageValue: "1000"   # 每个Pod处理1000 QPS时触发扩容

自定义指标的优势：直接对齐业务SLA，避免CPU指标和实际负载脱节。典型场景是I/O密集型服务——CPU利用率可能只有30%，但请求队列已经积压。

VPA：垂直伸缩自动调整资源配额

VPA与HPA互补——HPA调整副本数，VPA调整单个Pod的CPU/内存配额。VPA适用于以下场景：

资源配置不合理导致频繁OOMKilled
Pod的CPU请求设置过高，造成资源浪费
内存需求随运行时间增长（如缓存型服务）

VPA配置示例：

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-server-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  updatePolicy:
    updateMode: "Auto"     # Auto=自动重启更新; Initial=仅新Pod生效; Off=仅推荐
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: "100m"
        memory: "128Mi"
      maxAllowed:
        cpu: "4"
        memory: "8Gi"
      controlledResources: ["cpu", "memory"]

VPA的Auto模式会主动杀掉Pod重建，这在生产环境中风险较高。推荐做法：

先使用updateMode: "Off"，观察VPA的推荐值
确认推荐值合理后，切换为Initial模式（只对新创建的Pod生效）
仅在非核心服务上启用Auto模式

HPA与VPA的冲突处理

同时启用HPA和VPA时，两者可能对CPU指标产生竞争——VPA调整CPU配额，HPA基于CPU利用率做扩缩容。解决方案：

# VPA只管内存，HPA管CPU和副本数
# VPA配置
resourcePolicy:
  containerPolicies:
  - controlledResources: ["memory"]  # VPA只控制内存
    controlledValues: RequestsOnly   # 只调整requests

# HPA配置
metrics:
- type: Resource
  resource:
    name: cpu
    target:
      type: Utilization
      averageUtilization: 70

这样VPA负责根据实际内存消耗调整内存配额，HPA负责根据CPU利用率调整副本数，互不干扰。

Cluster Autoscaler：节点层面的弹性扩容

HPA扩容到maxReplicas后，如果集群没有足够的节点资源调度新Pod，扩容实际上不会生效。Cluster Autoscaler（CA）负责在节点层面扩容：

# Cluster Autoscaler启动参数（云厂商托管集群通常已集成）
--scale-down-unneeded-time=10m       # 节点空闲10分钟后缩容
--scale-down-delay-after-add=10m      # 扩容后10分钟内不缩容
--max-nodes-total=100                 # 集群最大节点数
--nodes=1:20:node-pool-1             # 节点池1：最少1台，最多20台
--balance-similar-node-groups         # 平衡相似节点组

三层伸缩的完整链路：

流量上升 → HPA检测到CPU/QPS超阈值 → 增加Pod副本数
Pod Pending → CA检测到集群资源不足 → 从云厂商申请新节点
节点加入集群 → Pending Pod被调度到新节点 → 服务容量恢复

缩容链路相反：流量下降 → HPA减少副本 → 节点利用率降低 → CA移除空闲节点。

压测验证伸缩效果

配置完成后必须用压测验证整个伸缩链路是否通畅：

# 使用hey工具模拟突发流量
hey -z 5m -c 500 -q 20 https://api.example.com/health

# 同时监控HPA状态
kubectl get hpa web-api-hpa -w

# 监控Pod状态
kubectl get pods -l app=web-api -w

# 监控节点变化
kubectl get nodes -w

验证关键指标：

HPA触发扩容的响应时间（从指标超阈值到新Pod启动）
新Pod从Pending到Running的时间
CA触发节点扩容的时间（云厂商API调用+节点初始化，通常2-5分钟）
缩容后服务是否保持稳定（无请求失败）

HPA+VPA+CA三层联动是Kubernetes应对流量洪峰的标准方案。核心配置要点：HPA用自定义指标对齐业务SLA，VPA只控制内存避免与HPA冲突，CA保障节点层资源供给，三层配合才能实现真正的弹性伸缩。

原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/kuberneteshpa-yu-vpa-zi-dong-shen-suo-shi-zhan-liu-liang/