1. 课程导论：为什么需要关注 Deployment 升级时的资源预留？资源画像与临时预留的核心概念
1.1 升级时的“隐形风险”：资源争抢与 Pod 驱逐
在 Kubernetes 集群中，Deployment 滚动升级是最常见的变更操作。然而，升级过程中 新 Pod 创建 与 旧 Pod 销毁 并非瞬间完成，而是存在一段短暂的“共存期”。这段窗口期内，集群资源（CPU、内存）面临双重压力：
- 新 Pod 启动峰值：新副本启动时，应用初始化、JVM 预热、缓存加载等操作往往产生远高于稳态运行的资源消耗。
- 旧 Pod 残留占用：旧 Pod 在优雅终止期间仍持有部分资源，尤其是内存，不会立即释放。
若未预留足够的“缓冲资源”，极易触发 节点资源紧张 → kubelet 驱逐 Pod → 服务中断 的连锁反应。以下表格对比了有无资源预留的升级表现：
| 对比维度 | 无资源预留 | 有临时资源预留 |
|---|---|---|
| 升级期间资源水位 | 接近或超过节点容量 | 始终低于安全阈值 |
| Pod 驱逐风险 | 高（尤其内存密集型应用） | 低 |
| 升级速度 | 被迫降速或卡死 | 平稳滚动 |
| 对同节点其他 Pod 影响 | 明显（资源争抢） | 几乎无影响 |
⚠️ 常见误区： 很多团队认为“只要设置了 requests/limits 就安全了”。实际上，requests 仅保证调度阶段的资源预留，无法阻止升级过程中因新旧 Pod 共存导致的瞬时超分。
1.2 核心概念：资源画像与临时预留
要解决上述问题，需要引入两个核心概念：资源画像 和 临时资源预留。它们分别回答“需要多少资源”和“如何临时锁定资源”两个关键问题。
1.2.1 资源画像：从“静态配置”到“动态感知”
资源画像是指通过分析 Pod 的历史运行数据（CPU 使用率、内存 RSS、网络 I/O 等），建立其在不同生命周期阶段（启动、稳态、峰值）的资源需求模型。传统做法是运维人员凭经验设置 requests/limits，往往导致：
- 过度预留：requests 设置过高，集群利用率低下。
- 预留不足：低估启动峰值，升级时触发 OOMKill。
资源画像的目标是输出 精细化资源基线，例如：
- 启动阶段：CPU 2.5 核 / 内存 1.8 GiB（持续 90 秒）
- 稳态阶段：CPU 0.8 核 / 内存 1.2 GiB
- 峰值阶段：CPU 3.0 核 / 内存 2.1 GiB（持续 30 秒）
1.2.2 临时资源预留：升级期间的“资源保险”
临时资源预留是指在 Deployment 升级期间，临时性地 在目标节点上为即将创建的新 Pod 预留出足够的资源空间，确保其启动阶段不会因资源不足而失败。它与永久性 requests 的区别如下：
| 特性 | 永久性 requests | 临时资源预留 |
|---|---|---|
| 生效时间 | Pod 整个生命周期 | 仅升级窗口期（秒~分钟级） |
| 资源量 | 基于稳态需求 | 基于启动峰值需求 |
| 释放机制 | Pod 删除后释放 | 新 Pod 就绪后自动释放 |
| 对集群利用率影响 | 长期占用 | 短期占用，几乎无影响 |
💡 类比理解： 永久性 requests 相当于“长期租房”，临时资源预留相当于“酒店钟点房”——只在需要时（升级启动阶段）临时占用，用完即退。
1.3 核心流程：资源画像驱动的升级预留
下图展示了从资源画像到临时预留的完整闭环流程：
1.4 本课程的核心收益
通过本课程的学习，你将掌握以下能力：
- 精准画像：基于生产数据生成 Pod 启动/稳态/峰值资源基线，告别“拍脑袋”配置。
- 动态预留：在升级触发时自动计算并锁定临时资源，保障新 Pod 启动安全。
- 零成本释放：新 Pod 就绪后立即回收预留资源，不浪费集群容量。
- 可观测性：通过监控面板实时查看预留状态与资源水位。
📌 课程定位： 本课程面向 Kubernetes 平台工程师、SRE、运维开发人员，要求学员具备基本的 Deployment 操作经验和 Pod 资源管理概念。课程将提供完整的 资源画像算法 + Operator 实现 + 生产部署方案，可直接落地到现有集群。