4. 容量规划原则：集群升级中的容量冗余设计原则（N+1、N+2冗余），预留资源比例计算
集群升级期间，控制面节点和工作节点会经历滚动重启、镜像拉取、Pod 重新调度等过程。如果集群没有预留足够的冗余资源，升级操作极易触发级联故障——节点驱逐 Pod 后，剩余节点因负载突增而进入资源竞争状态，导致关键组件 OOM 或被 kubelet 驱逐。容量规划的核心目标，就是通过冗余设计和预留比例计算，确保升级期间集群始终具备足够的“安全垫”。
4.1 冗余设计原则：N+1 与 N+2
冗余设计决定了集群在升级期间能容忍多少节点同时处于不可用状态。两种主流模型对比如下：
| 冗余模型 | 定义 | 升级期间可容忍故障节点数 | 资源利用率 | 适用场景 |
|---|---|---|---|---|
| N+1 | 集群总容量 = 业务峰值需求 + 1 个节点冗余 | 1 个节点 | 较高（约 85%~90%） | 非关键业务、可接受短时抖动、升级窗口短 |
| N+2 | 集群总容量 = 业务峰值需求 + 2 个节点冗余 | 2 个节点 | 中等（约 75%~80%） | 核心生产、金融/医疗、需同时升级多个节点池 |
实践建议：对于生产集群，至少采用 N+1 冗余。如果集群规模超过 50 个节点，或升级策略采用“一次升级一个节点池”的方式，建议升级为 N+2 冗余，以应对节点启动失败或镜像拉取超时等异常情况。
4.2 预留资源比例计算
预留资源比例 = (集群总可分配资源 - 业务峰值需求) / 集群总可分配资源 × 100%。计算时需考虑以下三个维度：
- 节点级预留：每个节点上 kubelet 保留的 system-reserved 和 kube-reserved 资源（通常为 5%~10%）。
- 升级缓冲预留：升级期间，被驱逐 Pod 的“突发资源需求”会叠加到剩余节点上。建议按“单节点最大 Pod 资源总和 × 1.5”估算。
- 安全系数：额外增加 5%~10% 的余量，应对镜像拉取带宽、节点启动时间等不可控因素。
计算公式（简化版）：
预留比例 = (集群总可分配资源 - 业务峰值需求) / 集群总可分配资源 × 100%
其中：
集群总可分配资源 = Σ(每个节点的 allocatable 资源)
业务峰值需求 = 过去 7 天 P95 资源使用量 × 1.2（含突发增长）
升级缓冲 = max(单节点最大 Pod 资源总和) × 1.5
安全系数 = 集群总可分配资源 × 5%
示例计算（N+1 场景）：
集群有 10 个节点，每个节点 allocatable CPU = 8 核，总可分配 = 80 核。
业务峰值需求（P95 × 1.2）= 60 核。
升级缓冲 = 单节点最大 Pod 资源（6 核）× 1.5 = 9 核。
安全系数 = 80 × 5% = 4 核。
实际预留 = 80 - 60 - 9 - 4 = 7 核，预留比例 = 7 / 80 ≈ 8.75%。
结论：当前集群仅满足 N+0.5 冗余，需扩容至 12 个节点才能达到 N+1 标准。
集群有 10 个节点，每个节点 allocatable CPU = 8 核，总可分配 = 80 核。
业务峰值需求（P95 × 1.2）= 60 核。
升级缓冲 = 单节点最大 Pod 资源（6 核）× 1.5 = 9 核。
安全系数 = 80 × 5% = 4 核。
实际预留 = 80 - 60 - 9 - 4 = 7 核，预留比例 = 7 / 80 ≈ 8.75%。
结论：当前集群仅满足 N+0.5 冗余，需扩容至 12 个节点才能达到 N+1 标准。
4.3 冗余设计决策流程
下图展示了从业务需求到冗余模型选择的完整决策路径：
4.4 不同冗余模型下的预留比例参考
以下表格给出了不同集群规模和冗余模型下的推荐预留比例范围（基于 CPU 资源，内存类似）：
| 集群规模（节点数） | 冗余模型 | 推荐预留比例（CPU） | 推荐预留比例（内存） | 备注 |
|---|---|---|---|---|
| 10 ~ 30 | N+1 | 10% ~ 15% | 12% ~ 18% | 小集群，单节点故障影响大 |
| 30 ~ 50 | N+1 | 8% ~ 12% | 10% ~ 15% | 中等规模，可适当降低 |
| 50 ~ 100 | N+2 | 12% ~ 18% | 15% ~ 20% | 大集群，需容忍 2 节点故障 |
| > 100 | N+2 | 15% ~ 20% | 18% ~ 25% | 超大规模，考虑节点池分组 |
常见误区：预留比例不是越高越好。过高的预留会导致资源浪费和成本上升。建议以“升级缓冲 + 安全系数”为下限，以“业务容忍的额外成本”为上限，在两者之间取平衡。如果预留比例超过 25%，应优先考虑优化 Pod 资源请求（requests）而非继续扩容。
4.5 升级期间的动态资源调整
除了静态的冗余设计，升级过程中还可以通过以下策略动态调整资源分配：
- 节点优雅驱逐（Graceful Node Shutdown）：设置 PodDisruptionBudget（PDB），确保每个应用至少保留指定数量的副本。
- 临时扩容（Scale-out）：在升级前，通过 Cluster Autoscaler 或手动方式临时增加 1~2 个节点，升级完成后回收。
- 资源配额（ResourceQuota）调整：升级期间，适当降低非关键命名空间的资源配额，将资源让给核心业务。
- 优先级与抢占（Priority & Preemption）：为关键系统组件（如 CoreDNS、kube-proxy）设置高优先级，确保它们在资源竞争时不会被驱逐。
容量规划不是一次性活动。每次升级前，都应重新评估业务峰值、节点健康状态和冗余模型，确保预留比例始终覆盖升级缓冲与安全系数。只有将冗余设计融入升级 SOP，才能真正实现“零中断升级”。