Kubernetes HPA与VPA自动扩缩容配置实战指南

Kubernetes集群的自动扩缩容是保障服务稳定性和资源利用率的核心能力。HPA（Horizontal Pod Autoscaler）通过增减Pod副本数应对负载变化，VPA（Vertical Pod Autoscaler）通过调整Pod的资源请求和限制优化资源分配。两者配合使用能在流量波动场景下实现精细化的资源管理，避免资源浪费和服务降级。

HPA工作机制与核心参数配置

HPA的控制循环默认每15秒执行一次，从Metrics Server获取Pod的资源利用率指标，与目标阈值比较后决定扩缩容操作。核心参数包括：

minReplicas / maxReplicas：副本数的上下限。生产环境建议minReplicas至少为2，保证单Pod故障时服务可用。

targetCPUUtilizationPercentage：CPU利用率目标值。通常设置为60-80%，留出突发流量的缓冲空间。设置过低会导致频繁扩容，设置过高则可能来不及扩容导致服务降级。

scaleTargetRef：扩缩容的目标资源，通常是Deployment或StatefulSet。

以下是基于CPU利用率的HPA配置示例：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-api-hpa
  namespace: production
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
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # 缩容稳定窗口5分钟
      policies:
      - type: Percent
        value: 10   # 每次最多缩容10%
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100  # 一次可扩容100%(翻倍)
        periodSeconds: 60
      - type: Pods
        value: 4    # 或每次至少增加4个Pod
        periodSeconds: 60
      selectPolicy: Max

behavior配置是HPA精细化控制的关键。scaleDown的stabilizationWindowSeconds防止指标短暂波动导致频繁缩容；scaleUp的selectPolicy: Max确保选择最激进的扩容策略，快速响应负载增长。

多指标HPA：CPU与自定义指标联动

单纯依赖CPU利用率作为扩缩容指标存在盲区：某些服务（如消息队列消费者）CPU利用率低但积压严重，需要基于自定义指标扩容。Kubernetes支持Prometheus自定义指标作为HPA数据源。

部署Prometheus Adapter将Prometheus指标暴露给Kubernetes Metrics API：

# Prometheus Adapter配置规则
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{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>)'

在HPA中引用自定义指标：

metrics:
- type: Pods
  pods:
    metric:
      name: http_requests_per_second
    target:
      type: AverageValue
      averageValue: 1000  # 每Pod每秒1000请求时触发扩容

多指标HPA的扩缩容决策逻辑是：取所有指标中扩容幅度最大的值作为最终扩容量。这意味着任何一个指标超过阈值都会触发扩容，但缩容需要所有指标都低于阈值。这种”或扩与缩”的逻辑确保了服务可用性优先。

VPA垂直自动扩缩容配置与最佳实践

VPA解决的是Pod资源请求（requests）和限制（limits）配置不合理的问题。很多团队凭经验设置资源值，要么过度分配浪费资源，要么分配不足导致OOM Kill或CPU Throttling。

VPA有三种运行模式：

Auto模式：自动计算推荐值并应用到新创建的Pod上。已有Pod需要重启才能生效。

Recommend模式：只计算推荐值不自动应用，适合先观察再决定是否启用自动调整。

Off模式：仅收集指标数据，不计算推荐值，用于调试。

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-api-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  updatePolicy:
    updateMode: "Auto"  # 自动应用推荐值
    minReplicas: 2       # 最低保持2个Pod可用
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: "4"
        memory: 8Gi
      controlledResources: ["cpu", "memory"]

VPA的minAllowed和maxAllowed限定了资源调整的上下限，防止异常指标导致资源请求值失控。生产环境务必设置maxAllowed，避免VPA将单个Pod的CPU请求调到节点可分配资源的上限，导致Pod无法调度。

HPA与VPA共存策略：避免冲突与资源争抢

HPA和VPA同时作用在同一Deployment上时，可能出现冲突：VPA增加Pod的CPU请求，导致CPU利用率下降，HPA因此触发缩容；缩容后负载集中又触发VPA上调——两个控制器相互抵消，形成振荡。

避免冲突的推荐策略：

1. HPA管CPU，VPA管Memory：HPA仅基于CPU指标扩缩容，VPA仅调整Memory的requests/limits。两者作用维度不同，不会产生冲突。

2. VPA设Recommend模式，HPA设Auto模式：VPA只提供推荐值，运维团队定期审查推荐值并手动调整Deployment的资源配置，HPA则自动根据负载扩缩容。

3. 分层控制：VPA作用于基础服务（如数据库连接池、缓存服务），确保单个Pod资源合理；HPA作用于无状态计算服务（如API网关、计算Worker），通过水平扩展应对流量变化。

在VPA配置中排除CPU指标：

resourcePolicy:
  containerPolicies:
  - containerName: '*'
    controlledResources: ["memory"]  # VPA只控制memory
    mode: "Auto"

同时在HPA中移除memory指标，仅保留CPU和自定义指标。这种解耦策略在大型集群中效果稳定。

扩缩容常见故障排查清单

HPA无法获取指标：检查Metrics Server是否正常运行，执行kubectl top pod验证指标可用性。Metrics Server默认只保留最近1分钟的指标数据，数据采集间隔30秒。

扩容速度慢于预期：检查scaleUp的periodSeconds和policy配置，确认没有过度限制扩容速率。同时检查Cluster Autoscaler是否需要先申请新节点——节点就绪时间通常是扩容瓶颈。

缩容导致服务抖动：增大stabilizationWindowSeconds到5-10分钟，降低缩容速率百分比。对于有状态服务，考虑使用PodDisruptionBudget限制并发缩容数量。

VPA推荐值异常偏大：检查Pod是否存在内存泄漏，VPA会基于历史峰值计算推荐值。设置maxAllowed作为安全兜底，同时排查应用本身的内存管理问题。

Kubernetes自动扩缩容不是开箱即用的银弹，需要根据业务特征持续调优。HPA和VPA的协同配置是SRE团队保障服务稳定性的基本功。