4. 镜像拉取原理：kubelet 与 CRI、containerd/CRI-O 的交互流程

理解镜像拉取的完整链路，是进行容量规划与拉取加速优化的前提。当用户通过 kubectl run 或 Deployment 创建 Pod 时，kubelet 并不会直接调用容器运行时去拉取镜像，而是通过一套标准化的接口协议——CRI（Container Runtime Interface），与底层的 containerd 或 CRI-O 进行交互。整个流程涉及多个组件的有序协作，任何一个环节的瓶颈都会直接影响 Pod 启动速度。

4.1 核心组件与角色定义

在深入流程之前，先明确参与镜像拉取的四个关键角色：

4.2 镜像拉取完整交互流程

从 kubelet 发起 Pod 创建请求到镜像层全部落盘，共经历以下 7 个核心步骤：

1. kubelet 触发 SyncPod：kubelet 的 Pod 管理工作循环检测到新 Pod 需要调度到本节点，调用 SyncPod 方法。
2. kubelet 调用 CRI ImageService.PullImage：kubelet 根据 Pod Spec 中的 image 字段，构造 PullImageRequest，通过 gRPC 发送给 CRI shim。
3. CRI shim 解析请求：containerd 或 CRI-O 的 CRI 插件接收请求，解析镜像名称、标签、认证信息（imagePullSecrets）。
4. CRI shim 调用底层运行时 PullImage：将解析后的请求转发给 containerd 核心或 CRI-O 的镜像管理模块。
5. 镜像层下载与解压：运行时根据 manifest 获取镜像层列表，并发或顺序下载每一层（layer），并解压到 snapshotter 管理的快照目录。
6. 返回镜像引用：下载完成后，运行时返回镜像的 digest 和元数据给 CRI shim。
7. CRI shim 返回 PullImageResponse：kubelet 收到响应，确认镜像已就绪，继续执行后续的容器创建流程。

4.3 CRI 接口详解：ImageService 与 RuntimeService

CRI 定义了两种核心 gRPC 服务，镜像拉取属于 ImageService 的范畴：

kubelet 在 SyncPod 中会先调用 PullImage，确保镜像存在后，再调用 CreateContainer 和 StartContainer。如果镜像已经存在于节点本地缓存，kubelet 会跳过拉取步骤，直接使用已有镜像。

4.4 containerd 与 CRI-O 的内部实现差异

虽然两者都实现了 CRI 接口，但在镜像拉取的内部实现上存在关键差异，这些差异会影响拉取性能和资源消耗：

4.5 镜像拉取的关键性能瓶颈点

从交互流程中可以识别出以下四个主要瓶颈，它们直接影响 Pod 启动速度和节点资源消耗：

• 网络带宽与延迟：镜像层从 Registry 下载的速度受限于节点出口带宽和 Registry 的响应能力。大镜像（>1GB）在带宽不足时可能成为 Pod 启动的瓶颈。
• 磁盘 I/O 与解压性能：镜像层下载后需要解压并写入 snapshotter 目录。使用 HDD 或 IOPS 受限的磁盘时，解压和写入会成为瓶颈。
• 镜像层去重与缓存命中率：如果节点上多个 Pod 使用相同的基础镜像层，containerd/CRI-O 的 content-based 寻址可以避免重复下载。缓存命中率低时，每次拉取都需要完整下载。
• Registry 认证与限流：频繁的拉取请求可能触发 Registry 的速率限制（rate limit），导致拉取失败或排队等待。

4.6 镜像拉取流程中的关键数据结构

kubelet 发送给 CRI shim 的 PullImageRequest 包含以下关键字段，理解这些字段有助于排查拉取问题：

// PullImageRequest 是 kubelet 通过 CRI 发送给运行时的请求
message PullImageRequest {
  // 镜像的完整引用，如 docker.io/library/nginx:1.25
  ImageSpec image = 1;

  // 认证信息，来自 imagePullSecrets
  AuthConfig auth = 2;

  // Pod 沙箱配置，用于确定拉取镜像时的平台架构
  PodSandboxConfig sandbox_config = 3;
}

// ImageSpec 定义镜像的标识
message ImageSpec {
  // 镜像引用字符串
  string image = 1;

  // 可选的注解，用于传递额外元数据
  map<string, string> annotations = 2;
}

// AuthConfig 包含 Registry 认证凭据
message AuthConfig {
  string username = 1;
  string password = 2;
  string auth = 3;
  string server_address = 4;
  string identity_ = 5;
  string registry_ = 6;
}

当 kubelet 调用 PullImage 后，CRI shim 会返回 PullImageResponse，其中包含镜像的唯一标识（digest），用于后续的容器创建引用：

message PullImageResponse {
  // 镜像的引用，包含 digest，如 docker.io/library/nginx@sha256:abc123...
  string image_ref = 1;
}

4.7 镜像拉取流程的优化切入点

基于上述原理，可以从以下四个方向进行镜像拉取加速：