1. 容量规划基础：定义、目标与核心原则
1.1 容量规划的定义
容量规划（Capacity Planning）是指在给定服务质量目标（SLO/SLI）的前提下，预测、评估并确保系统在未来一段时间内具备足够资源以承载预期负载的过程。在云原生环境中，这一过程从传统的“采购-部署”模式演变为“配置-弹性”模式，但其核心本质并未改变：在成本、性能与可靠性之间找到最优平衡点。
关键定义：容量规划不是一次性的资源估算，而是一个持续进行的闭环流程，包含监控、分析、预测、调整与验证五个阶段。
1.2 容量规划的核心目标
容量规划的目标可以归纳为以下四个维度，它们共同构成了容量规划的决策矩阵：
| 目标维度 | 描述 | 典型指标 |
|---|---|---|
| 性能保障 | 确保系统在峰值负载下仍能满足响应时间、吞吐量等SLO要求 | P99延迟、每秒请求数（RPS）、并发连接数 |
| 成本优化 | 避免过度配置导致的资源浪费，同时防止因资源不足引发的业务损失 | 资源利用率、单位请求成本、预留vs按需比例 |
| 可靠性提升 | 通过预留缓冲容量应对突发流量或故障转移，降低过载风险 | 故障域冗余度、N+1/N+2冗余、故障转移时间 |
| 弹性效率 | 评估弹性伸缩策略的有效性，确保扩容速度匹配负载增长速度 | 扩容触发时间、冷启动延迟、弹性伸缩滞后率 |
1.3 核心原则
容量规划遵循以下五项核心原则，这些原则在云原生架构下被赋予了新的内涵：
- 以数据驱动，而非经验驱动：依赖历史监控数据、业务增长曲线和压测结果进行量化分析，避免“拍脑袋”式的资源估算。
- 预留缓冲，但不浪费：在关键路径上保留合理的冗余容量（通常为峰值负载的20%~30%），同时通过弹性伸缩消除非核心资源的长期闲置。
- 分层规划，逐级细化：从全局集群容量到单个Pod/容器资源，分层设定容量目标，确保每一层都有明确的容量边界。
- 持续迭代，闭环反馈：容量规划不是静态文档，而是与CI/CD、监控告警、混沌工程等流程集成的持续活动。
- 故障域对齐：容量规划必须与多租户隔离、可用区分布、故障域边界保持一致，避免出现“有容量但不可用”的伪冗余。
1.4 云原生时代容量规划为何至关重要
在传统IT架构中，容量规划往往以季度或年度为周期，主要关注硬件采购与机房扩容。云原生架构的引入从根本上改变了这一格局，使得容量规划的重要性被推至前所未有的高度：
- 动态拓扑带来的不确定性：Pod漂移、自动扩缩容、HPA/VPA等机制使得资源分布时刻变化，静态容量模型完全失效。
- 微服务级联效应：一个服务的容量不足可能通过调用链引发雪崩效应，导致整个系统的容量塌陷。
- 多租户资源争抢：在共享集群中，不同租户的工作负载相互干扰，容量规划必须考虑“吵闹邻居”问题。
- 成本可见性要求：云资源按秒计费，容量规划直接关联到云成本控制，成为FinOps的核心输入。
- 故障域隔离的硬约束：Kubernetes集群的节点故障域、可用区故障域、Region故障域对容量分布提出了严格的物理约束。
实践洞察：根据CNCF的调查，超过60%的Kubernetes生产事故与容量规划不足直接相关，其中最常见的模式是“弹性伸缩来不及响应突发流量”和“跨可用区容量分布不均导致单点过载”。
1.5 容量规划在云原生架构中的位置
下图展示了容量规划在云原生技术栈中的核心位置及其与周边系统的关系：
1.6 容量规划的关键指标框架
在实际操作中，容量规划需要建立一套完整的指标体系。以下表格列出了最常用的容量指标及其在云原生环境中的采集方式：
| 指标类别 | 具体指标 | 采集来源 | 典型阈值 |
|---|---|---|---|
| 计算资源 | CPU利用率、内存使用率、CPU Throttling | kubelet / cAdvisor / Prometheus Node Exporter | CPU 80% 告警，90% 紧急 |
| 网络资源 | 网络带宽利用率、连接数、丢包率 | CNI插件指标、eBPF、网络监控 | 带宽 70% 告警，90% 紧急 |
| 存储资源 | PV使用率、IOPS、延迟、inode使用率 | CSI驱动指标、Node Exporter | PV 85% 告警，95% 紧急 |
| 应用层 | RPS、P99延迟、错误率、队列深度 | 应用埋点、Istio/Envoy指标、APM | P99延迟超过SLO的120%告警 |
| 集群层 | Pod密度、节点利用率分布、可调度资源 | Kubernetes API Server、Descheduler | 节点资源碎片率 > 30% 告警 |
常见误区：很多团队只关注CPU和内存利用率，忽略了网络带宽和存储IOPS的容量规划。在云原生环境中，网络带宽瓶颈和存储性能衰减往往是导致容量塌陷的隐藏因素，尤其是在跨可用区流量和日志密集型工作负载中尤为突出。
1.7 容量规划与故障域隔离的关联
容量规划不能脱离故障域隔离独立进行。在Kubernetes多租户集群中，容量规划必须回答以下三个关键问题：
- 容量是否分布在正确的故障域中？——例如，是否在每个可用区都预留了足够的Pod容量以应对单可用区故障。
- 租户之间的容量隔离是否有效？——ResourceQuota和LimitRange是否与故障域边界对齐，避免一个租户的突发流量挤占其他租户的故障转移容量。
- 故障转移后的容量是否足够？——当某个节点或可用区失效时，剩余故障域是否有足够的冗余容量承载全部流量。