2. 容量管理基础理论
2.1 什么是容量管理
容量管理（Capacity Management）是一套持续性的规划、监控与调整流程，旨在确保 IT 资源在正确的时间、以正确的规模、满足业务负载需求，同时避免过度投资或资源浪费。在 Kubernetes 语境下，容量管理聚焦于集群的 计算（CPU）、内存、存储 和 网络 四大维度。
核心定义：容量管理 = 需求预测 + 资源供给 + 持续调优，三者形成闭环。
容量管理并非一次性规划，而是贯穿集群全生命周期的动态过程。它需要回答三个关键问题：
- 当前容量够吗？——实时监控与告警
- 未来容量够吗？——趋势分析与预测
- 如何高效利用？——调度策略与资源优化
2.2 容量管理的目标：SLA / SLO / SLI
容量管理的最终目标是通过量化的服务等级协议（SLA）、服务等级目标（SLO）和服务等级指标（SLI）来驱动决策。三者构成一个从抽象承诺到具体测量的层级体系。
| 术语 | 定义 | 示例（K8s 场景） | 责任方 |
|---|---|---|---|
| SLA（Service Level Agreement） | 对外承诺的合同级协议，通常包含惩罚条款 | “集群月度可用性 ≥ 99.99%” | 业务方 / 客户 |
| SLO（Service Level Objective） | 内部设定的可达成目标，比 SLA 更严格 | “Pod 调度延迟 P99 ≤ 2s” | SRE / 平台团队 |
| SLI（Service Level Indicator） | 实际测量的量化指标，用于评估 SLO 达成情况 | “过去 30 天 Pod 调度延迟 P99 = 1.8s” | 监控系统 |
实践要点：SLO 通常比 SLA 严格 10%~30%，为意外留出缓冲。例如 SLA 要求 99.9% 可用性，内部 SLO 应设为 99.95% 或更高。
容量管理直接服务于 SLO 的达成。当 SLI 持续偏离 SLO 阈值时，容量管理流程应自动触发扩容、缩容或调度策略调整。
2.3 容量管理在 K8s 中的重要性
Kubernetes 的动态调度、弹性伸缩和声明式管理特性，使得容量管理比传统虚拟机环境更具挑战性，也更具价值。以下是 K8s 场景下容量管理的五个关键重要性维度：
| 维度 | 重要性说明 | 典型风险 |
|---|---|---|
| 资源碎片化 | Pod 调度不均导致节点资源碎片，无法调度大 Pod | 集群利用率低，需额外节点 |
| 突发流量 | HPA / VPA 依赖容量预留，否则扩容无资源可用 | 服务雪崩，SLA 违约 |
| 成本控制 | 云上节点按需付费，容量过剩直接增加账单 | 月成本超预算 30%~50% |
| 节点故障 | Pod 重新调度需要空闲容量作为缓冲 | 故障恢复时间延长 |
| 版本升级 | 节点滚动升级需要额外容量承载迁移 Pod | 升级阻塞，集群不可用 |
常见误区：很多团队认为 K8s 自动伸缩（CA/HPA）可以完全替代容量规划。实际上，自动伸缩是容量管理的执行工具，而非规划本身。没有合理的容量基线，自动伸缩可能导致“扩容来不及”或“缩容太激进”的双重问题。
2.4 容量管理的核心流程
一个完整的容量管理流程包含以下五个阶段，形成持续改进的闭环：
- 需求分析：收集业务负载特征（QPS、并发数、数据量），转换为资源需求（CPU 核数、内存 GB、存储 IOPS）。
- 基线建立：通过历史监控数据建立资源使用基线，识别波峰波谷周期。
- 容量规划：基于基线 + 增长预测，制定节点规格、数量、预留缓冲比例。
- 执行与监控：部署 Cluster Autoscaler、HPA/VPA，实时跟踪 SLI 指标。
- 审计与优化：定期复盘容量利用率，调整 Request/Limit、节点池配置、调度策略。
关键指标速查：
- 集群利用率：（已分配 Request / 总容量）× 100%，建议目标 60%~80%
- 节点装箱率：（节点已分配资源 / 节点可分配资源）× 100%，避免超过 90% 导致调度失败
- 扩缩容延迟：从触发条件到 Pod Ready 的时间，目标 < 5 分钟