2、容器运行时接口（CRI）原理

容器运行时接口（Container Runtime Interface，CRI）是 Kubernetes 控制面与容器运行时之间的核心协议边界。理解 CRI 的规范定义、通信机制以及 shim 层的设计，是诊断容器运行时治理控制面故障的基础。

2.1 CRI 规范：定义控制面与运行时的契约

CRI 是 Kubernetes 在 v1.5 引入的插件化接口协议，它定义了 kubelet 与容器运行时之间的 gRPC 通信契约。CRI 规范的核心目标是将容器运行时的实现细节从 kubelet 中解耦，使得 Kubernetes 可以支持多种容器运行时（如 containerd、CRI-O、Docker Engine 通过 dockershim）。

CRI 规范主要包含两个 gRPC 服务：

服务名称 主要 RPC 方法 功能描述
RuntimeService RunPodSandbox、StopPodSandbox、CreateContainer、StartContainer、StopContainer、RemoveContainer、Status 管理 Pod 沙箱和容器的生命周期（创建、启动、停止、删除）
ImageService PullImage、ListImages、ImageStatus、RemoveImage 管理容器镜像的拉取、列表、状态查询和删除
故障排查要点： 当 kubelet 报错 failed to create container 或 failed to pull image 时，首先应检查 CRI 接口的 gRPC 调用是否超时或返回错误码。CRI 规范要求所有 RPC 方法必须返回明确的错误信息，这是定位运行时故障的第一线索。

2.2 kubelet 与运行时通过 CRI 通信的机制

kubelet 作为 Kubernetes 控制面在节点上的代理，通过 CRI 接口与容器运行时进行双向通信。通信机制基于 gRPC 协议，使用 Protocol Buffers 进行序列化，默认通过 Unix Socket 进行本地进程间通信。

通信流程如下：

  1. kubelet 发起 gRPC 调用：kubelet 根据 Pod 状态变化（如调度到节点、更新、删除），构造对应的 CRI 请求（如 RunPodSandboxRequest）。
  2. 序列化与传输：请求通过 Protocol Buffers 序列化为二进制数据，通过 Unix Socket（默认路径 /var/run/crio/crio.sock 或 /run/containerd/containerd.sock）发送。
  3. 运行时处理：容器运行时（如 containerd）的 CRI 插件接收请求，解析后调用底层运行时（如 runc）执行实际容器操作。
  4. 响应返回：运行时将操作结果（成功或错误）封装为 CRI 响应，通过同一 Socket 返回给 kubelet。
关键配置参数：
  • --container-runtime-endpoint：指定 CRI 运行时 Socket 路径（如 unix:///var/run/containerd/containerd.sock）。
  • --image-service-endpoint：指定镜像服务 Socket 路径（可与运行时相同）。
  • --container-runtime：在 v1.24+ 中已废弃，默认使用 remote 模式。

以下 SVG 展示了 kubelet 通过 CRI 与容器运行时通信的完整架构：

kubelet 与容器运行时 CRI 通信架构 kubelet 控制面节点代理 Pod 生命周期管理 gRPC 协议 Protocol Buffers Unix Socket 本地 IPC 通信 CRI Shim containerd / CRI-O CRI 接口实现层 runc / kata OCI 运行时 通信机制关键点： 1. kubelet 通过 gRPC 客户端调用 CRI 接口，所有请求/响应均序列化为二进制 Protobuf 消息。 2. Unix Socket 通信避免了网络开销，但 Socket 文件权限或路径错误是常见故障原因。 3. CRI Shim 负责将 CRI 请求转换为 OCI 运行时调用，是故障隔离的关键边界。 4. 超时设置（默认 4 分钟）和重试机制影响控制面响应速度。

2.3 CRI Shim 的作用

CRI Shim 是连接 kubelet 与底层容器运行时的中间层，它实现了 CRI 规范定义的 gRPC 服务，并将 CRI 请求转换为特定运行时的操作。Shim 层的存在使得 Kubernetes 无需直接依赖任何特定容器运行时的实现细节。

CRI Shim 的核心职责包括：

  • 协议转换：将 CRI 的 Pod 和容器抽象映射为 OCI（Open Container Initiative）运行时规范。
  • 生命周期管理：管理 Pod 沙箱（Sandbox）和容器的创建、启动、停止、删除。
  • 镜像管理：处理镜像拉取、缓存、挂载和垃圾回收。
  • 监控与统计：提供容器资源使用统计（CPU、内存、网络）和日志流式传输。
  • 故障隔离：当底层运行时崩溃时，Shim 可以保持 kubelet 的稳定性，避免级联故障。
CRI Shim 实现 底层运行时 特点 常见故障场景
containerd runc (默认)、kata、gVisor 轻量、内置 CRI 插件、社区主流 Socket 文件丢失、镜像拉取超时、runc 状态不一致
CRI-O runc、kata 专为 Kubernetes 优化、最小依赖 conmon 进程泄漏、pause 镜像拉取失败
dockershim（已弃用） Docker Engine → runc v1.24 移除、历史兼容 Docker 守护进程重启导致 Pod 重建
故障排查警示： CRI Shim 是控制面故障的高发区域。常见问题包括：
  • Shim 进程崩溃导致 kubelet 无法创建新 Pod，但已有 Pod 继续运行。
  • Shim 与 kubelet 之间的 gRPC 连接超时，通常由 Socket 文件权限错误或磁盘 I/O 阻塞引起。
  • Shim 内部状态与底层运行时状态不一致，导致 ContainerStatus 返回错误信息。
排查时应首先检查 crictl info 和 crictl ps -a 的输出，确认 Shim 是否响应正常。

以下 SVG 展示了 CRI Shim 在 kubelet 与 OCI 运行时之间的桥梁作用：

CRI Shim 桥梁作用与协议转换 kubelet CRI 客户端 CRI Shim 协议转换层 CRI → OCI 转换 OCI 运行时 runc / kata CRI 协议 OCI 规范 CRI Shim 核心功能： 1. 协议转换：将 CRI 的 PodSandbox/Container 抽象映射为 OCI 的 Bundle 和容器进程。 2. 状态管理：维护 Pod 和容器的状态机，处理创建、运行、停止、删除等状态转换。 3. 资源隔离：通过 Linux Namespace 和 Cgroups 实现 Pod 级别的资源隔离。 4. 故障恢复：当底层运行时进程退出时，Shim 负责清理资源并通知 kubelet。

2.4 故障排查关键路径

当控制面出现容器运行时相关故障时，以下排查路径可以帮助快速定位问题根因：

  1. 检查 CRI Socket 连通性：使用 crictl info 或 crictl version 验证 kubelet 能否与 CRI Shim 通信。
  2. 查看 kubelet 日志：搜索 failed to connect to CRI、failed to create pod sandbox 等关键字。
  3. 检查 Shim 进程状态：使用 systemctl status containerd 或 crio status 确认 Shim 是否运行。
  4. 验证 OCI 运行时：使用 runc list 或 crictl ps -a 查看容器实际状态。
  5. 检查镜像缓存：使用 crictl images 确认所需镜像是否存在。
快速诊断命令： 
# 检查 CRI 接口是否响应
crictl version

# 查看所有容器状态（包括已退出）
crictl ps -a

# 查看 Pod 沙箱状态
crictl pods

# 检查镜像列表
crictl images

# 查看 containerd 状态
systemctl status containerd

# 查看 kubelet 日志中的 CRI 错误
journalctl -u kubelet --no-pager | grep -i "cri\|runtime\|sandbox"
← 上一章 📖 返回目录 下一章 →