capacity-forecasting

容量预测、水位阈值与扩容决策

补充说明

容量规划回答三个问题：现在够不够、什么时候不够、扩多少。指标要看峰值而不是平均值，扩缩容要看 request 而不是 limit。预测周期至少覆盖采购或节点启动的提前期；GPU、裸金属和专线通常要提前 1–3 个月。

扩容公式（按并发）：所需副本 = ceil(峰值 QPS × P99 延迟(秒) / (单副本安全并发 × 目标利用率))。

常用示例

算例：峰值 2000 QPS，P99 50ms，单副本安全并发 50，目标利用率 70%：

awk 'BEGIN {qps=2000; lat=0.05; per=50; util=0.7; r=qps*lat/(per*util);
  printf "并发: %.0f，所需副本: %d\n", qps*lat, int(r)+(r>int(r))}'

容量水位阈值：

从历史数据做线性趋势预测：

# qps.csv 每行一个采样点，第二列为峰值 QPS，至少 6 周数据
awk -F, '{n++; x[n]=n; y[n]=$2; sx+=n; sy+=$2; sxx+=n*n; sxy+=n*$2}
END {b=(n*sxy-sx*sy)/(n*sxx-sx*sx); a=(sy-b*sx)/n;
  printf "每日增长 %.2f QPS，30 天后 %.0f QPS，60 天后 %.0f QPS\n",
  b, a+b*(n+30), a+b*(n+60)}' qps.csv

Kubernetes 资源申请基线：

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    memory: "1Gi"

不要给 CPU 设过低 limit，否则节流会造成延迟毛刺；内存 limit 要高于实际峰值，避免 OOMKilled。

容量评审决策规则：

• 预测峰值超过当前可分配容量的 70%，立即启动扩容；不要等到 90%。
• 扩容提前期超过 30 天的资源（GPU、裸金属、专线），按 90 天预测备货。
• 单可用区故障后剩余容量必须能承载全量流量，否则按 N+1 补容量。
• 连续 30 天利用率低于 30% 的资源进入缩容评估，但先确认灾备和峰值需求。

易错点与排错

• 用平均利用率做决策，忽略每天峰值和活动流量，扩容总是慢半拍。
• 用 limit 计算节点可调度容量，节点实际按 request 调度，导致超卖和争抢。
• 忘记 N+1 或可用区故障，单区故障后剩余容量不足。
• 只看趋势不看事件日历，大促、发布会和批处理任务会把预测打穿。
• 扩容链路本身是瓶颈：节点启动、镜像拉取、IP 耗尽、配额不足都会拖慢扩容。
• 只扩应用副本，瓶颈在数据库连接数、下游配额或许可证。
• 没有缩容策略，长期低水位运行，成本持续浪费。
• 把 HPA 当容量规划：HPA 处理分钟级波动，容量规划处理周/月级增长和采购。

读完自测

合上页面，先回答，再展开对照。

1. 为什么容量规划要看 request 而不是 limit？
2. 预测峰值达到当前可分配容量的多少时应启动扩容？
3. HPA 能替代容量规划吗？为什么？

相关条目

• capacity-planning — 集群容量规划
• cluster-autoscaler — 节点自动扩缩容
• hpa — 工作负载水平扩缩容
• cost-optimization-checklist — 成本与容量平衡