Kubernetes集群HPA与VPA自动伸缩配置与冲突规避

Kubernetes自动伸缩体系概览

Kubernetes提供两种Pod自动伸缩机制：Horizontal Pod Autoscaler（HPA）横向扩缩容和Vertical Pod Autoscaler（VPA）纵向调整资源。两者配合得当可以最大化资源利用率，配合失当则会导致扩缩容震荡和资源浪费。

HPA基于指标（CPU利用率、内存利用率或自定义指标）增减Pod副本数量，适合流量波动大的在线服务。VPA基于历史资源使用情况调整Pod的CPU和内存请求值（requests），适合资源请求值设置不合理的场景。

HPA配置与关键参数

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: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 1000
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 60
      - type: Pods
        value: 4
        periodSeconds: 60
      selectPolicy: Max
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60

behavior字段是v2版本的增强功能，用于控制扩缩容速率。scaleUp的selectPolicy: Max表示同时满足百分比策略和Pod数量策略时，取扩容幅度更大的那个。scaleDown的stabilizationWindowSeconds: 300表示缩容需要5分钟的稳定窗口，避免流量短暂下降后立即缩容再扩容的震荡。

VPA配置与更新模式

VPA有三种更新模式：Auto（自动重建Pod应用新值）、Recreate（同Auto但更激进）、Off（仅建议不执行）。生产环境建议先用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: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: "4"
        memory: 8Gi

切换到Auto模式后，VPA会在Pod重建时应用新的资源请求值。需要注意VPA修改requests会导致Pod被重建，对于不支持优雅退出的应用可能造成短暂不可用。

HPA与VPA同时启用时的冲突

HPA和VPA同时作用于CPU指标时，极易产生冲突。VPA发现Pod的CPU请求值过高，下调requests值，导致CPU利用率百分比飙升（分母变小），HPA检测到利用率超标开始扩容。扩容后每个Pod的CPU利用率下降，VPA再次下调requests，形成正反馈循环。

规避策略：

1. 指标分离：HPA使用自定义指标（如QPS、消息队列深度），VPA负责CPU/内存资源请求值。两者监控不同维度的信号，互不干扰。

2. 限制VPA调整范围：通过VPA的minAllowed和maxAllowed约束调整幅度，避免requests被调整到HPA触发阈值以下。

3. 仅对特定工作负载启用：批处理任务和CronJob只配VPA，在线服务只配HPA，避免同一Deployment上两者同时生效。

基于自定义指标的HPA实践

对于Web服务，QPS比CPU利用率更能反映真实负载。通过Prometheus Adapter暴露自定义指标给HPA：

# Prometheus Adapter配置（ConfigMap）
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>>},30s)) by (<<.GroupBy>>)'

Adapter配置完成后，HPA就可以使用http_requests_per_second指标进行扩缩容决策。建议配合Pods类型指标，以每个Pod的平均QPS作为扩缩容基准。

自动伸缩的监控与告警

自动伸缩并非配置完就万事大吉，需要建立监控体系持续观察其行为是否符合预期。关键告警项：

1. HPA达到maxReplicas且指标仍超阈值——说明maxReplicas设置过低或资源池不足。

2. VPA建议值持续超过maxAllowed——说明应用资源需求已超出预期上限，需要重新评估。

3. 短时间内频繁扩缩容（如5分钟内扩容又缩容3次以上）——需要增大stabilizationWindowSeconds或调整指标窗口。

4. Pod Pending比例持续偏高——集群节点资源不足，需要配合Cluster Autoscaler扩容节点。