1. 课程导论：为什么需要控制滚动更新中的镜像拉取并发？常见痛点与场景

在 Kubernetes 生产环境中，Deployment 滚动更新是最常用的无状态应用发布方式。默认情况下，kube-controller-manager 通过 maxSurge 和 maxUnavailable 两个参数控制 Pod 的创建与销毁速率，但并未对镜像拉取（Image Pull）这一环节做任何并发限制。当集群规模较大、镜像体积较大或镜像仓库存在限流策略时，不加控制的并发拉取会引发一系列严重问题。

1.1 核心痛点：镜像拉取并发失控的连锁反应

下图展示了滚动更新中镜像拉取并发过高时，从节点到镜像仓库再到控制平面的完整故障链路：

1.2 常见痛点场景

场景	现象描述	根因分析	影响范围
大镜像批量更新	滚动更新启动后，数十个 Pod 同时拉取 1GB+ 的镜像，节点网络带宽瞬间打满，拉取时间从 30s 延长至 5min+	kubelet 默认无镜像拉取队列控制，所有新 Pod 的 imagePullPolicy 同时触发	更新速度下降 10x，Pod 启动超时，就绪探针失败
镜像仓库限流	Docker Hub / 自建 Harbor 返回 429 Too Many Requests，部分 Pod 拉取失败进入 ImagePullBackOff	仓库侧并发连接数超过阈值（通常匿名用户 100 次/6h，认证用户 200 次/6h）	更新中断，部分 Pod 无法调度，需要手动删除重试
节点磁盘 I/O 风暴	节点上同时解压多个大镜像层，磁盘写延迟从 5ms 飙升至 500ms，影响节点上所有容器的文件读写	containerd / dockerd 解压镜像层时大量占用磁盘 I/O，且无全局并发限制	节点上其他业务容器响应变慢，甚至触发 Liveness 探针失败
跨地域拉取	集群节点分布在多个地域，滚动更新时所有节点同时从中心仓库拉取，跨地域带宽被占满	未配置 P2P 分发或镜像缓存，所有流量回源到单一仓库	拉取延迟增加 3-5 倍，部分节点因超时拉取失败

1.3 为什么默认配置无法解决？

Kubernetes 原生提供的滚动更新参数仅控制 Pod 的创建与销毁速率，并不控制镜像拉取这一子步骤的并发度：

以下表格对比了原生参数与实际需要的控制维度：

控制维度	原生参数	控制粒度	是否控制镜像拉取并发
Pod 创建速率	maxSurge	Deployment 级别	❌ 否
Pod 不可用上限	maxUnavailable	Deployment 级别	❌ 否
节点镜像拉取串行化	serializeImagePulls	kubelet 节点级别	⚠️ 仅控制单节点串行/并行，无全局并发限制
镜像拉取 QPS 限制	registry-qps / registry-burst	kubelet 节点级别	⚠️ 仅限制单节点到仓库的请求速率，不控制 Pod 创建侧的并发

1.4 本课程要解决的核心问题

通过本课程，你将掌握以下四种主流控制技巧，能够根据实际场景灵活组合使用：

1. kubelet 参数调优 — 通过 serializeImagePulls、registry-qps、registry-burst 控制单节点镜像拉取并发与速率。
2. Deployment 滚动更新策略精细化 — 利用 maxSurge、maxUnavailable 与 progressDeadlineSeconds 的组合，间接控制镜像拉取并发峰值。
3. Sidecar 限流 + 优雅启动 — 在 Pod 内注入 Init Container 或 Sidecar，实现镜像拉取后的二次限流与就绪等待。
4. Operator 级全局并发控制 — 通过自定义控制器或 Flagger / Argo Rollouts 等渐进式交付工具，实现集群维度的镜像拉取并发调度。