自动扩缩是什么
水平自动扩缩根据指标自动调整工作负载的副本数：用量高于目标就加副本，低于目标就减副本，副本数被限制在设定的上下限之间。它解决的是容量与流量不匹配的问题，让基础设施随业务波动伸缩。但它的动作有延迟，不是实时的，因此下限与指标目标需要按业务特性选好。
指标从哪来
最常用的是基于资源用量的指标，数值相对每个副本的请求值计算，因此目标对象必须先声明请求值，否则该指标不可用，扩缩状态会一直显示未知。也可以接入自定义指标，但需要额外的采集与适配组件，复杂度明显高于资源类指标。
基本信息
| 适用环境 | 任何 Kubernetes 发行版，接口版本不同功能有差异 |
|---|---|
| 依据指标 | 资源用量、自定义指标或外部指标 |
| 依赖组件 | 指标采集组件，资源类指标还需请求值已声明 |
| 调节范围 | 副本数在设定的上下限之间变化 |
| 动作节奏 | 按周期计算，且缩容通常带有稳定窗口 |
| 与手工操作 | 手工调整会被控制器按指标拉回 |
典型使用场景
- 流量波峰波谷明显：白天扩容、夜间缩容节省资源
- 突发流量承接：在监控指标超过目标时自动增加副本
- 发布期间保底：配合副本下限保证滚动更新期间有足够实例
- 成本优化：把长期空闲的副本数压到合理下限
- 配合队列类服务：依据积压量扩缩消费者数量
- 压测验证：观察扩容触发点与速度是否符合预期
扩缩配置示例
扩缩配置示例
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web
minReplicas: 3 # 下限决定保底容量
maxReplicas: 30 # 上限决定成本封顶
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60 # 相对请求值的百分比查看与排查
查看与排查
kubectl get hpa # 看当前副本数与指标值
kubectl describe hpa web-hpa # 看扩缩事件与原因
kubectl get deploy web -o jsonpath='{.spec.replicas}' # 与工作负载副本数对照
kubectl top pod -n prod --sort-by=cpu # 看真实用量分布常见异常状态
| 现象 | 原因 | 处理 |
|---|---|---|
| 指标显示未知 | 目标对象缺少请求值或指标组件未就绪 | 补上请求值并确认采集组件正常 |
| 始终不扩容 | 已达上限或指标未超过目标 | 核对上限与目标值设置 |
| 频繁抖动 | 目标值过严或指标波动大 | 放宽目标值并设置稳定窗口 |
| 扩了但仍然慢 | 扩容只是加副本，实例启动仍需时间 | 提高下限作为保底容量 |
基于资源用量的指标按每个副本的相对请求值计算，没有声明请求值时该指标不可用，这是自动扩缩失败最常见的原因。
扩缩对象存在时手工调整副本数会被控制器按指标拉回，需要临时固定副本数时应先暂停或移除扩缩对象。