4. 临时资源预留定义：什么是升级期间的临时资源预留？它与常规 Buffer 的区别
4.1 临时资源预留的核心定义
在 K8s 集群升级（尤其是控制面或节点池滚动升级）过程中，临时资源预留是指为了应对升级期间 Pod 迁移、节点排水、新 Pod 调度等操作带来的瞬时资源需求峰值，而额外预留的一批计算资源（CPU、内存、临时存储）。
其本质是：在升级窗口内，为“资源重分布”提供安全垫。当节点被封锁并排水时，其上的 Pod 需要被调度到其他可用节点；如果集群没有足够的空闲资源接纳这些“流浪 Pod”，就会导致 Pod 调度失败、服务降级甚至中断。
关键特征：
- 时间窗口性：只在升级操作期间存在，升级完成后即可回收。
- 动态性：预留量随升级批次、节点规格、Pod 副本数动态变化。
- 不可抢占性：这部分资源不能被常规业务 Pod 使用，必须为升级期间的迁移流量保留。
4.2 临时资源预留 vs. 常规 Buffer：核心差异
很多团队容易将“临时资源预留”与日常容量规划中的“常规 Buffer”混为一谈。两者虽然都表现为“闲置资源”，但目的、生命周期和管理方式截然不同。下表从 7 个维度进行对比：
| 对比维度 | 临时资源预留（Upgrade Buffer） | 常规 Buffer（Headroom） |
|---|---|---|
| 目的 | 应对升级期间 Pod 迁移的瞬时调度压力 | 应对日常流量突发、HPA 扩容、节点故障 |
| 生命周期 | 仅在升级窗口内存在（分钟~小时级） | 持续存在（7×24 小时） |
| 触发条件 | 由升级操作（节点排水、封锁）主动触发 | 由业务指标（CPU 利用率、QPS）被动触发 |
| 资源粒度 | 按批次计算，通常为“单批次最大迁移量” | 按集群整体水位计算，通常为“峰值余量” |
| 回收方式 | 升级完成后立即释放，可被业务重新使用 | 长期保留，一般不主动回收 |
| 成本属性 | 短期、可预测的额外成本 | 长期、固定的“保险”成本 |
| 管理工具 | 升级策略、PDB、节点预算 | Cluster Autoscaler、HPA、VPA |
实践建议：常规 Buffer 通常设置为集群总容量的 10%~20%，而临时资源预留量应基于“最大并发排水节点数 × 单节点平均 Pod 资源请求量”精确计算，避免与常规 Buffer 叠加后造成过度预留。
4.3 临时资源预留的运作机制（SVG 流程图）
下图展示了在 K8s 节点滚动升级过程中，临时资源预留如何被创建、使用和回收：
4.4 临时资源预留的典型场景与计算示例
假设一个生产集群的节点规格为 32 vCPU / 128 GB 内存，每个节点平均运行 30 个 Pod，Pod 平均资源请求为 0.5 vCPU / 2 GB。升级策略为每次并发排水 2 个节点：
# 临时资源预留量计算
单节点 Pod 总请求 = 30 × (0.5 vCPU + 2 GB) = 15 vCPU + 60 GB
单批次排水量 = 2 节点 × (15 vCPU + 60 GB) = 30 vCPU + 120 GB
安全系数 = 1.2（考虑调度碎片和重试）
临时预留量 = 30 vCPU × 1.2 = 36 vCPU
临时预留量 = 120 GB × 1.2 = 144 GB
# 集群总容量假设：10 节点 = 320 vCPU / 1280 GB
# 常规 Buffer（15%）= 48 vCPU / 192 GB
# 升级期间总预留 = 常规 Buffer + 临时预留 = 84 vCPU / 336 GB
# 占比 = 84/320 = 26.25%（仍在 30% 安全线内）
⚠️ 常见误区：
- 误区一：认为临时预留可以完全替代常规 Buffer。实际上，常规 Buffer 应对的是日常突发，临时预留应对的是升级迁移，两者是互补关系，不能相互替代。
- 误区二：将临时预留量设置得过大（如超过集群 50% 容量），导致升级期间业务 Pod 无资源可用，反而引发调度失败。
- 误区三：升级完成后忘记回收临时预留资源，造成长期资源浪费。
4.5 临时资源预留与常规 Buffer 的协同模型（SVG 架构图）
下图从集群容量视角，展示临时资源预留与常规 Buffer 在集群资源池中的分层关系：
4.6 总结：一句话定义
临时资源预留 = 在 K8s 集群升级窗口内，为承接节点排水产生的迁移 Pod 而临时划拨的、可精确计算且升级后立即回收的弹性资源池；它与常规 Buffer 的核心区别在于生命周期（临时 vs. 永久）和触发条件（升级操作 vs. 业务突发），两者在容量规划中应分层管理、协同运作。