Linux CRI-O 的轻量级设计与 Kubernetes 集成性能对比

cri-o 启动 pod 略慢于 containerd，主因是在 sandbox 创建阶段强制校验 oci 配置（如 seccomp/capabilities），而 containerd 推迟至容器启动时；生产中该差异可忽略，调度、镜像拉取、cni 才是瓶颈。

为什么 CRI-O 启动 Pod 比 containerd 慢一点？

CRI-O 不是“更快”的 runtime，它的设计目标不是压测吞吐，而是最小化攻击面和 kubernetes 原生语义对齐。启动延迟略高，主要来自它在 pod-sandbox 创建阶段做了更严格的 OCI 运行时校验（比如强制检查 config.json 中的 linux.seccomp 和 capabilities 字段合法性），而 containerd 会把部分校验推迟到容器实际 start 时。

• 如果你用 crictl runp 测试单个 sandbox，CRI-O 平均多耗 30–80ms，尤其在启用 seccomp 或 apparmor 策略时更明显
• 生产中这个差异几乎不可感——Kubernetes 调度、镜像拉取、CNI 配置才是瓶颈，别为这几十毫秒换 runtime
• 想压测真实性能？必须用 kubectl create -f 批量起 50+ Pod，并关闭 imagePullPolicy: Always，否则网络和 registry 成为主因

CRI-O 的 pause 镜像到底要不要手动配置？

要，而且必须匹配 kubelet 的 --pod-infra-container-image。CRI-O 不像 containerd 那样能自动 fallback 到内置默认值；它完全依赖配置项 pause_image（位于 /etc/crio/crio.conf 的 [crio.image] 小节）。

• 常见错误：升级 Kubernetes 后没同步更新 pause_image，导致 Pod 卡在 ContainerCreating，crictl pods 显示状态为 NotReady，crictl logs 查不到日志——因为 infra 容器根本没起来
• 正确做法：从对应 k8s 版本的 kubernetes/release images 找匹配的 pause 镜像，例如 v1.28 → k8s.gcr.io/pause:3.6
• 注意镜像仓库镜像：如果用国内环境，得把 pause_image 改成 registry.aliyuncs.com/google_containers/pause:3.6，且确保该镜像已 podman pull 过，CRI-O 不会自动拉取 infra 镜像

为什么 crictl exec 进不去容器却没报错？

因为 CRI-O 默认禁用 exec 的 TTY 分配和 stdin 绑定，除非容器 manifest 显式声明了 stdin: true 和 tty: true。这不是 bug，是它对 OCI spec 的严格实现——containerd 会悄悄补全这些字段，CRI-O 不会。

• 现象：crictl exec -it <cid> sh</cid> 返回空提示、光标卡住，但 exit code 是 0
• 验证方法：crictl inspect <cid></cid> 查 spec.process.stdin 和 spec.process.terminal 字段，若为 false 就必然失败
• 修复方式：改 Deployment 的 stdin: true 和 tty: true（在 containers[] 下），或临时用 crictl exec -i -t 强制开启（仅当 runtime 允许时才生效，CRI-O 1.26+ 支持）

CRI-O 的 cgroup v2 支持有哪些硬限制？

它只支持 unified cgroup hierarchy（即纯 v2），不支持 hybrid 模式。一旦系统启用了 cgroup v2，CRI-O 就要求所有组件（kubelet、runc、内核）都走 v2 路径，否则直接拒绝启动。

• 典型报错：failed to create container: cgroups: cgroup mountpoint does not exist: /sys/fs/cgroup —— 实际是 /sys/fs/cgroup 下没有 cgroup.controllers 文件，说明内核没真正启用 v2
• 检查命令：stat -fc %T /sys/fs/cgroup 输出必须是 cgroup2fs；cat /proc/1/cgroup 第一行应为 0::/
• 坑点：某些发行版（如 RHEL 8.8+）默认启用 hybrid，需在 grub 中加 systemd.unified_cgroup_hierarchy=1 并重装 initramfs，否则 CRI-O 服务起不来

事情说清了就结束。CRI-O 的“轻量”不在二进制大小，而在它不做多余的事——不兼容旧字段、不自动补配置、不兜底失败路径。用它就得接受这种克制。