3. containerd 整体架构：核心组件总览

containerd 的设计哲学是“简洁、可插拔、专注运行时”。它并非一个单体二进制，而是由多个独立组件构成的微内核架构。这些组件通过 gRPC 接口通信，并由事件系统串联异步操作。理解这张架构图是掌握控制面设计的第一步。

3.1 核心组件详解

containerd 的核心组件各自承担明确的职责，共同构成了容器生命周期的管理闭环。下表总结了各组件的定位与关键特性：

3.2 gRPC API 层：统一的控制面入口

containerd 的所有功能都通过 gRPC API 暴露。API 层是客户端与核心服务之间的契约，也是控制面设计的核心。API 定义在 github.com/containerd/containerd/api 中，主要服务包括：

• Namespace Service：管理命名空间，实现多租户隔离。
• Container Service：容器的 CRUD 操作（创建、查询、更新、删除）。
• Task Service：容器进程的生命周期管理（启动、停止、暂停、恢复、Exec）。
• Image Service：镜像的拉取、推送、列举、删除。
• Content Service：Blob 数据的上传、下载、列举。
• Snapshots Service：快照的创建、提交、挂载、回滚。
• Events Service：事件流的订阅。

一个典型的容器创建流程会依次调用多个 gRPC 服务：

// 伪代码：容器创建流程的 gRPC 调用链
1. client.Namespaces().Create(ctx, "my-ns")          // 创建命名空间
2. client.ImageService().Pull(ctx, "nginx:alpine")   // 拉取镜像（内部调用 Content Service）
3. client.SnapshotService().Prepare(ctx, key, parent) // 准备快照（挂载根文件系统）
4. client.ContainerService().Create(ctx, container)  // 创建容器元数据
5. client.TaskService().Create(ctx, task)            // 创建任务（启动 Shim 和容器进程）

3.3 事件系统：异步解耦的基石

containerd 的事件系统采用发布/订阅模式，用于在组件之间传递异步通知。事件系统是控制面实现可观测性和自动化运维的关键基础设施。

事件类型示例：

事件订阅示例（Go 客户端）：

// 订阅所有容器相关事件
filter := `topic=="/containers/*"`
eventsCh, errCh := client.EventService().Subscribe(ctx, filter)

for {
    select {
    case evt := <-eventsCh:
        // 处理事件，例如记录日志或触发回调
        log.Printf("Event: %s, Namespace: %s, ID: %s", evt.Topic, evt.Namespace, evt.ID)
    case err := <-errCh:
        // 处理错误或重连
        log.Fatalf("Event subscription error: %v", err)
    }
}

3.4 组件间通信与数据流

理解组件间的数据流是掌握 containerd 架构的关键。以“拉取镜像并启动容器”为例，数据流如下：

1. 客户端 通过 gRPC 调用 ImageService.Pull()。
2. gRPC API 层 将请求转发给 Content Store，后者从远程仓库下载 Blob 数据，并计算 Digest 验证完整性。
3. 下载完成后，Metadata Store 记录镜像的元数据（Manifest、Config、Layer 列表）。
4. 客户端调用 SnapshotService.Prepare()，Snapshotter 根据镜像层信息创建挂载点（例如 overlayfs 的 lowerdir 和 upperdir）。
5. 客户端调用 TaskService.Create()，Shim 进程被启动，Shim 根据 OCI Runtime Spec 调用 runc 创建容器进程。
6. 容器进程启动后，Event System 发布 /tasks/start 事件，通知所有订阅者。