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 的字段演进路径,以及核心参数的映射关系:
3.4 版本选择决策流程
在实际项目中,选择哪个 API 版本取决于集群版本和功能需求。以下决策流程可帮助快速判断:
- 检查集群版本:
kubectl version --short查看 Server Version。 - 若 ≥ v1.23:直接使用
autoscaling/v2,获得完整指标支持和稳定的 behavior 策略。 - 若 v1.12 – v1.22:使用
autoscaling/v2beta2,但需注意未来升级时迁移到 v2。 - 若 < v1.12:只能使用
autoscaling/v1,仅支持 CPU 指标,建议优先升级集群。 - 功能需求检查:如果需要自定义指标、外部指标或 behavior 策略,必须使用 v2beta2 或 v2。
避坑提示: 不要在生产集群中混用多个 API 版本的 HPA 资源。虽然 Kubernetes 会自动进行版本转换,但不同版本的默认行为可能略有差异,尤其在 behavior 字段的默认值上。统一使用
autoscaling/v2 是最安全的选择。