这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 HPA 根据指标自动调整 Pod 副本数，适合无状态、可水平扩展的服务。它不能替代容量规划和资源限制。
21.1 HPA 对象
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: order-service
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: order-service
minReplicas: 3
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
21.2 扩缩容算法
简化公式：
desired = currentReplicas * currentMetric / targetMetric
结果会受 min / max、容忍度、稳定窗口和指标质量影响。
21.3 指标来源
常见指标：
| 指标 | 场景 |
|---|---|
| CPU | 通用基线 |
| 内存 | 缓存类需谨慎 |
| QPS | 入口流量 |
| 队列长度 | 消费者 |
| 自定义延迟 | 核心体验 |
自定义指标依赖 Metrics Server、Prometheus Adapter 或自定义指标 API。
21.4 行为控制
behavior:
scaleDown:
stabilizationWindowSeconds: 300
scaleUp:
stabilizationWindowSeconds: 30
扩容可以更快，缩容应更保守，避免流量震荡。
21.5 前提条件
- Deployment 设置资源 requests；
- 应用无状态；
- Pod 可安全加入和退出；
- 下游依赖可承受并发；
- 指标可靠；
- 命名空间配额足够；
- 节点资源可扩容。
21.6 排查
kubectl get hpa order-service -w
kubectl describe hpa order-service
常见问题：
| 现象 | 原因 |
|---|---|
| unknown | 缺 requests 或指标 |
| 不扩容 | 指标未达阈值 |
| 达到 max | 容量或配额上限 |
| 震荡 | 稳定窗口太短 |
| Pod Pending | 节点资源不足 |
本章小结
HPA 通过指标维护副本数。CPU 是基础，QPS 和队列长度更能反映业务压力。稳定扩缩容依赖 requests、健康检查、下游容量和节点弹性。
思考题
- HPA 为什么依赖 requests？
- 队列长度指标适合什么服务？
- 扩容和缩容窗口为什么不同？
- HPA 能否解决节点资源不足？
- 如何避免 HPA 震荡？