CRI-O 1.37 介绍与选型指南

基于官方资料溯源的 CRI-O 1.37 Kubernetes 轻量运行时介绍与选型指南，覆盖架构分层、组件与安全机制、快速上手、适用限制及与 runc、crun、gVisor 的运行时对比。

CRI-OCRI-O运行时Kubernetes2026/10/18

CRI-O 1.37 介绍与选型指南

一、信息基准

本文为 CRI-O 认知篇，全部信息基于官方资料溯源编写，不涉及任何本地实测数据。查询日期为 2026-10-18。

项目内容
软件名称CRI-O
本文信息基准版本v1.37.2（2026-10-02 发布，GitHub Releases Feed 实查）
并行维护版本线v1.36.7、v1.35.10、v1.34.15（Releases Feed 中同期仍在发布补丁）
开源许可Apache-2.0（官方仓库 LICENSE 文件实查）
社区归属CNCF 毕业项目（cri-o.io 官网首页明示 "Cloud Native Computing Foundation graduated project"）
实现语言Go
官网https://cri-o.io/
官方文档https://cri-o.io/doc.html 与 GitHub 仓库文档目录
源码仓库https://github.com/cri-o/cri-o
版本依据GitHub Releases Feed、官网、release-1.37 分支 README
GitHub stars官方未公布（本次溯源未获取到可验证的 star 统计）

二、软件概述

本文介绍的版本为 CRI-O v1.37，其最新修订版为 v1.37.2（2026-10-02 发布）。CRI-O 是专门面向 Kubernetes 的轻量级运行时实现：kubelet 通过 CRI（Kubernetes 运行时接口）与其通信，由它负责工作负载实例（Pod 沙箱与实例进程）的创建、运行与管理，底层再调用符合 OCI 标准的运行时（如 runc、crun）完成实际的沙箱隔离。

CRI-O 的版本号与 Kubernetes 保持一一对应关系：CRI-O 1.37 服务于 Kubernetes 1.37，官方 README 的兼容性说明进一步指出其支持 Kubernetes n-2 的版本偏差策略，即 v1.37 可服务于低两个 minor 版本内的集群。这使集群升级时的运行时选版非常直观——跟随 Kubernetes 版本即可。

社区归属上，CRI-O 由 Red Hat 发起，现为 CNCF 毕业项目，采用 Apache-2.0 许可。官方对其定位的描述是"专为 Kubernetes 而生的轻量运行时"：只实现 Kubernetes 需要的运行时能力子集，不带任何面向单机的额外功能面，这一取舍是它与通用运行时引擎（既可独立使用又可接入 K8s 的那类产品）最核心的差异。

三、核心架构

3.1 在 Kubernetes 技术栈中的位置

CRI-O 位于 kubelet 与 OCI 运行时之间：kubelet 发起 CRI 调用（gRPC，走其 UNIX 套接字，默认 /var/run/crio/crio.sock），CRI-O 完成沙箱与实例的生命周期编排，将隔离执行委托给 runc/crun。分层清晰是 CRI-O 架构的显著特点——每一层都可独立替换（如把底层 runc 换成 crun，或换成 Kata 系强隔离沙箱运行时）。

3.2 主要组件

  • crio 主守护进程：实现 CRI 服务，管理 Pod 沙箱与工作负载实例生命周期。
  • 拉取与存储层：负责按仓库地址与摘要拉取分层制品、维护本地分层存储与快照器（如 overlay），并对接只读副本仓库的认证配置。
  • 网络层：通过 CNI 插件体系为 Pod 沙箱配置网络（IP 分配、路由与端口能力）。
  • 资源隔离层：基于 cgroup v2 与 systemd 协同管理 CPU、内存等资源约束。
  • 安全层：支持 seccomp、AppArmor、SELinux、rootless 运行等安全机制，由 CRI 级别配置或注解指定。

3.3 与 kubelet 的协同

CRI-O 实现的是 CRI 中与运行时相关的子集（RuntimeService 与 ImageService 的职责范围），事件与状态（如实例退出码、探针结果）持续回传 kubelet，由 kubelet 做上层调度决策。CRI-O 自身不做调度、不维护集群状态，职责边界刻意收窄。

四、功能特性

  • 专一 K8s 场景：只实现 CRI 所需能力，安装面与攻击面小，资源开销低。
  • OCI 运行时可插拔：runc、crun 均为官方支持的后端，可按场景切换；强隔离需求可接入 Kata 系沙箱运行时。
  • 版本对齐：minor 版本与 Kubernetes 同步演进，官方支持 n-2 偏差，升级路径简单。
  • 分层制品管理：按仓库与摘要拉取、校验与存储分层制品，支持多种快照器与存储驱动；提供过期制品清理能力。
  • 根less 运行：官方支持以非 root 身份运行守护进程与工作负载（rootless 模式），配合用户命名空间增强隔离。
  • 安全策略内建：seccomp 配置档案管理、AppArmor/SELinux 标签、能力裁剪等安全机制原生集成。
  • systemd 集成：官方提供 systemd 单元，以托管方式运行守护进程并支持 resource-aware 排序。
  • 可观测：暴露 Prometheus 指标端点，支持 CRI 级别日志与事件。

五、快速上手

以下为官方文档（cri-o.io 及 GitHub 仓库 README）的最小流程摘要，本文不做本地实测：

  1. 安装：官方文档给出按操作系统选择软件源的安装方式（Debian 系与 RHEL 系均有官方仓库指引，安装包名 crio），详见 https://cri-o.io/doc.html 。
  2. 启动守护进程：以 systemd 托管启动：
sudo systemctl start crio
sudo systemctl enable crio
  1. 核验就绪：官方推荐用 crictl 检查运行时状态（crictl 默认连接 CRI-O 套接字）：
sudo crictl info
  1. 供 Kubernetes 使用：kubeadm 初始化或加入集群时指定 CRI-O 套接字：
sudo kubeadm init --cri-socket unix:///var/run/crio/crio.sock
  1. 日常运维：主配置文件（官方文档给出完整配置项说明，可用 crio config 生成默认配置模板）调整存储目录、网络插件与安全默认值。

来源链接：https://cri-o.io/doc.html （Quick Start 与安装）、https://github.com/cri-o/cri-o/blob/main/README.md （兼容性矩阵与 crictl 用法）。

六、适用场景与限制

6.1 适用场景

  • 以 Kubernetes 为唯一工作负载编排平台的集群：CRI-O 的能力面与 K8s 需求精确对齐，没有多余组件。
  • 对运行时资源占用与攻击面敏感的环境（边缘节点、大规模集群）：轻量化带来密度与安全收益。
  • 需要运行时可插拔的异构集群：同一集群内按节点选择 runc（通用）或 crun（更低开销）、Kata 系（强隔离）后端。
  • 偏好 Red Hat 系技术栈（RHEL/CentOS/Fedora + SELinux + systemd）的组织。

6.2 限制

  • 不用于单机场景：CRI-O 不提供独立于 K8s 的单机使用价值，单机需求应选 Podman 等工具。
  • 版本升级节奏与 Kubernetes 绑定：集群需保持运行时与 K8s 版本对齐（n-2 内），跨多版本升级需按官方路径逐级推进。
  • 功能面收窄：制品构建、单机管理等周边能力不在其定位内，需配套工具补齐。
  • 生态默认值：部分 K8s 发行版（K3s、minikube 等）默认内置另一款 CRI 运行时，选用 CRI-O 需在发行版配置中显式切换。

七、同类选型对比

在 Kubernetes 运行时语境下，同类可比对象为：runc 与 crun（OCI 运行时实现，即 CRI-O 的底层执行器）、gVisor（强隔离沙箱运行时）。三者与 CRI-O 是上下游或平级替换关系，对比数据来自各项目官方渠道，查询日期 2026-10-18。GitHub stars 官方未公布（本次溯源未获取到可验证统计），故不列该列。

维度CRI-O v1.37.2runc v1.5.2crun 1.30.1gVisor 20261012.0
定位K8s 专用 CRI 运行时（上层编排）OCI 运行时基准实现（底层执行器）OCI 运行时的 C 语言轻量实现用户态内核式强隔离沙箱运行时
开源许可Apache-2.0Apache-2.0GPLv2Apache-2.0
最新版本v1.37.2（2026-10-02）v1.5.2（v1.6.0-rc.1 为预发布标签）1.30.1（GitHub Releases）release-20261012.0（周度日期版本）
版本节奏随 K8s 季度 minor + patch低频稳定版 + rc 预发布月度级修订周度发布
与 CRI 关系原生实现 CRI，kubelet 直连不实现 CRI，由上层运行时调用不实现 CRI，由上层运行时调用以 runsc 形式作为 OCI 运行时被上层调用
依赖语言/内核GoGoCGo（用户态内核拦截系统调用）
典型搭配kubelet + CRI-O + runc/crun各类上层运行时（含 CRI-O）的默认执行器作为 CRI-O/Podman 的可选执行器敏感工作负载的沙箱后端
隔离模型依赖底层执行器 + 安全策略命名空间与控制组标准隔离命名空间与控制组标准隔离拦截式用户态内核，更强隔离、有性能税

注：表格中 CRI-O 与 runc/crun 为分层关系——生产集群通常三者共存（CRI-O 编排 + runc 或 crun 执行）；对隔离等级有特殊要求的节点可将执行器替换为 gVisor。

选型建议一句话：Kubernetes 集群要一套只做运行时本职、轻量且与 K8s 版本严格对齐的选择，CRI-O 是稳健答案（底层执行器默认 runc、追求更低开销换 crun）；若以兼容性与工具链成熟为先，则发行版默认内置的 CRI 运行时同样可靠；强隔离敏感负载再叠加 gVisor/Kata 系沙箱后端。

八、参考链接

  1. CRI-O 官网：https://cri-o.io/
  2. 官方文档入口：https://cri-o.io/doc.html
  3. GitHub 仓库与 README（兼容性矩阵）：https://github.com/cri-o/cri-o
  4. Releases（版本依据）：https://github.com/cri-o/cri-o/releases
  5. CNCF 项目页（毕业状态）：https://www.cncf.io/projects/cri-o/
  6. runc 官方项目（对比数据来源：GitHub runc 项目主页与 Releases）
  7. crun 官方项目（对比数据来源：GitHub crun 项目主页与 Releases）
  8. gVisor 官方仓库（对比数据来源）：https://github.com/google/gvisor
  9. Kubernetes 官方文档（CRI 概念）：https://kubernetes.io/docs/concepts/architecture/cri/