2. 镜像拉取原理：Docker/containerd 镜像拉取流程、镜像层（Layer）与 Manifest 结构

在生产环境中，镜像拉取速度直接影响 Pod 启动延迟和集群恢复时间（RTO）。理解镜像拉取的底层原理，是优化并发控制与 etcd 状态同步策略的前提。本节深入剖析 Docker / containerd 的镜像拉取流程、镜像层（Layer）与 Manifest 结构，为后续的并发控制策略奠定理论基础。

2.1 镜像拉取核心流程

无论是 Docker Engine 还是 containerd，镜像拉取都遵循 “索引 → Manifest → 层（Layer）→ 配置” 的递进式获取模型。整个流程可概括为以下步骤：

1. 解析镜像引用：将 registry.example.com/myapp:v1.2 解析为 registry 地址、仓库名和标签。
2. 获取 Manifest：向 registry 请求 /v2/<name>/manifests/<tag>，返回 Manifest 或 Manifest List（多架构索引）。
3. 解析 Manifest：提取配置层（Config Layer）和所有数据层（Layer）的摘要（Digest）与大小。
4. 并发拉取层：根据 Manifest 中的层列表，按依赖顺序（通常无依赖，可并行）向 registry 发起 /v2/<name>/blobs/<digest> 请求。
5. 解压与验证：每层下载完成后，计算摘要与 Manifest 中声明的 digest 比对，解压到本地存储（overlay2 或 snapshotter）。
6. 应用配置层：下载并解析 Config 层（JSON 格式），设置容器运行时参数（如 CMD、ENV、Entrypoint）。

2.2 镜像层（Layer）与 Manifest 结构

镜像由一组只读层（Layer）堆叠而成，每个层对应一个文件系统变更集。Manifest 是描述这些层和配置的元数据文件。

2.2.1 镜像层（Layer）

• 层定义：每个层是一个 tar.gz 压缩包，包含文件系统的增量变更（新增、修改、删除）。
• 层标识：通过 SHA256 摘要（Digest）唯一标识，格式为 sha256:abcdef...。
• 层存储：在 Docker 中存储在 /var/lib/docker/overlay2/；在 containerd 中存储在 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/。
• 层共享：相同摘要的层在节点上只存储一份，多个镜像可共享基础层（如 Ubuntu base layer）。

2.2.2 Manifest 结构

Manifest（v2 Schema 2）是一个 JSON 文档，包含以下核心字段：

2.3 镜像拉取流程 SVG 架构图

下图展示了从镜像引用到本地存储的完整拉取流程，包含关键组件与数据流向：

2.4 Manifest List（多架构索引）

当镜像支持多架构（如 amd64、arm64）时，Registry 返回的不是普通 Manifest，而是 Manifest List（也称为 OCI Index）。其结构如下：

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
  "manifests": [
    {
      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
      "size": 7143,
      "digest": "sha256:aaaa...",
      "platform": {"architecture": "amd64", "os": "linux"}
    },
    {
      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
      "size": 7143,
      "digest": "sha256:bbbb...",
      "platform": {"architecture": "arm64", "os": "linux"}
    }
  ]
}

2.5 层缓存与共享机制

镜像层在节点上的缓存策略直接影响拉取性能：

2.6 镜像拉取并发控制关键参数

containerd 和 Docker 均提供并发拉取控制参数，直接影响拉取速度和节点资源消耗：

2.7 镜像拉取与 etcd 状态同步的关联

镜像拉取状态是 etcd 中 Pod 状态机的重要输入。典型的状态转换如下：

• PodScheduled → 节点已分配，但镜像尚未拉取。
• Initialized → 镜像拉取完成，容器启动前。
• PodReady → 容器运行且健康检查通过。

在 etcd 中，镜像拉取状态通常通过 PodStatus.ContainerStatuses[].State.Waiting.Reason 字段体现，值为 ImagePullBackOff 或 ErrImagePull。控制面应监听这些状态变更，触发重试或重新调度。