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 服务起不来
