4. 镜像拉取流程分析：kubelet → containerd → 镜像仓库的完整链路与网络瓶颈识别

在集群升级过程中，镜像拉取是影响节点就绪时间的关键路径。理解从 kubelet 发起请求到 containerd 从远端镜像仓库下载数据的完整链路，能够帮助运维人员精准定位网络瓶颈，并为后续 Cilium 网络策略优化提供数据依据。本节将拆解该链路的每一跳，并给出瓶颈识别方法。

4.1 完整拉取链路与数据流向

一次典型的镜像拉取请求，在节点内部经过以下 5 个阶段：

1. kubelet 同步循环：kubelet 通过 CRI (Container Runtime Interface) 调用 containerd，携带镜像名称与认证信息。
2. containerd 本地缓存检查：containerd 检查本地内容存储 (Content Store) 是否存在该镜像的 manifest 和层数据。
3. 镜像仓库解析：若缓存未命中，containerd 解析镜像仓库地址（如 registry-1.docker.io 或私有仓库），执行 DNS 查询。
4. HTTPS 传输层：containerd 通过 TLS 连接镜像仓库，依次拉取 manifest 文件与各层 blob 数据。
5. 解压与写入：数据到达节点后，containerd 解压层数据并写入本地存储，返回成功状态给 kubelet。

4.2 各阶段网络瓶颈识别

下表总结了每个阶段可能出现的网络瓶颈及其典型表现：

4.3 网络瓶颈的量化识别方法

在集群升级期间，建议使用以下工具和方法对瓶颈进行量化：

• 节点级抓包分析：在目标节点执行 tcpdump -i any port 443 or port 53，观察 DNS 响应时间与 TCP 连接建立耗时。
• containerd 日志：查看 journalctl -u containerd -f，关注 pulling image 与 image unpacked 之间的时间差。
• Prometheus 指标：采集 container_image_pull_duration_seconds 与 container_image_pull_bytes_total，按镜像仓库标签聚合。
• 带宽监控：使用 iftop 或 nload 观察节点出站带宽是否达到上限（通常为 1 Gbps 或 10 Gbps）。

4.4 瓶颈与 Cilium 网络策略的关联

理解瓶颈位置后，才能设计有效的 Cilium 网络策略来优化拉取路径。以下为典型关联场景：

• DNS 瓶颈：Cilium 的 DNS 代理 (DNS Proxy) 可以缓存 DNS 响应，减少上游查询次数。
• 仓库连接瓶颈：Cilium 网络策略可限制非仓库流量，保障镜像仓库连接的带宽与优先级。
• 节点间镜像分发：若集群内配置了 Harbor 或 Dragonfly 等 P2P 分发方案，Cilium 策略需允许节点间的镜像层传输流量。

4.5 链路瓶颈快速排查清单

在升级过程中，若发现镜像拉取缓慢，可按以下清单逐级排查：

1. 检查 DNS 解析：dig +short <registry-host> 响应时间是否 > 100ms。
2. 检查 containerd 配置：确认 /etc/containerd/config.toml 中 max_concurrent_downloads 是否合理（建议 3~5）。
3. 检查节点带宽：使用 iperf3 测试节点到仓库的网络吞吐量。
4. 检查仓库限流：查看 containerd 日志中是否出现 429 Too Many Requests。
5. 检查磁盘 IO：iostat -x 1 观察 %util 是否持续 > 80%。