Kubernetes HPA与VPA自动伸缩实战：集群资源优化配置指南

Kubernetes自动伸缩的核心价值

Kubernetes集群的资源管理中，手动配置Pod副本数和资源请求既低效又容易出错。业务流量存在波峰波谷，固定副本数要么在低峰期浪费资源，要么在高峰期响应不足。Kubernetes提供了HPA（Horizontal Pod Autoscaler）和VPA（Vertical Pod Autoscaler）两种自动伸缩机制，分别处理水平扩缩和垂直调整，二者配合使用可以实现集群资源的精细化管理。

HPA根据CPU使用率、内存占用或自定义指标增减Pod副本数，应对流量波动。VPA则调整Pod的CPU和内存请求值，解决资源请求设置不合理的问题。在SRE稳定性工程实践中，合理配置自动伸缩策略是保障服务SLA同时控制成本的关键手段。

HPA配置与指标选择

HPA的基础配置并不复杂，但指标选择和参数调优直接影响伸缩效果。

# HPA基础配置 - 基于CPU使用率
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
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 25
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 30
      - type: Pods
        value: 4
        periodSeconds: 30
      selectPolicy: Max

behavior字段是HPA配置中容易被忽略但极其重要的部分。默认行为下，缩容速度可能过快导致请求抖动，扩容速度可能过慢无法应对突发流量。上面的配置做了针对性优化：扩容时取最大策略，允许快速拉起实例；缩容时设置5分钟稳定窗口，避免流量小幅波动导致反复缩扩。

自定义指标驱动的HPA

CPU和内存使用率是最常用的伸缩指标，但对多数业务而言并非最佳选择。CPU高不一定代表负载高（可能是GC或计算密集型任务），CPU低也不代表服务健康。基于业务指标的HPA能更准确地反映实际负载。

# 基于Prometheus自定义指标的HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 2
  maxReplicas: 15
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 500
  - type: Pods
    pods:
      metric:
        name: request_duration_seconds_p99
      target:
        type: AverageValue
        averageValue: 500m

VPA垂直自动伸缩配置

VPA解决的是另一个问题：Pod的资源请求（requests）设置不合理。开发者往往凭经验设置CPU和内存请求，设置过低会触发OOM或CPU节流，设置过高则浪费集群资源。VPA通过监控Pod的实际资源使用情况，推荐或自动调整资源请求值。

# VPA配置
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: data-processor-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: data-processor
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: data-processor
      minAllowed:
        cpu: 250m
        memory: 256Mi
      maxAllowed:
        cpu: 4
        memory: 8Gi
      controlledResources: ["cpu", "memory"]

VPA的updateMode选择需要权衡：Auto模式下VPA会主动终止Pod并调整资源重建，可能造成短暂不可用；Off模式只输出推荐值，适合初期观察VPA推荐是否合理。生产环境建议先运行Off模式两周，分析推荐值与实际负载的偏差，确认无误后再切换为Auto。

HPA与VPA的协作冲突处理

HPA和VPA同时作用于同一Deployment时，存在冲突风险：VPA调整CPU请求可能导致CPU利用率变化，触发HPA不必要的伸缩操作。处理方案：

方案一：资源分工——HPA基于CPU指标水平伸缩，VPA仅管理内存请求。这避免了CPU请求变化对HPA的干扰。

方案二：指标分离——HPA使用自定义业务指标（QPS、延迟），VPA管理CPU和内存请求。HPA的伸缩决策不依赖资源利用率，因此VPA的调整不会影响HPA判断。

方案三：VPA仅推荐模式——VPA设为Off模式，运维人员定期审查推荐值并手动调整。适合对稳定性要求极高的核心服务。

Cluster Autoscaler配合节点扩缩

HPA扩容Pod时，如果集群节点资源不足，Pod会进入Pending状态。Cluster Autoscaler监测Pending Pod，自动向云服务商申请新节点。三者配合的完整链路：HPA检测负载增长、创建新Pod、节点资源不足Pod Pending、Cluster Autoscaler添加节点、Pod调度到新节点。

# Cluster Autoscaler关键启动参数
--scale-down-delay-after-add=10m
--scale-down-delay-after-delete=30s
--scale-down-unneeded-time=10m
--max-graceful-termination-sec=600
--skip-nodes-with-system-pods=true
--expander=least-waste

DevOps流水线中的自动伸缩验证

自动伸缩配置的验证不应只在生产环境被动等待流量波动，应在CI/CD流水线中主动测试。使用k6模拟负载冲击，观察HPA响应时间是否满足预期。

# k6负载测试脚本
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 500 },
    { duration: '10m', target: 1000 },
    { duration: '5m', target: 1000 },
    { duration: '2m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.get('http://web-api.example.com/api/orders');
  check(res, {
    'status is 200': (r) => r.status === 200,
  });
}

测试期间同步监控HPA事件：kubectl get hpa -w，记录从负载增加到新Pod就绪的时间。如果扩容延迟超过流量容忍窗口，需要调整HPA的扩容策略或预热机制。通过这种主动验证的方式，可以在上线前发现自动伸缩配置的问题，而非在流量高峰时被动应对。