副本数是怎么算出来的
自动扩缩容不是每次加一个副本，而是按比例计算：用当前副本数乘以当前指标与目标指标的比值，向上取整得到期望副本数，再受最小与最大副本数约束。理解这个公式，就能解释为什么利用率略高一点时副本数会跳一大截，以及为什么缩减通常比扩容慢。
基本信息
| 适用平台 | Kubernetes 1.20+，通常需要指标组件提供数据 |
|---|---|
| 计算公式 | 期望副本等于当前副本乘以当前指标除以目标指标后向上取整 |
| 取值边界 | 结果受最小与最大副本数夹取 |
| 指标口径 | 利用率是相对容器资源请求的百分比 |
| 多指标 | 各指标分别计算后取较大值 |
典型使用场景
- 理解扩容幅度为何比预期大，核对公式与请求值是否合理
- 资源请求改动后伸缩行为突然变化，需要定位原因
- 多指标组合场景：确认最终以哪个指标为准
- 排查不扩缩容：确认指标采集是否正常
- 容量规划时预估高负载下需要多少副本
两个算例
两个算例
4 副本、平均利用率 90%、目标 60%：向上取整(4 × 90/60) = 向上取整(6) = 6
3 副本、利用率 200%、目标 50%：向上取整(3 × 4) = 12
2 副本、利用率 55%、目标 60%：向上取整(2 × 0.92) = 2，保持不变查看决策依据
查看决策依据
kubectl describe hpa web-hpa | sed -n '/Metrics:/,/Events:/p' # 当前指标与期望值
kubectl get hpa web-hpa -o jsonpath='{.status.currentMetrics}' # 结构化指标
kubectl get hpa web-hpa # 目标与实际对比
kubectl top pods -l app=web # 单副本实际用量参数与影响
| 参数 | 作用 | 注意点 |
|---|---|---|
| 目标利用率 | 期望维持的指标水平 | 设置过低会导致副本频繁波动 |
| 最小副本数 | 下限 | 决定低峰期的基础成本 |
| 最大副本数 | 上限 | 决定突发流量下的容量天花板 |
| 资源请求 | 利用率计算的分母 | 请求改小会让利用率变高、更易扩容 |
| 稳定窗口 | 抑制剧烈波动的观察时间 | 过短会导致副本数来回抖动 |
利用率是相对资源请求的百分比，不是相对节点容量。把请求改小会让同一份真实负载看起来利用率更高，伸缩行为随之变得敏感，这也是扩容突然变频繁的常见原因。
多指标场景下，最终副本数取各指标计算结果的较大值。只盯一个指标检查，会得出与实际不符的结论。