1. CRI 基础概念

1.1 CRI 的定义

CRI(Container Runtime Interface,容器运行时接口) 是 Kubernetes 在 v1.5 版本引入的插件协议,用于解耦 kubelet 与底层容器运行时。CRI 定义了 kubelet 与容器运行时之间的 gRPC 接口规范,使任何实现了该接口的运行时都能无缝接入 Kubernetes 集群。

CRI 的核心是一个 protobuf 协议文件,包含两个主要 gRPC 服务:

  • RuntimeService:管理 Pod 和容器的生命周期(创建、启动、停止、删除)。
  • ImageService:管理容器镜像的拉取、列表、删除等操作。
关键定义:CRI 是 Kubernetes 与容器运行时之间的标准化抽象层,通过 gRPC 协议实现运行时无关的 Pod 和容器管理。

1.2 设计目标

CRI 的设计围绕以下 5 个核心目标 展开:

目标 说明 实现方式
解耦 将 kubelet 与具体运行时实现分离 通过 gRPC 接口定义,kubelet 不直接调用 Docker/containerd API
可插拔 支持多种运行时自由切换 任何实现 RuntimeService + ImageService 的运行时均可接入
标准化 统一 Pod 和容器的操作语义 定义 PodSandbox、Container 等抽象资源及其生命周期方法
轻量 最小化接口定义,避免过度抽象 仅包含必要的方法,运行时内部实现细节不暴露给 kubelet
向后兼容 保证接口版本演进时不影响已有运行时 采用 gRPC 版本号 + 兼容性设计,v1alpha2 → v1 平稳过渡

1.3 在 Kubernetes 架构中的位置与作用

CRI 位于 Kubernetes 集群的 每个 Node 节点 上,是 kubelet 与容器运行时之间的桥梁。下图展示了 CRI 在 Kubernetes 架构中的精确位置:

CRI 在 Kubernetes 架构中的位置 Control Plane API Server / Scheduler / Controller kubelet 节点代理 + Pod 生命周期管理 CRI (gRPC) RuntimeService + ImageService Container Runtime containerd / CRI-O / Docker 容器实例 Pod 内的业务容器 常见 CRI 实现 • containerd (v1.1+) • CRI-O • Docker (通过 cri-dockerd) • Kata Containers

1.4 CRI 的核心作用

CRI 在 Kubernetes 集群中承担以下 4 项关键作用:

  1. 运行时抽象:屏蔽不同容器运行时的 API 差异,kubelet 只需调用统一的 gRPC 接口。
  2. Pod 生命周期管理:通过 RunPodSandbox、CreateContainer、StartContainer 等方法管理 Pod 和容器的完整生命周期。
  3. 资源隔离与配额传递:将 Kubernetes 资源请求/限制(CPU、内存、PID)通过 CRI 参数传递给运行时,由运行时配置 cgroups 实现隔离。
  4. 可观测性接口:提供 ContainerStats、ListContainerStats 等方法,支持 kubelet 采集容器资源使用指标。
性能调优视角:CRI 是 kubelet 与运行时之间的唯一通信通道。接口调用的延迟、序列化开销、连接复用策略直接影响 Pod 启动速度和资源配额生效时间。后续章节将深入分析 CRI 调用的性能瓶颈与优化方法。

1.5 CRI 接口方法概览

下表列出了 CRI 中 RuntimeService 和 ImageService 的核心方法:

服务 方法 功能描述 性能敏感度
RuntimeService RunPodSandbox 创建 Pod 沙箱(网络、PID 命名空间等) ⭐⭐⭐⭐⭐
StopPodSandbox 停止并清理 Pod 沙箱 ⭐⭐⭐
CreateContainer 在 Pod 沙箱内创建容器 ⭐⭐⭐⭐⭐
StartContainer 启动已创建的容器 ⭐⭐⭐⭐
ContainerStats 获取容器资源使用统计 ⭐⭐
ImageService PullImage 拉取容器镜像 ⭐⭐⭐⭐⭐
ListImages 列出节点上已拉取的镜像 ⭐
RemoveImage 删除指定镜像 ⭐⭐
注意:CRI 接口的性能敏感度与 Pod 启动频率、镜像拉取并发度、资源配额变更频率直接相关。在大规模集群或高密度部署场景下,RunPodSandbox 和 CreateContainer 的延迟优化是性能调优的首要目标。

1.6 CRI 与资源配额的关系

CRI 是 Kubernetes 资源配额从 API 层传递到操作系统层 的关键通道。资源配额的传递链路如下:

  1. 用户定义:在 Pod Spec 中设置 resources.requests 和 resources.limits。
  2. kubelet 解析:kubelet 将资源配额转换为 CRI 的 LinuxContainerResources 结构体。
  3. CRI 传递:通过 CreateContainer 或 UpdateContainerResources 接口发送给运行时。
  4. 运行时配置:运行时调用 cgroups 接口设置 CPU 份额、内存限制、PID 限制等。
资源配额传递链路(CRI 作为桥梁) Pod Spec resources.requests/limits kubelet 转换为 CRI 参数 CRI 接口 LinuxContainerResources Runtime + cgroups CPU / 内存 / PID 限制 CRI 是资源配额从声明到生效的必经桥梁

理解 CRI 的基础概念是后续进行 性能调优 和 资源配额配置 的前提。CRI 的接口设计、调用链路、参数传递方式直接决定了 Pod 启动速度、资源隔离精度和集群整体性能表现。