3. CRI（Container Runtime Interface）概述：CRI的诞生背景、接口定义与主流实现

3.1 CRI 的诞生背景：从“紧耦合”到“标准化”

在 Kubernetes 早期版本（v1.5 之前），kubelet 与容器运行时的交互是硬编码的。kubelet 内部直接通过 Docker API 调用 Docker Engine 来创建、启动、删除容器。这种架构存在三个核心痛点：

• 供应商锁定：Kubernetes 与 Docker 深度绑定，无法接入其他容器运行时（如 rkt、Hyper.sh、Kata Containers）。
• 版本耦合：kubelet 必须跟随 Docker API 的版本升级而修改代码，维护成本极高。
• 社区分裂风险：每个运行时都想成为 Kubernetes 的“一等公民”，但缺乏统一的接入标准。

为了解决上述问题，Kubernetes 社区在 2016 年提出了 CRI（Container Runtime Interface），作为 kubelet 与容器运行时之间的中间层抽象。CRI 使用 Protocol Buffers（protobuf） 定义 gRPC 服务，将容器生命周期管理、镜像管理、Pod 沙箱管理等操作标准化。从此，任何实现了 CRI 接口的运行时都可以无缝接入 Kubernetes。

3.2 CRI 接口定义：RuntimeService 与 ImageService

CRI 将容器运行时管理拆分为两个独立的 gRPC 服务：

以下是一个典型的 RunPodSandboxRequest 消息结构示例：

message RunPodSandboxRequest {
  // Pod 沙箱的唯一标识
  string pod_sandbox_id = 1;
  // 沙箱配置，包含 Pod 名称、UID、命名空间、DNS 等
  PodSandboxConfig config = 2;
  // 运行时特定的扩展配置
  RuntimeConfig runtime_config = 3;
}

message PodSandboxConfig {
  string name = 1;
  string uid = 2;
  string namespace = 3;
  // 主机名、DNS 配置、端口映射、标签、注解等
  DNSConfig dns_config = 4;
  repeated PortMapping port_mappings = 5;
  map<string, string> labels = 6;
  map<string, string> annotations = 7;
  LinuxPodSandboxConfig linux = 8;
}

3.3 主流 CRI 实现对比

目前社区主流的 CRI 实现有三个：containerd、CRI-O 和 Docker（通过 Dockershim）。Dockershim 已在 Kubernetes v1.24 中被移除，但仍有大量存量集群在使用。

3.4 如何选择 CRI 实现？

在选择 CRI 实现时，建议从以下维度评估：

• Kubernetes 版本兼容性：v1.24+ 推荐 containerd，OpenShift 推荐 CRI-O。
• 运维复杂度：containerd 和 CRI-O 都比 Docker 轻量，无需管理 Docker daemon。
• 生态集成：如果需要与 Docker Compose、Docker Swarm 等工具共存，Docker 仍有优势（但需注意 K8s 已弃用）。
• 性能与资源：containerd 和 CRI-O 在启动延迟、内存占用上优于 Docker。