2. Containerd 架构基础：核心组件、gRPC 接口与插件机制

Containerd 并非一个简单的二进制文件，而是一个由多个守护进程、gRPC 接口和可插拔模块构成的工业级容器运行时。理解其分层架构是进行参数动态注入与流水线集成的理论前提。本章将拆解其核心组件、通信协议与扩展机制。

2.1 核心组件分层

Containerd 采用 C/S（客户端/服务端） 架构，主要分为三层：客户端层（CLI/API）、核心守护进程层（containerd） 和 底层执行层（shim/runc）。各层职责清晰，通过 gRPC 或 Unix Socket 通信。

2.2 gRPC 接口体系

Containerd 内部通信全面基于 gRPC，使用 Protocol Buffers 定义服务接口。主要分为两大类：面向用户的通用 API 和 面向 Kubernetes 的 CRI API。

2.2.1 通用 gRPC 服务

通用 API 定义在 github.com/containerd/containerd/api/services 目录下，核心服务包括：

• Namespace Service：管理容器命名空间隔离。
• Image Service：镜像拉取、推送、删除、列表。
• Container Service：容器创建、更新、删除、查询。
• Task Service：容器进程启动、停止、暂停、恢复、获取状态。
• Snapshot Service：管理文件系统快照（OverlayFS 层）。
• Content Service：管理 Blob 内容存储（镜像层数据）。
• Lease Service：资源租约管理，防止 GC 回收正在使用的资源。

2.2.2 CRI（Container Runtime Interface）

Kubelet 通过 CRI 插件与 Containerd 交互。Containerd 内置了 cri 插件，将 CRI 请求转换为内部 gRPC 调用。核心接口包括：

2.3 插件机制与扩展点

Containerd 采用 插件（Plugin） 架构，几乎所有核心功能都以插件形式注册到主进程中。插件通过 containerd 配置文件（/etc/containerd/config.toml）进行启用、禁用或参数配置。

2.3.1 内置插件类型

2.3.2 插件注册与配置示例

插件在启动时通过 config.toml 加载。以下是一个典型的插件配置片段，用于启用 CRI 并指定 pause 镜像：

version = 2
[plugins]
  [plugins."io.containerd.grpc.v1.cri"]
    sandbox_image = "registry.k8s.io/pause:3.9"
    [plugins."io.containerd.grpc.v1.cri".containerd]
      default_runtime_name = "runc"
      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
        runtime_type = "io.containerd.runc.v2"

2.4 架构设计对参数注入的影响

理解上述架构后，可以总结出参数动态注入的几个关键约束与机会：

• gRPC 是唯一入口：所有参数必须通过 gRPC 请求的 CreateContainerRequest 或 UpdateContainerRequest 传递，无法绕过。
• 插件隔离性：不同插件（如 CRI 与通用 API）处理参数的方式略有差异，CRI 插件会额外处理 Pod 级别的安全上下文。
• Shim 持久化：参数一旦通过 shim 传递给 runc，便写入容器配置（config.json），后续修改需通过 UpdateTask 接口或重建容器。
• Snapshotter 无关性：参数注入通常不涉及快照层，除非需要动态修改根文件系统挂载选项。