3. HPA API 版本演进:autoscaling/v1、v2beta2、v2 的区别与选择

HorizontalPodAutoscaler(HPA)的 API 版本经历了从 autoscaling/v1 到 v2beta2,再到稳定的 autoscaling/v2 的演进过程。每个版本在功能维度、字段结构和弹性策略上都有显著差异。理解这些差异,是进行参数移植适配的前提。

3.1 版本演进路线与核心差异

下表从功能覆盖、指标类型、行为控制三个维度对比三个主要 API 版本:

对比维度 autoscaling/v1 autoscaling/v2beta2 autoscaling/v2(稳定版)
Kubernetes 版本 v1.0+ v1.12 – v1.22 v1.23+
指标类型 仅 CPU 利用率 CPU、内存、自定义指标、外部指标 同 v2beta2(完整指标集)
指标结构 单字段 targetCPUUtilizationPercentage metrics[] 数组,支持 type + 详细配置 同 v2beta2
弹性行为控制 不支持 behavior 字段(beta) behavior 字段(稳定 GA)
选择建议 仅兼容旧集群,不推荐新部署 过渡版本,建议迁移至 v2 生产环境首选
版本选择原则: 如果你的集群版本 ≥ 1.23,请直接使用 autoscaling/v2。v2beta2 虽然功能与 v2 几乎一致,但属于 beta 资源,在集群升级时可能被移除或变更字段路径。

3.2 API 字段详解:metrics、behavior、scaleTargetRef

以 autoscaling/v2 为例,HPA 的核心字段结构如下。理解这三个字段是参数移植的基础。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: sample-hpa
spec:
  scaleTargetRef:        # 目标工作负载引用
    apiVersion: apps/v1
    kind: Deployment
    name: web-server
  minReplicas: 2
  maxReplicas: 10
  metrics:               # 弹性指标数组
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: requests_per_second
      target:
        type: AverageValue
        averageValue: 1000m
  behavior:              # 弹性行为策略
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Pods
        value: 4
        periodSeconds: 60
      - type: Percent
        value: 100
        periodSeconds: 60
      selectPolicy: Max

3.2.1 scaleTargetRef —— 弹性目标绑定

scaleTargetRef 指定 HPA 要控制哪个工作负载的副本数。它必须指向支持 /scale 子资源的对象,如 Deployment、StatefulSet、ReplicaSet。

  • apiVersion:目标资源的 API 版本,通常为 apps/v1。
  • kind:资源类型,常见为 Deployment 或 StatefulSet。
  • name:目标资源的名称,必须与集群中实际资源名称一致。
移植注意: 从 v1 迁移到 v2 时,scaleTargetRef 字段结构完全兼容,无需修改。但需确认目标工作负载的 apiVersion 是否已更新(如从 extensions/v1beta1 改为 apps/v1)。

3.2.2 metrics —— 多维弹性指标

metrics 是一个数组,允许同时配置多个指标。HPA 控制器会计算每个指标的建议副本数,并取最大值作为最终目标副本数。v2 支持四种指标类型:

指标类型(type) 适用场景 target 子字段 典型配置
Resource CPU / 内存利用率 type: Utilization 或 AverageValue averageUtilization: 70
Pods 每个 Pod 的自定义指标平均值 type: AverageValue averageValue: 1000m
Object 集群中某对象的指标(如 Ingress QPS) type: Value 或 AverageValue value: 500
External 集群外部指标(如 SQS 队列长度) type: Value 或 AverageValue value: 100
参数移植关键点: v1 中的 targetCPUUtilizationPercentage 在 v2 中对应 metrics[0].resource.target.averageUtilization。如果原 v1 配置为 targetCPUUtilizationPercentage: 80,移植到 v2 时需写成:
metrics:
- type: Resource
  resource:
    name: cpu
    target:
      type: Utilization
      averageUtilization: 80

3.2.3 behavior —— 弹性行为策略

behavior 字段是 v2beta2 引入、v2 稳定的核心增强。它允许精细控制扩缩容的速率、窗口和策略选择,避免弹性抖动。

behavior 包含两个子策略组:

  • scaleDown:缩容策略,控制副本减少的行为。
  • scaleUp:扩容策略,控制副本增加的行为。

每个策略组包含以下关键字段:

字段 说明 典型值
stabilizationWindowSeconds 稳定窗口,HPA 在窗口期内取历史建议副本数的最大值(扩容)或最小值(缩容),防止抖动 扩容:0;缩容:300
policies[] 策略列表,每个策略定义在 periodSeconds 内最多变更的副本数 见下方示例
selectPolicy 多策略时的选择逻辑:Max(取最大变更量)、Min(取最小变更量)、Disabled(禁用该方向) 扩容用 Max,缩容用 Min
生产建议: 缩容时设置 stabilizationWindowSeconds: 300(5分钟),避免流量短暂下降就快速缩容;扩容时设置 stabilizationWindowSeconds: 0,让 HPA 立即响应负载上升。

3.3 版本演进与参数映射关系(SVG 架构图)

下图展示了从 v1 到 v2 的字段演进路径,以及核心参数的映射关系:

HPA API 版本演进与字段映射 autoscaling/v1 scaleTargetRef minReplicas / maxReplicas targetCPUUtilizationPercentage (仅 CPU,无 behavior) autoscaling/v2beta2 scaleTargetRef minReplicas / maxReplicas metrics[] 数组 behavior(beta) (CPU + 内存 + 自定义 + 外部) autoscaling/v2(稳定) scaleTargetRef minReplicas / maxReplicas metrics[] 数组 behavior(GA) (完整指标 + 稳定行为策略) 字段扩展 稳定 GA 参数移植映射关系 1. targetCPUUtilizationPercentage → metrics[0].resource.target.averageUtilization 2. v1 无 metrics 数组 → v2 需构造 metrics[] 结构,type 设为 Resource 3. v1 无 behavior → v2 可新增 behavior 字段,默认行为与 v1 兼容 4. scaleTargetRef 结构三版本完全一致,无需修改 5. minReplicas / maxReplicas 字段名和语义在所有版本中保持一致

3.4 版本选择决策流程

在实际项目中,选择哪个 API 版本取决于集群版本和功能需求。以下决策流程可帮助快速判断:

  1. 检查集群版本:kubectl version --short 查看 Server Version。
  2. 若 ≥ v1.23:直接使用 autoscaling/v2,获得完整指标支持和稳定的 behavior 策略。
  3. 若 v1.12 – v1.22:使用 autoscaling/v2beta2,但需注意未来升级时迁移到 v2。
  4. 若 < v1.12:只能使用 autoscaling/v1,仅支持 CPU 指标,建议优先升级集群。
  5. 功能需求检查:如果需要自定义指标、外部指标或 behavior 策略,必须使用 v2beta2 或 v2。
避坑提示: 不要在生产集群中混用多个 API 版本的 HPA 资源。虽然 Kubernetes 会自动进行版本转换,但不同版本的默认行为可能略有差异,尤其在 behavior 字段的默认值上。统一使用 autoscaling/v2 是最安全的选择。