HPA 水平自动扩缩容
HPA 按指标自动调整工作负载的副本数：CPU 与内存这类资源指标由 metrics-server 提供，自定义与外部指标需要额外的适配器。要注意 CPU 利用率的分母是 requests，没有设置 requests 的工作负载根本扩不起来。
基本信息
| 对象 | HorizontalPodAutoscaler，用 scaleTargetRef 指向目标工作负载 |
|---|---|
| CPU 指标 | 按其占 requests 的百分比计算，必须设置 requests |
| 副本范围 | minReplicas 与 maxReplicas 决定调整区间 |
| 行为控制 | behavior 控制扩缩速度与稳定窗口 |
| 前置依赖 | 资源指标需要 metrics-server，自定义指标需要适配器 |
| API 版本 | autoscaling/v2 支持多指标与行为策略 |
指标类型与来源
| 指标类型 | 来源 | 典型用途 |
|---|---|---|
| 资源指标 | metrics-server | CPU 与内存驱动的扩缩 |
| 自定义指标 | 指标适配器 | 按队列长度或业务指标扩缩 |
| 外部指标 | 外部系统接入 | 按云服务指标扩缩 |
| 多指标组合 | 各指标取需要的副本最大值 | 多维度同时约束 |
HPA 示例
HPA 示例
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70 # 目标：平均利用率 70%典型使用场景
- 流量有明显波峰波谷的在线服务，按 CPU 自动扩缩
- 队列消费型服务，按自定义指标扩缩以跟上堆积速度
- 高峰期保底副本、低峰期收缩，兼顾体验与成本
- 与节点自动扩缩配合，既扩副本也扩节点
HPA 扩的是副本数而不是节点数：集群节点容量不够时扩出来的 Pod 会 Pending，需要配套节点自动扩缩或提前预留容量。
内存指标驱动的扩缩风险更高：内存回收困难且应用行为非线性，实践中多数团队仍以 CPU 或自定义业务指标为主。
忘设 requests 会让利用率无法计算，HPA 一直报 unknown 而不扩容，这是自动扩缩失效最常见的原因。
阈值上线前先用压测确认：目标利用率设得过低会让副本频繁上下浮动，设得过高则压力上来也不扩；配合行为策略里的稳定窗口与缩放速率，把抖动收敛到可接受范围。