4. 镜像拉取流程基础：Kubernetes 镜像拉取流程与网络路径分析
在排查镜像拉取网络流量故障之前，必须准确理解 Kubernetes 从发起拉取到完成下载的完整链路。本章将拆解 kubelet → containerd → registry 的三层调用关系，并分析每一跳可能出现的网络瓶颈。
4.1 三层调用架构
Kubernetes 节点上的镜像拉取并非由单个组件完成，而是由 kubelet、容器运行时（containerd） 和 镜像仓库（registry） 协作完成。下表总结了各层的职责与网络行为：
| 层级 | 组件 | 核心职责 | 网络行为 |
|---|---|---|---|
| 1 | kubelet | 监听 Pod 规约，触发拉取指令 | 通过本地 gRPC 调用 containerd（Unix Socket） |
| 2 | containerd | 管理镜像层，执行拉取、解压、挂载 | 发起 HTTPS 请求到 registry（TCP 443） |
| 3 | registry | 存储镜像 Blob 与 Manifest | 响应 HTTP/2 请求，返回数据流 |
关键理解：kubelet 与 containerd 之间的通信走本地 Unix Socket，不经过网络栈；真正的网络流量发生在 containerd 与 registry 之间。因此，Cilium/Hubble 观测的重点是 containerd 到 registry 的出站连接。
4.2 完整拉取流程（步骤拆解）
一次典型的镜像拉取包含以下 6 个步骤，其中步骤 4-5 是网络流量最密集的阶段：
- kubelet 决策：kubelet 的
imageManager检查本地是否已存在目标镜像，若不存在则构造拉取请求。 - gRPC 调用：kubelet 通过 CRI（Container Runtime Interface）调用 containerd 的
PullImage接口，请求通过/run/containerd/containerd.sock传输。 - containerd 解析：containerd 解析镜像引用（如
docker.io/library/nginx:1.25），提取 registry 地址、仓库名、标签。 - HTTPS 握手：containerd 向 registry 发起 TCP 连接 → TLS 协商 → HTTP/2 请求。
- Blob 下载：containerd 依次拉取 Manifest 文件和各层 Blob（通常为 tar.gz 压缩包），每个 Blob 对应一个独立的 HTTP GET 请求。
- 解压与挂载：containerd 将下载的 Blob 解压到本地 snapshotter 目录，并返回成功状态给 kubelet。
流量特征：步骤 4-5 会产生大量出站流量，且每个 Blob 下载完成后连接可能复用（HTTP/2 多路复用）。若镜像较大（如 1GB+），单次拉取可能持续数十秒到数分钟。
4.3 网络路径分析（节点视角）
从网络数据包的角度，containerd 到 registry 的流量经过以下路径。下图展示了节点内部的网络栈与外部通信关系：
4.4 各阶段可能出现的网络故障
根据上述路径，镜像拉取失败通常发生在以下环节。排查时应按顺序检查：
| 阶段 | 故障现象 | 可能原因 | Hubble 观测指标 |
|---|---|---|---|
| DNS 解析 | no such host |
CoreDNS 不可达 / 域名不存在 | DNS 请求超时 / NXDOMAIN |
| TCP 连接 | connection refused |
防火墙拦截 / registry 端口未开放 | SYN 无 SYN-ACK / RST |
| TLS 握手 | tls: first record does not look like a TLS handshake |
代理劫持 / 证书不匹配 | TLS 握手失败计数 |
| HTTP 请求 | manifest unknown / blob unknown |
镜像标签错误 / registry 存储故障 | HTTP 404 / 500 响应码 |
| 数据下载 | i/o timeout / 拉取速度极慢 |
带宽不足 / 丢包 / 镜像层过大 | TCP 重传率 > 5% / 吞吐量低 |
常见误区：很多工程师在镜像拉取失败时直接怀疑 registry 不可达，却忽略了 DNS 解析 和 TLS 握手 这两个前置环节。使用 Hubble 观测时，应首先检查 DNS 请求是否成功返回 A 记录，再检查 TCP 握手是否完成。
4.5 使用 Hubble 观测拉取流量的切入点
在后续章节中，我们将通过 Hubble 的以下能力定位故障：
- 流量过滤：使用
--destination-fqdn registry.example.com过滤出 containerd 到 registry 的所有流量。 - TCP 状态追踪：观察
SYN、SYN-ACK、FIN序列，判断连接是否正常建立和关闭。 - HTTP 层解码：Hubble 支持解析 HTTP/2 帧，可直接看到
GET /v2/...请求和响应状态码。 - 重传与丢包：通过 Hubble Metrics 的
tcp.retransmit指标识别网络质量下降。