2. 容器运行时分类：基于CRI的运行时与基于传统Docker的运行时的对比与演进

容器运行时是容器生命周期管理的核心执行者。随着Kubernetes成为容器编排的事实标准，容器运行时接口（CRI）的引入彻底改变了运行时的接入方式。本节将系统对比基于CRI的运行时（containerd、CRI-O）与基于传统Docker的运行时的架构差异、通信机制及演进路径。

2.1 运行时分类全景

从Kubernetes集成视角，容器运行时可分为两大类：

• 基于CRI的运行时：原生实现CRI接口，直接与kubelet通信，如containerd、CRI-O。
• 基于传统Docker的运行时：通过Docker Engine + dockershim适配层间接接入Kubernetes，如Docker + dockershim（已弃用）。

2.2 架构对比：控制面通信路径

下图展示了两种运行时在Kubernetes控制面中的通信路径差异：

2.3 关键对比维度

2.4 演进路径：从Docker到CRI原生运行时

容器运行时在Kubernetes生态中的演进经历了三个阶段：

1. 阶段一（v1.0–v1.23）：Docker独占期。kubelet通过硬编码的dockershim与Docker Engine通信，Docker成为唯一官方支持的运行时。
2. 阶段二（v1.5–v1.24）：CRI引入与并行期。Kubernetes v1.5引入CRI标准，containerd和CRI-O开始发展，dockershim作为兼容层继续存在。
3. 阶段三（v1.24+）：CRI原生期。dockershim被正式移除，所有运行时必须通过CRI接口接入，containerd成为默认运行时。

2.5 通信机制深度对比

基于CRI的运行时与基于Docker的运行时在通信机制上存在本质差异：

• 协议栈：CRI运行时使用gRPC/Protobuf二进制协议，Docker使用RESTful JSON/HTTP协议。gRPC的序列化效率比JSON高3–5倍。
• 连接模型：CRI运行时采用长连接gRPC流，Docker采用短连接HTTP请求。长连接减少了TCP握手开销。
• 错误处理：CRI定义了标准化的gRPC错误码（如NotFound、AlreadyExists），Docker返回HTTP状态码+JSON错误体，解析复杂度更高。

// CRI gRPC 接口示例（PodSandboxManager）
service RuntimeService {
  // 创建Pod沙箱
  rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandboxResponse);
  // 停止Pod沙箱
  rpc StopPodSandbox(StopPodSandboxRequest) returns (StopPodSandboxResponse);
  // 移除Pod沙箱
  rpc RemovePodSandbox(RemovePodSandboxRequest) returns (RemovePodSandboxResponse);
  // 创建容器
  rpc CreateContainer(CreateContainerRequest) returns (CreateContainerResponse);
  // 启动容器
  rpc StartContainer(StartContainerRequest) returns (StartContainerResponse);
}

2.6 性能指标对比

2.7 选型建议

根据生产环境需求，推荐以下选型策略：

• 通用场景：containerd是默认首选，社区支持最广，性能均衡，与Kubernetes集成最成熟。
• Red Hat/OpenShift生态：CRI-O是Red Hat主导的运行时，与OpenShift深度集成，在安全合规场景有优势。
• 边缘计算/资源受限：containerd的轻量特性（28MB内存占用）更适合边缘节点。
• 安全敏感场景：CRI-O支持直接集成kata-containers等安全容器，无需额外适配层。