Kubernetes HPA与VPA自动弹性伸缩配置详解

HPA与VPA的核心区别与适用场景

Kubernetes中的弹性伸缩包含两个核心组件：Horizontal Pod Autoscaler（HPA）通过增减Pod副本数实现横向伸缩，Vertical Pod Autoscaler（VPA）通过调整Pod的CPU和内存请求实现纵向伸缩。两者解决不同维度的资源瓶颈问题。

HPA适用于无状态服务（Web API、微服务网关），流量波动大时横向扩容可线性提升吞吐。VPA适用于有状态或单实例服务（数据库连接池、内存缓存），这类服务无法通过增加副本数提升性能，只能纵向调整资源配置。生产环境中两者常配合使用：HPA处理流量弹性，VPA优化资源配置效率。

HPA配置实战：基于CPU和自定义指标

基础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: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

基于自定义指标（如QPS）的HPA需要先部署Prometheus Adapter，将Prometheus指标注册为Kubernetes自定义指标：

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>>},5m)) by (<<.GroupBy>>)'

HPA引用自定义指标：

metrics:
- type: Pods
  pods:
    metric:
      name: http_requests_per_second
    target:
      type: AverageValue
      averageValue: 1000

VPA配置实战：资源推荐与自动调整

VPA有三种运行模式：Off（仅推荐不执行）、Initial（仅在新Pod创建时应用推荐值）、Auto（自动终止并重建Pod以应用新值）。

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: cache-service-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: cache-service
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: cache-service
      minAllowed:
        cpu: 500m
        memory: 512Mi
      maxAllowed:
        cpu: "4"
        memory: 8Gi
      controlledResources: ["cpu", "memory"]

VPA的推荐值可以通过kubectl查看：

kubectl describe vpa cache-service-vpa
# Status.Recommendation 下可看到当前推荐的CPU和内存值

HPA与VPA共存冲突处理

HPA和VPA同时启用时，若HPA基于CPU指标伸缩，而VPA也在调整CPU请求，两者会互相干扰：VPA增大CPU请求会导致Pod CPU利用率下降，触发HPA缩容；HPA缩容后负载集中又触发VPA增大资源。解决此冲突的方法：

方案一：HPA使用自定义指标（QPS、消息队列深度）代替CPU指标，VPA管理CPU和内存请求。两者在不同维度工作，互不干扰。

方案二：VPA设为Initial模式，只在Pod创建时应用推荐值，运行期间不主动调整。HPA在运行期间正常横向伸缩。需要手动定期review VPA推荐值并更新Deployment资源限制。

方案三：对于关键服务，VPA仅管理内存请求（避免OOMKill），CPU请求由HPA控制：

resourcePolicy:
  containerPolicies:
  - containerName: web-api
    controlledResources: ["memory"]
    mode: "Auto"

CI/CD流水线中的弹性伸缩集成

在CI/CD部署流水线中集成弹性伸缩策略，可以在发布时动态调整伸缩参数。典型实践：

金丝雀发布场景：部署新版本前，先将HPA minReplicas临时调高，确保新版本有足够Pod承载灰度流量，灰度通过后再恢复正常伸缩范围。

# 发布前临时调高HPA下限
kubectl patch hpa web-api-hpa -p '{"spec":{"minReplicas":6}}'
# 灰度通过后恢复
kubectl patch hpa web-api-hpa -p '{"spec":{"minReplicas":3}}'

监控告警集成：通过Prometheus Alertmanager在HPA达到maxReplicas时触发告警，通知运维人员评估是否需要手动扩容或申请更多节点资源。

混沌工程验证弹性伸缩效果

弹性伸缩策略需要在真实故障场景下验证有效性。使用Chaos Mesh注入故障测试：

CPU压力注入：对特定Pod注入CPU负载，验证HPA能否在预期时间内完成扩容。

apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: cpu-stress-test
spec:
  mode: one
  selector:
    namespaces: ["production"]
    labelSelectors:
      app: web-api
  stressors:
    cpu:
      workers: 4
      load: 80
  duration: "5m"

验证要点：HPA在2分钟内检测到CPU超阈值并开始扩容，新Pod在90秒内就绪并开始接收流量，扩容后P99延迟恢复至正常水平。若不满足上述标准，需调整HPA的stabilizationWindowSeconds和behavior.scaleUp.policies参数。