crun 1.30 介绍与选型指南

crun 1.30 介绍与选型指南：官方资料溯源的 C 语言轻量 OCI 运行时定位、libcrun 与 shim 集成架构、性能与 krun/CRIU 特性、源码构建快速上手与适用限制，以及与 runc、youki、Kata Containers 的量化选型对比（2026-10-19 实查，未做本地安装实测）。

cruncrun运行时运维2026/10/19

crun 1.30 介绍与选型指南

目标：基于官方公开资料（containers/crun 官方仓库 README 与 Releases 发行页）梳理 crun 的定位、架构、功能与选型口径，并与 runc、youki、Kata Containers 做量化对比。本文仅做官方资料溯源，不做本地安装与运行实测；全部版本号、日期与社区数据于 2026-10-19 联网实查。

一、信息基准

1.1 查询说明

  • 查询日期：2026-10-19。
  • 信息获取方式：纯官方资料溯源（github.com/containers/crun 官方仓库 README、Releases 页与 Atom 时间线、shields.io 社区数据徽章），本文不做本地安装与运行实测。
  • 版本结论：当前最新稳定版为 1.30.1（2026-09-25 发布，对 CVE-2026-84042 的补全修复），1.30 于 2026-09-24 发布。1.x 线按月度级节奏推进。

1.2 版本依据

项目实查结果（2026-10-19）来源
最新补丁1.30.1（2026-09-25）github.com/containers/crun/releases
系列时间线1.30（2026-09-24）、1.29.1（2026-08-13）、1.29（2026-08-07）、1.28（2026-05-27）、1.27.1（2026-04-21）、1.27（2026-03-25）同上 Releases/Atom
安全修复1.30 修复 CVE-2026-84042、CVE-2026-88264、CVE-2026-88265 等1.30/1.30.1 发行说明
代码仓库containers/crungithub.com/containers/crun
开源许可GPL-2.0（仓库 COPYING 口径）仓库 COPYING
GitHub stars约 4.2k（shields.io 徽章实查）shields.io（2026-10-19）

1.3 官方来源清单

来源地址
源码仓库https://github.com/containers/crun
发行页https://github.com/containers/crun/releases
用户文档（man）https://github.com/containers/crun/blob/main/crun.1.md
上游规范https://github.com/opencontainers/runtime-spec

二、软件概述

本文介绍的是 crun 1.30（开源版，最新补丁 1.30.1，2026-09-25 发布）。

crun 是一个「快速、低内存占用、完全用 C 编写」的 OCI 容器运行时（官方 README 定位），符合 OCI Container Runtime Specification。它处于容器栈的最底层：Podman、CRI-O 等上层工具在创建容器时把根文件系统与进程规格（config.json）交给 crun，由它完成命名空间、cgroup、Capabilities 等内核级设置并拉起容器进程。项目由 Giuseppe Scrivano（Red Hat）主导、containers 社区维护，是 Podman 与 CRI-O 的默认执行器之一。

GitHub stars 约 4.2k（2026-10-19 实查）。它的价值不在项目体量，而在「更低开销」：官方 README 给出的对比显示，顺序启动 100 个运行 /bin/true 的容器，crun 用时约为 runc 的一半（0:01.69 对 0:03.34，-49.4%，作者实测口径）。

三、核心架构

以下要素转述自官方 README 与 man 文档（查询日期 2026-10-19）。

3.1 OCI 执行器定位

  • 输入：OCI bundle（rootfs + config.json，可用 crun spec 生成），描述进程参数、挂载表、namespaces、cgroup 资源限制、seccomp、capabilities 等；
  • 行为：crun run/create/start/delete/list/state 等子命令完成容器生命周期管理；无长驻守护进程，执行即退出；
  • 上游规范：严格遵循 OCI runtime-spec，与 runc 在 bundle 层完全互换。

3.2 libcrun 库化设计

官方 README 强调 crun「也可作为库使用」：libcrun 可被程序直接链接调用，无需为每个容器管理动作拉起外部进程——这是它区别于 runc（Go 实现、启动时需重执行自身并调用 C 模块）的核心差异点，也是低内存占用与快速启动的来源。

3.3 运行时变体与集成

  • krun 模式：基于 libkrun 的轻量虚拟化运行（1.30 发行说明包含 krun 支持 passt 网络、TAP 后端网络等增强）；
  • CRIU 集成：支持容器 checkpoint/restore（1.30 修复 --network-lock 与恢复期信号转发等问题）；
  • 上层集成：作为 Podman/containers.conf 与 CRI-O 的可配置执行器（--runtime /usr/bin/crun）。

四、功能特性

4.1 核心特性

  • OCI runtime-spec 全量兼容（namespaces、cgroup v1/v2、seccomp、capabilities、masked/readonly paths）；
  • 低内存占用：官方 README 示例显示可在 512k 内存限制下运行容器（runc 在 4M 限制下即报错，作者实测口径）；
  • libcrun 库化嵌入、静态二进制构建（官方 nix 构建产出 glibc 静态 ELF）；
  • Lua 绑定、Python 绑定（构建可选）。

4.2 1.30 系列状态

1.30/1.30.1（2026-09-24/25）为安全修复集中版本：修复 rootful krun+passt 场景的载荷执行越界（CVE-2026-84042）、/dev/console 符号链接逃逸（CVE-2026-88264）、/dev/null 校验缺失（CVE-2026-88265），并包含 sysctl 键路径转换、OPEN_TREE_NAMESPACE 绑定挂载修复等（官方发行说明实查）。选型时应确保使用 1.30.1 或发行版内已含修复的版本。

4.3 与 runc 的互换性

同一 OCI bundle 可在 runc 与 crun 间直接切换，上层（Podman/CRI-O）通过配置即改；这使「默认 runc、热点路径换 crun」的渐进策略可行。

五、快速上手

以下步骤转述自官方 README（官方地址：https://github.com/containers/crun ，本文不做本地实测）。

5.1 源码构建

# Fedora 系依赖（Ubuntu/Alpine 等依赖清单见官方 README）
sudo dnf install -y autoconf automake gcc git-core glibc-static \
  go-md2man libcap-devel libseccomp-devel libtool make pkg-config \
  python python-libmount systemd-devel json-c-devel

./autogen.sh
./configure
make
sudo make install   # 默认安装到 /usr/local

官方 README 同时提供 nix 可复现静态构建（nix build "path:.#crun-static-amd64"）与社区 Ansible Role 安装路径；各主流发行版软件源亦直接提供 crun 包。

5.2 通过 Podman 使用

# 以 crun 作为执行器启动容器（官方 README 示例）
podman --runtime /usr/bin/crun run --rm --memory 512k fedora echo it works

生成与修改 OCI bundle 的字段级实操，本站已实测整理为 《crun 配置参数详解》，发行版安装步骤见 《Ubuntu 22.04 安装 crun 指南》。

六、适用场景与限制

6.1 适用场景

  • 高密度容器节点（Serverless、CI 弹性池）：启动速度与内存开销直接转化为密度与成本优势；
  • 资源受限的边缘设备与小规格主机；
  • 需要将 OCI 运行时嵌入自有程序（libcrun）的平台开发；
  • 需要容器 checkpoint/restore（CRIU）的迁移与快照场景。

6.2 限制与注意事项

  • 只解决「单个容器如何启动」，不含镜像管理、网络与编排，须与 Podman/CRI-O 等上层搭配；
  • 社区体量小于 runc，个别发行版默认仍为 runc，切换前需验证 cgroup 驱动与 selinux 策略组合；
  • 安全通告密集期（如 2026-09 三连 CVE）需及时跟进发行版内补丁；
  • krun/libkrun 虚拟化模式属较新特性，生产采用前应单独评估其内核与固件要求。

七、同类选型对比

7.1 候选概览

项目定位开源许可
crun 1.30.1C 实现的轻量 OCI 运行时GPL-2.0
runc v1.5.2Go 实现的 OCI 运行时基准实现Apache-2.0
youki v0.7.0Rust 实验型 OCI 运行时Apache-2.0
Kata Containers 4.2.0轻量虚拟机强隔离运行时Apache-2.0

7.2 量化对比（2026-10-19 实查）

维度crun 1.30.1runc v1.5.2youki v0.7.0Kata Containers 4.2.0
开源许可GPL-2.0Apache-2.0Apache-2.0（仓库 LICENSE）Apache-2.0
GitHub stars约 4.2k（containers/crun）约 13k（opencontainers/runc）约 7.6k（youki-dev/youki）约 9k（kata-containers/kata-containers）
最近发版1.30.1（2026-09-25）v1.5.2（2026-09-25；v1.6.0-rc.1 为预发布）v0.7.0（2026-07-25）4.2.0（2026-09-15）
版本节奏月度级修订稳定版低频 + rc 预发布0.x 实验线minor 季度级
实现语言CGoRustGo（agent）+ QEMU/CLH 虚拟化
隔离模型命名空间/cgroup 标准隔离命名空间/cgroup 标准隔离命名空间/cgroup 标准隔离每容器/每 Pod 轻量虚拟机（VM 边界）
兼容矩阵OCI runtime-spec；Podman/CRI-O 默认可选OCI runtime-spec；事实标准默认OCI runtime-spec（宣称兼容）以 OCI 运行时形式对接 containerd/CRI-O

（stars 与发版时间取自各项目 GitHub Releases/releases.atom 与 shields.io 实查，查询日期 2026-10-19；许可见各仓库 LICENSE/COPYING。runc 为同批交付文档，此处仅列对比数据不互链。）

7.3 选型建议

  • 追求默认兼容与最大生态兜底，用 runc——它是 OCI 语义的基准实现；
  • 高密度、低开销与库化集成诉求明确，换 crun：官方口径下启动耗时约为 runc 一半，且可静态编译、嵌入 libcrun；
  • Rust 技术栈团队想参与运行时共建，可关注 youki（仍是 0.x 实验线，生产采用需谨慎）；
  • 多租户/不可信负载需要 VM 级强隔离，选 Kata Containers（开销为「性能税」，与 crun/runc 是隔离等级而非同位替代关系）。Podman 与 CRI-O 用户可通过一行配置在 runc/crun 间切换，先在灰度节点实测再全量。

八、参考链接