1. 容量规划基础：定义、目标与核心原则
1.1 容量规划的定义
容量规划（Capacity Planning）是指在给定服务水平目标（SLO）的前提下，预测未来业务负载对基础设施资源的需求，并制定资源供给策略的过程。它并非一次性估算，而是一个持续动态的闭环管理活动。
核心公式： 容量规划 = 负载预测 × 资源模型 × 供给策略
在云原生场景下，容量规划的对象从物理服务器扩展为 Pod、节点、集群、API 网关、数据库连接池、消息队列吞吐量等抽象资源。
1.2 容量规划的目标
| 目标维度 | 具体描述 | 关键指标示例 |
|---|---|---|
| 成本最优 | 避免过度采购导致资源闲置，也避免资源不足引发业务受损 | 资源利用率 60%~80%，闲置成本 < 15% |
| 性能达标 | 确保在峰值负载下仍满足 SLO（如 P99 延迟 < 200ms） | 请求成功率 ≥ 99.9%，P99 延迟 ≤ 200ms |
| 弹性充足 | 预留合理的弹性缓冲，应对突发流量和故障转移 | 弹性扩容时间 < 30s，Buffer 水位 20%~30% |
| 风险可控 | 降低因资源不足导致的级联故障、版本漂移等连锁风险 | 无资源争抢引发的 OOM/CPU Throttle |
1.3 为什么需要容量规划
没有容量规划，团队将陷入以下困境：
- 被动救火： 流量突增时才发现资源不足，紧急扩容导致变更风险激增。
- 成本黑洞： 盲目采购或过度预留，云成本失控，资源利用率低于 30%。
- 版本漂移催化剂： 在 Multi-Cluster 架构中，容量不均会迫使运维人员在不同集群间手动迁移工作负载，导致配置不一致、版本碎片化。
- SLA 违约： 大促、秒杀等场景下系统雪崩，直接造成经济损失和品牌声誉受损。
⚠️ 关键认知： 容量规划不是“预测未来”，而是“管理不确定性”。好的容量规划能让系统在负载波动时保持稳定，为版本发布提供可靠的资源底座。
1.4 核心原则
- 以 SLO 为锚点： 所有容量决策必须绑定可量化的服务水平目标，避免凭感觉估算。
- 分层建模： 从应用层、中间件层、基础设施层分别建立资源模型，逐层聚合。
- 预留 Buffer 但不浪费： 通常保留 20%~30% 的弹性余量，同时通过 HPA/VPA 动态调整。
- 持续校准： 容量规划不是年度活动，应随业务增长、架构演进持续迭代。
- 跨集群统一视图： 在 Multi-Cluster 环境下，必须建立全局容量大盘，避免局部过载。
1.5 容量规划核心流程
下图展示了容量规划的闭环流程，从业务指标采集到资源供给策略执行：
1.6 容量规划与版本漂移的关系
在 Multi-Cluster 架构中，容量规划不足会直接加剧版本漂移风险：
- 集群间负载不均： 某个集群资源耗尽时，运维人员可能紧急将流量切到其他集群，但目标集群的版本可能落后，导致用户访问到旧版本服务。
- 弹性扩容触发配置漂移： 自动扩容时，新启动的 Pod 可能使用缓存中的旧镜像或旧配置，造成同一集群内版本不一致。
- 容量规划缺失 → 手动干预 → 配置碎片化： 这是版本漂移最常见的传播路径。
💡 最佳实践： 将容量规划与版本发布流程绑定。每次发布前，先评估目标集群的剩余容量是否满足新版本的资源需求，避免因容量不足而回退到旧版本或跨集群迁移。
1.7 容量规划成熟度模型
| 成熟度等级 | 特征 | 典型表现 |
|---|---|---|
| L1 被动响应 | 无规划，资源不足时手动扩容 | 频繁告警、紧急变更、版本漂移高发 |
| L2 静态规划 | 基于历史峰值做一次性估算 | 资源利用率低（< 40%），成本浪费严重 |
| L3 动态规划 | 引入 HPA/VPA，基于实时指标自动调整 | 利用率提升至 50%~70%，但仍存在局部过载 |
| L4 预测性规划 | 使用机器学习预测负载，提前调整资源 | 利用率稳定在 60%~80%，弹性响应时间 < 1min |
| L5 全局自治 | Multi-Cluster 全局容量调度，版本与容量联动 | 零手动干预，版本漂移自动修复 |