2. Containerd 架构深度解析：gRPC API、Shim 进程、Snapshotter、运行时的协作流程

在集群节点扩容场景中，理解 Containerd 的内部协作机制是进行资源分配与性能调优的前提。本章将深入剖析 Containerd 的核心组件——gRPC API、Shim 进程、Snapshotter 以及 运行时（runc/runsc）——之间的数据流与协作关系，揭示从用户请求到容器进程启动的完整链路。

2.1 整体架构与协作流程概览

Containerd 采用模块化设计，各组件通过 gRPC 协议进行通信。下图展示了从客户端发起请求到容器运行的核心协作流程：

2.2 gRPC API 层：统一的通信入口

gRPC API 是 Containerd 对外暴露的唯一接口，所有客户端（如 ctr CLI、kubelet）都通过此接口与 Containerd 交互。API 定义在 containerd/services 包中，主要服务包括：

2.3 Snapshotter：容器根文件系统的构建者

Snapshotter 负责管理容器镜像的层（Layer）数据，并为每个容器准备可写层（Rootfs）。Containerd 默认使用 overlayfs 快照器，它利用 Linux 内核的 OverlayFS 实现高效的层叠文件系统。

Snapshotter 的工作流程分为以下步骤：

1. Prepare：根据镜像配置，准备一个挂载点，将镜像层和容器层组合成可用的根文件系统。
2. Mounts：返回挂载信息（如 lowerdir、upperdir、workdir），供后续运行时使用。
3. Commit：将容器运行期间产生的变更提交为新的快照层（通常用于构建新镜像）。
4. Remove：容器销毁后，清理对应的快照数据。

2.4 Shim 进程：容器生命周期的守护者

Shim 进程（containerd-shim）是 Containerd 架构中最具特色的组件。它作为 Containerd 主进程与容器运行时之间的中间层，承担以下职责：

• 生命周期管理：每个容器对应一个独立的 Shim 进程，负责监控容器进程状态。
• IO 重定向：将容器的标准输入/输出/错误流重定向回 Containerd 主进程。
• 退出状态上报：当容器进程退出时，Shim 捕获退出码并通知 Containerd。
• 解耦设计：即使 Containerd 主进程重启或崩溃，Shim 进程依然存活，容器不受影响。

Shim 进程的启动流程如下：

1. Containerd 主进程通过 gRPC 收到 Create 任务请求。
2. 主进程 fork 出一个新的 Shim 进程，并传递容器配置信息。
3. Shim 进程调用运行时（如 runc）创建并启动容器。
4. Shim 进程持续运行，通过 Unix Domain Socket 与 Containerd 主进程通信。
5. 容器退出后，Shim 进程上报退出状态，然后自行退出。

2.5 运行时（runc / runsc）：容器进程的执行者

运行时是容器技术的底层执行引擎，负责真正创建和运行容器进程。Containerd 支持多种运行时，最常用的是 runc（标准 OCI 运行时）和 runsc（gVisor 沙箱运行时）。

2.6 完整协作流程：从请求到容器运行

以下是一个完整的容器创建请求在 Containerd 内部的流转过程：

1. 客户端发起请求：kubelet 或 ctr 通过 gRPC 调用 Tasks.Create 方法。
2. 核心服务层处理：Containerd 主进程解析请求，验证命名空间和容器元数据。
3. Snapshotter 准备根文件系统：调用 Snapshots.Prepare 方法，挂载 OverlayFS 并返回挂载点路径。
4. 创建 Shim 进程：主进程 fork 出 containerd-shim，传递容器 ID、挂载信息、运行时配置等。
5. Shim 调用运行时：Shim 进程根据配置调用 runc（或 runsc），执行 runc create 和 runc start。
6. 运行时创建容器：runc 利用 cgroups 和命名空间创建隔离环境，挂载根文件系统，启动容器进程。
7. 状态上报：Shim 进程持续监控容器状态，通过 gRPC 流式接口向 Containerd 主进程上报。
8. 返回响应：Containerd 主进程向客户端返回容器创建成功响应。

2.7 组件协作的故障排查要点

当容器启动失败或性能异常时，可以按照以下链路进行排查：