runc 是唯一能直接执行 OCI 容器包的运行时，OCI 规范仅定义 runtime、image 和 distribution 三类规范，不涉及构建、网络等上层功能；containerd 仅为调用 runc 的调度中转层，其本身不处理内核隔离。
runc 是唯一能直接执行 OCI 容器包的运行时，其他如 containerd、CRI-O 都是封装层，不处理内核级隔离——想真正理解容器，必须亲手用 runc 跑一个 bundle，否则永远停留在“调 API”层面。
OCI 规范到底管什么？别被“标准”二字唬住
OCI 实际只定义三件事：runtime-spec（怎么跑容器）、image-spec（镜像怎么存）、distribution-spec（怎么推拉镜像）。它不管镜像构建、网络插件、存储卷挂载——这些全是上层 runtime（比如 containerd）自己加的。很多人以为 “符合 OCI” 就等于“能跑 Docker 镜像”，其实不是：OCI 运行时只认解压后的 bundle（一个 config.json + 一个 rootfs 目录），不认 nginx:latest 这种标签。
-
runc spec生成的是最小可行 config，但默认 rootfs 是空的，直接runc run必报no such file or directory: unknown - 镜像解包必须用
umoci unpack或skopeo copy --dest-dir，不能用tar -xzf硬解——layer 合并逻辑、白名单文件、.wh. 文件处理全在工具里 -
config.json中的linux.namespaces和linux.resources是硬绑定 Linux 内核能力的，换到 Windows 或 macOS 上runc直接拒绝启动
为什么 containerd 不是“容器运行时”？它只是个调度中转站
containerd 本身不创建 namespace、不设置 cgroup、不 clone() 进程——它只做三件事：监听 gRPC 请求、校验 bundle 合法性、调用 runc 的二进制。Kubernetes 的 CRI 接口之所以能对接多种 runtime，靠的就是这个设计：把 containerd 当成“通用胶水”，底层换 crun 或 kata-runtime 只需改一个配置项 containerd.toml 里的 default_runtime_name。
- 查当前 runtime：运行
containerd config dump | grep runtime，看到的io.containerd.runc.v2就是实际干活的runc插件名 - 强制指定 low-level runtime：在
config.toml中写[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]，再设runtime_type = "io.containerd.runc.v2" - 误以为删掉
runc二进制还能跑容器？错。containerd启动时会检查所有 configured runtime 的二进制是否存在，缺一个就 panic 报错
runc spec 生成的 config.json 到底该怎么改？
刚跑 runc spec 得到的 config 是“能启动但没用”——它默认运行 /bin/sh，rootfs 为空，没挂载任何设备。真实场景下至少要改三处：
- 修改
process.args：把["/bin/sh"]换成["/bin/bash", "-c", "echo hello && sleep 3600"]，否则容器秒退 - 补全
root.path：确保路径存在且可读，比如"root": {"path": "./rootfs"}，然后手动mkdir -p ./rootfs - 加必要 mount：至少保留
/proc、/sys、/dev的 bind mount，否则ps、free全失效；runc spec --rootless会自动禁用部分 mount，适合非 root 用户调试
改完记得验证：runc checkconfig config.json，它会告诉你哪些内核特性缺失（比如没开 CONFIG_USER_NS 就跑不了 user namespace）。
OCI 规范最反直觉的一点：它不保证“跨平台兼容”，只保证“跨实现兼容”。同一个 config.json 在 runc 和 crun 下行为一致，但在 kata-runtime 下可能启动一个轻量 VM——这恰恰是规范允许的。别指望一份 bundle 到哪都能跑，先看 runtime 类型再说。
