2. Kubernetes 镜像拉取基础：kubelet 镜像拉取流程、镜像层与 manifest 结构

2.1 镜像拉取的核心参与者

在 Kubernetes 集群中，镜像拉取并非由 kube-apiserver 或 scheduler 直接执行，而是由每个节点上的 kubelet 组件负责。kubelet 通过 CRI（Container Runtime Interface）与容器运行时（如 containerd、CRI-O）交互，最终由运行时完成镜像层的下载与解包。

从容量规划角度看，理解这一流程有助于定位拉取瓶颈：是 kubelet 的并发控制不足，还是运行时下载带宽受限，或是镜像仓库的限流策略导致。

2.2 kubelet 镜像拉取流程

kubelet 内部维护一个 imageManager，负责管理镜像拉取请求。其核心流程如下：

1. Pod 调度到节点：kubelet 从 apiserver 监听到 Pod 绑定事件，开始创建 Pod 沙箱。
2. 解析容器镜像：kubelet 读取 Pod Spec 中的 image 字段，提取镜像名称与标签（如 nginx:1.25）。
3. 检查本地缓存：通过 CRI 调用 ImageStatus 检查镜像是否已存在于节点本地存储。
4. 拉取决策：若本地不存在，或 imagePullPolicy 为 Always，则触发拉取。
5. 加入拉取队列：kubelet 的 imageManager 将请求加入一个 串行队列（默认串行拉取，可通过 --serialize-image-pulls 调整）。
6. CRI 调用 PullImage：kubelet 调用容器运行时的 PullImage gRPC 接口，传递镜像引用与认证信息。
7. 运行时下载镜像层：容器运行时根据 manifest 获取镜像层列表，逐层下载并解包到本地存储。
8. 返回结果：拉取完成后，kubelet 更新 Pod 状态，继续后续的容器创建流程。

2.3 镜像层与 manifest 结构

容器镜像由多个只读层（Layer）叠加而成，每一层对应 Dockerfile 中的一条指令。镜像的元数据由 manifest（清单）描述，它是镜像仓库中最重要的索引文件。

2.3.1 镜像层结构

每个镜像层是一个压缩的 tar 包，包含文件系统的增量变更。层与层之间通过 内容寻址（Content-Addressable）方式标识，使用 SHA256 摘要作为唯一 ID。

2.3.2 Manifest 结构

Manifest 是镜像的“目录文件”，包含以下关键字段：

• schemaVersion：清单格式版本，目前主流为 2。
• mediaType：媒体类型，如 application/vnd.docker.distribution.manifest.v2+json。
• config：指向镜像配置文件的引用，包含环境变量、入口点、默认命令等。
• layers：镜像层列表，每个元素包含 digest（摘要）、size（压缩后大小）、mediaType。

以下是一个简化版的 manifest 示例：

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
  "config": {
    "mediaType": "application/vnd.docker.container.image.v1+json",
    "size": 7023,
    "digest": "sha256:config_digest_here"
  },
  "layers": [
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "size": 28000000,
      "digest": "sha256:layer1_digest"
    },
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "size": 1500000,
      "digest": "sha256:layer2_digest"
    }
  ]
}