1. CRI 接口概述

容器运行时接口（Container Runtime Interface，CRI）是 Kubernetes 与容器运行时之间的核心抽象层。它定义了 kubelet 如何与容器运行时通信，以管理 Pod 及其容器的完整生命周期。CRI 的引入将容器运行时从 kubelet 内部解耦，使得 Kubernetes 能够支持多种容器运行时（如 containerd、CRI-O、Docker Engine 通过 dockershim 桥接）而无需修改核心代码。

1.1 CRI 的定义与设计目标

CRI 是一组基于 Protocol Buffers（protobuf）定义的 gRPC 服务接口，包含两个主要服务：RuntimeService 和 ImageService。RuntimeService 负责 Pod 和容器的生命周期管理（创建、启动、停止、删除），ImageService 负责容器镜像的拉取、列表和删除操作。

CRI 的设计目标可归纳为以下五点：

• 解耦性：将容器运行时实现与 kubelet 核心逻辑分离，允许独立演进和替换。
• 标准化：提供统一的接口契约，消除不同运行时之间的 API 差异。
• 可扩展性：通过 protobuf 定义，支持向后兼容的字段扩展。
• 性能可预测：基于 gRPC/HTTP2 的流式传输，减少连接开销，支持双向流操作（如 exec）。
• 安全隔离：Pod 沙箱（PodSandbox）作为资源隔离的最小单元，与容器运行时自身的安全模型对齐。

1.2 CRI 在 Kubernetes 架构中的位置与作用

在 Kubernetes 节点架构中，CRI 位于 kubelet 与容器运行时之间，是控制面数据流的关键桥梁。下图展示了 CRI 在节点组件中的位置及其与上下层模块的关系。

1.3 CRI 的核心作用

CRI 在 Kubernetes 节点控制面中承担以下四个核心作用：

1. 生命周期管理标准化：kubelet 通过统一的 RunPodSandbox / CreateContainer 等调用，无需关心底层运行时如何实现容器创建、网络命名空间初始化、存储挂载等操作。
2. 流式通信支持：CRI 的 Exec、Attach、PortForward 方法基于 gRPC 双向流，支持实时交互式操作（如 kubectl exec），避免了传统 HTTP 轮询的开销。
3. 镜像管理解耦：ImageService 将镜像拉取、缓存、垃圾回收等职责从 kubelet 下沉到运行时，kubelet 只需调用 PullImage 并等待结果。
4. 插件化运行时生态：任何实现了 CRI 接口的容器运行时都可以无缝接入 Kubernetes，催生了 containerd、CRI-O、Kata Containers、gVisor 等多样化运行时生态。

1.4 CRI 接口的版本演进与兼容性

CRI 接口自 Kubernetes 1.5 引入以来，经历了多个版本的迭代。下表总结了关键版本节点及其变更要点：

CRI 的版本兼容性遵循 Kubernetes 的 GA 级 API 兼容性承诺：一旦进入 v1 稳定版，后续版本必须保持向后兼容，不得移除或破坏已有字段。这一设计保障了容器运行时实现者可以安全地升级 Kubernetes 版本而无需频繁修改 CRI 适配层。