2. Deployment 基础回顾：ReplicaSet、Pod、滚动更新策略核心字段解析
在深入镜像拉取并发控制之前，必须牢固掌握 Deployment 的核心抽象层。Deployment 并不直接管理 Pod，而是通过 ReplicaSet 间接控制 Pod 的创建、更新与销毁。理解这三层关系以及滚动更新策略的关键字段，是后续调优并发行为的前提。
2.1 三层架构：Deployment → ReplicaSet → Pod
Deployment 是 Kubernetes 中最常用的工作负载控制器，它通过声明式配置驱动 ReplicaSet 的版本演进，而 ReplicaSet 则负责维持指定数量的 Pod 副本。三者形成清晰的“控制-编排-执行”层级：
核心关系：Deployment 只负责“版本策略”与“期望状态”，ReplicaSet 负责“副本计数”与“Pod 模板”，Pod 负责“实际容器运行”。滚动更新本质上是 Deployment 创建新 ReplicaSet、缩容旧 ReplicaSet 的过程。
2.2 ReplicaSet 的核心职责
ReplicaSet 是 Deployment 的“副本执行器”，其核心逻辑是一个简单的控制循环：
- 期望副本数（replicas）：从 Deployment 继承，ReplicaSet 确保集群中运行的 Pod 数量与此值一致。
- Pod 模板（template）：包含完整的 Pod 规约（容器镜像、端口、资源限制等），ReplicaSet 以此模板创建 Pod。
- 选择器（selector）：通过标签匹配管理 Pod，只有匹配选择器的 Pod 才会被计入副本计数。
关键认知：Deployment 的每次更新（如镜像版本变更）都会生成一个新的 ReplicaSet。旧 ReplicaSet 不会被立即删除，而是保留在历史记录中，用于快速回滚。
2.3 滚动更新策略核心字段解析
滚动更新策略定义在 spec.strategy.rollingUpdate 下，包含两个核心参数。这两个参数直接决定了镜像拉取的并发度与 Pod 替换节奏：
| 字段 | 类型 | 默认值 | 含义与并发影响 |
|---|---|---|---|
maxUnavailable |
int 或百分比 | 25% | 滚动更新期间允许的最大不可用 Pod 数量（相对于期望副本数）。值越大，并发销毁旧 Pod 的速率越高。 |
maxSurge |
int 或百分比 | 25% | 滚动更新期间允许超出期望副本数的最大 Pod 数量。值越大，并发创建新 Pod 的速率越高。 |
这两个参数共同决定了滚动更新的“并发窗口”：
- maxUnavailable = 1, maxSurge = 1：严格串行更新，一次只替换一个 Pod，镜像拉取并发度为 1。
- maxUnavailable = 25%, maxSurge = 25%：默认配置，对于 10 副本的 Deployment，允许同时最多 2 个 Pod 不可用、最多 2 个额外 Pod 被创建，镜像拉取并发度约为 2~4。
- maxUnavailable = 0, maxSurge = 1：先创建新 Pod 再销毁旧 Pod，保证零不可用，但镜像拉取并发度受限于 maxSurge。
镜像拉取并发陷阱：当 maxSurge 设置较大（如 50% 或 100%）时，Deployment 会同时触发大量新 Pod 创建，导致镜像拉取请求瞬间爆发。如果镜像仓库或节点带宽不足，可能引发拉取超时、失败甚至节点 OOM。
2.4 滚动更新流程与并发节奏
一次典型的滚动更新分为以下步骤，其中步骤 3 和步骤 4 直接产生镜像拉取并发：
- 创建新 ReplicaSet：Deployment 检测到 Pod 模板变更，生成新 ReplicaSet（v2），期望副本数为 0。
- 计算并发预算：根据 maxSurge 和 maxUnavailable 计算允许创建和销毁的 Pod 数量。
- 扩容新 ReplicaSet：新 ReplicaSet 开始创建 Pod，触发镜像拉取。创建数量受 maxSurge 限制。
- 缩容旧 ReplicaSet：旧 ReplicaSet 开始销毁 Pod，销毁数量受 maxUnavailable 限制。
- 循环迭代：重复步骤 3~4，直到所有 Pod 都迁移到新版本。
2.5 关键参数对比与选型建议
根据不同的业务场景，滚动更新策略的配置应有所侧重。下表总结了常见场景下的推荐配置：
| 场景 | maxUnavailable | maxSurge | 镜像拉取并发度 | 适用说明 |
|---|---|---|---|---|
| 严格零停机、低并发 | 0 | 1 | 1 | 先创建新 Pod 再销毁旧 Pod，适合关键在线服务 |
| 快速批量更新、高并发 | 50% | 50% | 较高（约副本数×50%） | 适合非关键批处理任务，需确保镜像仓库带宽充足 |
| 镜像拉取慢、仓库限流 | 1 | 1 | 1 | 串行拉取，避免仓库过载，适合大镜像或弱网络环境 |
| 默认均衡配置 | 25% | 25% | 中等（约副本数×25%） | 通用场景，兼顾可用性与更新速度 |
实践要点：在调整滚动更新策略前，务必评估镜像仓库的并发拉取能力、节点磁盘 I/O 以及网络带宽。对于大规模集群（副本数 > 50），建议将 maxSurge 控制在 10~20 以内，避免拉取风暴。