3. 节点池升级的挑战
节点池升级是集群运维中最频繁、风险最高的操作之一。当底层节点操作系统、容器运行时或 kubelet 版本需要更新时，平台必须将旧节点上的 Pod 迁移到新节点，同时保证业务不中断。本节将深入分析节点池升级的标准流程、滚动升级原理，以及镜像拉取如何成为升级速度的瓶颈。
3.1 节点池升级流程
一个完整的节点池升级通常包含以下 6 个阶段：
| 阶段 | 操作内容 | 耗时占比 |
|---|---|---|
| 1. 节点置为不可调度 | 执行 kubectl cordon <node>，阻止新 Pod 调度到该节点 |
~1% |
| 2. Pod 驱逐 | 执行 kubectl drain，优雅驱逐节点上所有 Pod |
~5% |
| 3. 节点初始化/重装 | 云厂商或裸金属平台重装操作系统、安装 kubelet 等组件 | ~20% |
| 4. 节点加入集群 | 新节点完成 kubelet 注册，状态变为 Ready | ~4% |
| 5. 镜像拉取 | 节点从镜像仓库拉取业务 Pod 所需的所有容器镜像 | ~60% |
| 6. Pod 调度与启动 | 调度器将 Pod 分配到新节点，容器运行时启动容器 | ~10% |
关键洞察： 镜像拉取阶段耗时占比高达 60%，是节点池升级速度的最主要瓶颈。在大型集群中，一个节点可能需要拉取 10~30 个不同镜像，总数据量可达数 GB。
3.2 滚动升级原理
节点池升级通常采用滚动升级（Rolling Update）策略，即逐个或分批替换节点，而不是一次性升级所有节点。其核心流程如下：
- 设置最大不可用节点数（例如 maxUnavailable=1），保证集群中始终有足够节点运行工作负载。
- 选择一个旧节点，执行 cordon + drain，将 Pod 迁移到其他健康节点。
- 创建新节点（或重装旧节点），等待其 Ready。
- 新节点拉取镜像，调度器将待调度 Pod 分配到该节点。
- 重复步骤 2~4，直到所有旧节点被替换。
最佳实践： 设置
maxUnavailable=1 且 maxSurge=0 是最保守的滚动升级策略，适合生产环境。如果业务有 PodDisruptionBudget（PDB），drain 阶段会等待 PDB 允许后再驱逐 Pod。
3.3 升级过程中的镜像拉取瓶颈分析
镜像拉取成为瓶颈的根本原因在于：每个新节点都需要从零开始拉取所有业务镜像。在滚动升级场景下，这种“重复拉取”问题被放大。以下是具体的瓶颈分析：
3.3.1 镜像拉取时间构成
一个镜像的拉取时间由以下因素决定：
| 因素 | 典型耗时 | 说明 |
|---|---|---|
| 镜像层元数据查询 | 0.5~2 秒 | 向镜像仓库发起 manifest 请求，获取层列表 |
| 层下载（网络传输） | 5~120 秒/GB | 取决于镜像大小、网络带宽、仓库限速 |
| 层解压与校验 | 2~10 秒/GB | CPU 密集型操作，受节点计算能力影响 |
| 存储写入 | 1~5 秒/GB | 写入容器运行时存储目录（overlay2 等） |
典型场景： 一个包含 10 个镜像（平均大小 500MB）的节点，在 100Mbps 带宽下，仅网络传输就需要约 400 秒（6.7 分钟）。加上解压和校验，总拉取时间可达 8~10 分钟。
3.3.2 滚动升级中的“重复拉取”问题
在滚动升级过程中，每个新节点都需要独立拉取相同的镜像集。假设节点池有 10 个节点，每个节点需要拉取 5GB 镜像，总拉取数据量高达 50GB。这种重复拉取带来三个严重问题：
- 镜像仓库压力激增： 多个节点同时拉取相同镜像，仓库出口带宽被迅速占满，导致拉取速度下降。
- 升级周期线性增长： 每批次升级时间 = 节点初始化时间 + 镜像拉取时间。镜像拉取时间不随批次减少而缩短。
- 网络带宽浪费： 相同的数据在集群内部被反复传输，造成不必要的网络开销。
3.3.3 瓶颈量化分析
以下表格对比了不同节点池规模下的镜像拉取总耗时：
| 节点池规模 | 单节点镜像量 | 传统方式总耗时 | 预拉取方式总耗时 | 节省比例 |
|---|---|---|---|---|
| 10 节点 | 5 GB | ~80 分钟 | ~12 分钟 | 85% |
| 50 节点 | 5 GB | ~400 分钟 | ~15 分钟 | 96% |
| 100 节点 | 5 GB | ~800 分钟 | ~18 分钟 | 98% |
注意： 传统方式的总耗时随节点数线性增长，而预拉取方式的总耗时基本恒定（仅受预拉取节点带宽和节点间分发速度影响）。在 100 节点规模下，预拉取可将升级时间从 13 小时缩短至 18 分钟，提升幅度超过 40 倍。
3.3.4 其他瓶颈因素
- 镜像仓库限速： 大多数公有云镜像仓库（如 Docker Hub、ACR、ECR）对单个 IP 或账号有拉取速率限制（rate limit）。大规模并发拉取极易触发限速，导致拉取失败或降速。
- 节点磁盘 I/O： 镜像层解压和写入需要大量磁盘 I/O。如果节点使用普通 HDD 或 IOPS 受限的云盘，解压阶段会成为新的瓶颈。
- 容器运行时差异： containerd 和 Docker 在镜像拉取和解压性能上存在差异。containerd 的镜像拉取性能通常优于 Docker，但在大规模并发场景下仍需优化。
- 镜像层复用率低： 如果业务镜像没有合理分层（例如每个镜像都包含完整的基础层），层复用率低，导致拉取数据量增大。
优化方向： 针对上述瓶颈，业界提出了多种优化方案，包括：节点本地镜像缓存、分布式镜像仓库、P2P 镜像分发（如 Dragonfly）、以及本课程重点介绍的容器镜像预拉取策略。预拉取策略通过提前将镜像分发到目标节点，从根本上消除了升级过程中的镜像拉取等待时间。