Kubernetes集群自动伸缩策略深度解析：HPA、VPA与Cluster Autoscaler实战

2026年7月15日互联网

引言：为什么需要自动伸缩

在云原生时代，应用流量的波动性越来越显著。白天高峰期需要大量计算资源，而夜间低谷期资源大量闲置。手动调整资源不仅耗时耗力，而且往往无法及时响应突发流量。Kubernetes提供了完善的自动伸缩体系，包括水平Pod自动伸缩（HPA）、垂直Pod自动伸缩（VPA）和集群自动伸缩（Cluster Autoscaler），三者协同工作可以实现从Pod到节点级别的全方位弹性伸缩。

HPA：水平Pod自动伸缩详解

HPA（Horizontal Pod Autoscaler）是Kubernetes中最常用的自动伸缩机制，它根据观察到的CPU利用率、内存使用率或自定义指标自动增加或减少Pod副本数量。

HPA的工作原理是周期性地从Metrics Server获取Pod的资源使用指标，与目标值进行比较，然后计算出所需的副本数并调整Deployment或StatefulSet的replicas字段。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  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: 10
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
      - type: Percent
        value: 100
        periodSeconds: 60
      - type: Pods
        value: 4
        periodSeconds: 60
      selectPolicy: Max

上述配置定义了一个HPA，目标是将CPU使用率维持在70%以下，内存使用率维持在80%以下。扩容时每分钟最多翻倍或增加4个Pod（取较大值），缩容时每分钟最多减少10%且需要5分钟的稳定窗口。

自定义指标与Prometheus Adapter

仅依赖CPU和内存指标往往不够精确。例如，一个Web服务可能需要基于QPS（每秒查询数）来伸缩，一个消息队列消费者可能需要基于队列深度来伸缩。Prometheus Adapter允许你将Prometheus采集的任意指标暴露给Kubernetes Metrics API，从而被HPA使用。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 3
  maxReplicas: 50
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "1000"
  - type: External
    external:
      metric:
        name: rabbitmq_queue_messages
        selector:
          matchLabels:
            queue: "task-queue"
      target:
        type: AverageValue
        averageValue: "50"

Prometheus Adapter的核心配置文件定义了如何从Prometheus查询结果映射为Kubernetes指标：

rules:
- seriesQuery: 'http_requests_total{namespace!="",pod!=""}'
  resources:
    overrides:
      namespace: {resource: "namespace"}
      pod: {resource: "pod"}
  name:
    matches: "^(.*)_total"
    as: "${1}_per_second"
  metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>)'

VPA：垂直Pod自动伸缩

VPA（Vertical Pod Autoscaler）与HPA不同，它不改变Pod的数量，而是根据历史使用数据自动调整Pod的CPU和内存请求（requests）与限制（limits）。这在以下场景中特别有用：应用的资源需求随时间变化但不需要水平扩展，或者你不确定应用到底需要多少资源。

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: database-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: StatefulSet
    name: postgres-db
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: postgres
      minAllowed:
        cpu: "500m"
        memory: "1Gi"
      maxAllowed:
        cpu: "4"
        memory: "8Gi"
      controlledResources: ["cpu", "memory"]

VPA有三种运行模式：Auto（自动调整并在必要时重启Pod）、Recreate（始终在启动时调整并重启Pod）和Off（仅提供建议不自动调整）。建议在生产环境先用Off模式观察推荐值，确认合理后再切换到Auto模式。

Cluster Autoscaler：节点级别的弹性伸缩

当HPA扩容Pod时，如果集群中没有足够的节点资源来调度这些Pod，Pod将处于Pending状态。Cluster Autoscaler会监控这些Pending Pod，并自动向云提供商申请新节点加入集群。当节点资源利用率持续低于阈值时，它也会移除空闲节点。

Cluster Autoscaler的关键启动参数：

# 常见启动参数（以AWS EKS为例）
--scale-down-unneeded-time=10m          # 节点空闲10分钟后可缩容
--scale-down-delay-after-add=10m        # 扩容后10分钟内不缩容
--balance-similar-node-groups=true      # 平衡相似节点组
--skip-nodes-with-system-pods=true      # 跳过有kube-system Pod的节点
--expander=least-waste                  # 优先选择浪费最少的节点组
--max-node-provision-time=15m           # 节点创建最大等待时间

在云厂商托管Kubernetes服务中，Cluster Autoscaler通常通过节点组（Node Group）或托管节点组来管理。以下是一个典型的节点组配置：

# AWS EKS 节点组配置示例
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: production-cluster
  region: ap-southeast-1
managedNodeGroups:
- name: compute-nodes
  instanceType: m6i.xlarge
  minSize: 3
  maxSize: 30
  desiredCapacity: 5
  labels:
    node-type: compute
  tags:
    k8s.io/cluster-autoscaler/enabled: "true"
    k8s.io/cluster-autoscaler/production-cluster: "owned"

三大伸缩器协同工作的最佳实践

HPA、VPA和Cluster Autoscaler三者需要协调配置才能发挥最大效用。以下是一些关键的实践建议：

1. HPA和VPA不要同时作用于同一资源指标。如果HPA基于CPU伸缩，VPA就不应该自动调整CPU请求，否则两者会互相干扰。推荐做法是HPA基于CPU/内存伸缩时，VPA仅对非关键容器提供建议。

2. 设置合理的冷却时间。伸缩操作后需要给系统一个稳定期，避免频繁抖动。HPA的stabilizationWindowSeconds和Cluster Autoscaler的scale-down-delay-after-add都是为此设计。

3. 预留缓冲资源。集群应始终保持一定的可用资源（建议至少20%），确保HPA扩容的Pod能立即调度，而不必等待Cluster Autoscaler创建新节点。

4. 使用Pod Disruption Budget保护关键服务：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-app-pdb
spec:
  minAvailable: "60%"
  selector:
    matchLabels:
      app: web-app

监控与调优：构建可观测的伸缩体系

自动伸缩不是配置完成就一劳永逸的，需要持续监控和调优。以下是关键的监控指标和对应的Prometheus查询：

# HPA伸缩事件频率
rate(kube_hpa_status_replicas_changes[5m])

# Pod资源请求 vs 实际使用
kube_pod_container_resource_requests{resource="cpu"}
/ on(namespace, pod) group_left
sum(rate(container_cpu_usage_seconds_total[5m])) by (namespace, pod)

# 集群节点资源分配率
sum(kube_pod_container_resource_requests{resource="cpu"})
/ sum(kube_node_capacity{resource="cpu"})

# Pending Pod数量（触发Cluster Autoscaler的信号）
kube_pod_status_phase{phase="Pending"}

建议在Grafana中建立伸缩监控面板，包含以下视图：HPA当前副本数与目标副本数对比、各节点资源使用热力图、Cluster Autoscaler扩缩事件时间线、Pod调度延迟分布。这些视图能帮助你快速发现伸缩策略中的不足并及时调整。

总结

Kubernetes的自动伸缩体系为云原生应用提供了从Pod到节点级别的全方位弹性能力。HPA处理水平扩展以应对流量波动，VPA优化单个Pod的资源分配以减少浪费，Cluster Autoscaler在节点层面保障资源供给。三者协同配合，加上完善的监控和调优机制，才能真正实现按需分配、弹性伸缩的云原生资源管理目标。在实际部署中，建议从HPA开始，逐步引入VPA和Cluster Autoscaler，并在每个阶段充分验证效果后再推进下一步。