Python containerd vs cri-o 的容器运行时选型

选containerd还是cri-o取决于kubernetes发行版、维护节奏及oci运行时控制需求：containerd通用灵活，cri-o轻量专一，二者在socket路径、多运行时支持、镜像配置、存储驱动、日志抽象和升级兼容性上差异显著。

containerd 和 CRI-O 都是符合 CRI 的运行时，但默认行为和集成路径差异很大

选 containerd 还是 CRI-O，不取决于“谁更先进”，而取决于你用的 Kubernetes 发行版、发行版维护节奏、以及是否需要细粒度控制 OCI 运行时行为。containerd 是通用型运行时，CRI-O 是专为 Kubernetes 设计的轻量级运行时——前者像瑞士军刀，后者像手术刀。

常见错误现象：Failed to create pod sandbox 或 failed to get runtime version，往往不是配置错，而是 kubelet 没对齐 CRI socket 路径或版本协议（比如 CRI-O 1.28 默认用 v1alpha3 CRI，而旧 kubelet 只认 v1）。

• containerd 默认监听 /run/containerd/containerd.sock；CRI-O 默认监听 /var/run/crio/crio.sock，kubelet 的 --container-runtime-endpoint 必须严格匹配
• CRI-O 强制绑定 runc（可换，但需手动编译），containerd 默认用 runc，但可通过 default_runtime 和 runtime_handlers 支持 crun、kata-containers 等多运行时
• 如果你用 RHEL/centos Stream + openshift，CRI-O 是默认且受红帽全栈支持的；用 vanilla kubeadm 或 EKS Bottlerocket，containerd 是事实标准

镜像拉取和存储机制不同，影响私有 registry 登录和离线部署

CRI-O 把镜像存储耦合进自己的 storage.conf，containerd 则通过 plugins."io.containerd.grpc.v1.cri".registry 配置，两者对 auth、mirror、insecure 等字段的语义和生效位置完全不同。

使用场景：你在 air-gapped 环境部署，或用 Harbor + robot account 做镜像权限隔离。

立即学习“Python免费学习笔记（深入）”；

• CRI-O 的 registry auth 信息必须写在 /etc/crio/crio.conf.d/00-default.conf 的 [registries] 下，且只支持 auth_file（指向 ~/.docker/config.json 类文件），不支持 inline credentials
• containerd 在 config.toml 中用 configs."my-registry.example.com".auth 直接嵌套 username/password 或 auth 字段（base64 编码），更灵活，也更容易注入 CI 变量
• CRI-O 的镜像层解压默认走 overlayfs，但 storage driver 不可热替换；containerd 的 snapshotter（如 overlayfs、native）可按命名空间动态切换，适合混部 kata 和普通容器

调试时看到的错误日志风格差异大，定位链路不一样

containerd 日志里你会频繁见到 ctr、shim、task 等概念；CRI-O 日志则围绕 pod、container、image server 展开。这不是术语偏好问题，而是底层抽象层级不同。

典型错误：failed to create container: failed to mount rootfs: invalid argument

• 在 containerd 中，这大概率是 snapshotter 初始化失败（比如 overlayfs 不支持 d_type），查 journalctl -u containerd -n 100，重点看 snapshotter 模块日志
• 在 CRI-O 中，同错误更可能出现在 crio --log-level debug 输出里，并关联到 storage.driver 初始化阶段，此时要检查 /var/lib/containers/storage 所在文件系统是否启用 ftype=1
• 两者都不直接暴露 runc exec 日志，真要查容器进程启动失败，得去 /run/runc/xxx/ 下找 bundle 目录，再手动 runc run -d 复现——这个环节没人帮你绕过

升级风险点不在版本号本身，而在 CRI 协议兼容性和插件生命周期

Kubernetes 1.27+ 开始逐步弃用 CRI v1alpha2，而 CRI-O 1.26 仍默认用它；containerd 1.7 已全面转向 v1，但部分 distro（如 ubuntu 22.04 的 cloud-init 镜像）打包的 containerd 1.6.12 仍带 alpha2 兼容开关。版本数字接近不代表协议就通。

• 升级前务必确认 kubelet 的 --feature-gates=CRISocket=true 是否开启，以及 kubelet --version 输出中是否含 CRI v1
• CRI-O 升级后若 kubelet 启动报 connection refused，先检查 systemctl status crio 是否成功加载了新 socket，而不是直接重试 kubelet
• containerd 升级后，旧的 ctr CLI 可能无法连新 daemon（尤其跨大版本），要用 ctr --address /run/containerd/containerd.sock 显式指定，别依赖默认值

最常被忽略的是：CRI-O 不管理 runc 生命周期，升级 runc 后必须重启 CRI-O；containerd 则会在启动时校验 runc 版本并拒绝加载太旧的二进制——这个“自动拦截”看似省事，实则掩盖了底层不一致的问题。