containerd 和 cri-o 不能同时被 kubelet 激活，因为 kubelet 仅支持配置一个 CRI 端点；若 runtimeEndpoint 同时指向两者或服务共存为 active，kubelet 启动失败并报 container runtime 初始化错误。
为什么 containerd 和 cri-o 不能同时被 kubelet 激活
因为 kubelet 只允许配置一个 CRI（Container Runtime Interface）端点，底层通过 Unix socket 或 gRPC 连接唯一运行时。若同时启用了两个，kubelet 启动会失败，报错类似：failed to run Kubelet: unable to construct runtime manager: failed to initialize container runtime: failed to get container runtime version。
实操建议：
- 检查
/var/lib/kubelet/config.yaml中的runtimeEndpoint字段，它必须指向且仅指向一个有效 socket，如unix:///run/containerd/containerd.sock或unix:///var/run/crio/crio.sock - 确认对应运行时服务已启动：
systemctl is-active containerd或systemctl is-active crio，二者不可共存为 active 状态 - 若需临时切换，停掉当前运行时（
systemctl stop containerd），再启动目标运行时（systemctl start crio），最后重启kubelet
crictl 连不上运行时？先看 runtime-endpoint 配置是否匹配
crictl 默认连接 unix:///run/containerd/containerd.sock，但如果你用的是 cri-o，它监听的是 /var/run/crio/crio.sock —— 不配对就直接报 connection refused 或 context deadline exceeded。
实操建议：
- 用
crictl --runtime-endpoint unix:///var/run/crio/crio.sock ps显式指定 endpoint - 写入默认配置：创建
/etc/crictl.yaml，内容为：runtime-endpoint: "unix:///var/run/crio/crio.sock"
- 注意路径权限：
cri-osocket 默认属组crio，确保执行crictl的用户在该组内，否则会提示permission denied
Pod 启动卡在 ContainerCreating，大概率是镜像拉取或运行时插件不兼容
多运行时环境下，imagePullPolicy 行为一致，但底层镜像解包、OCI 运行时配置生成逻辑不同。比如 containerd 默认用 stargz 支持懒加载，而 cri-o 目前不支持；又比如某些使用 buildah 构建的镜像含非标准 OCI 注解，cri-o 可能拒绝运行。
实操建议：
- 查具体失败原因：
kubectl describe pod <pod-name>，重点关注 Events 区域里FailedCreatePodContainer或ImagePullBackOff后的详细错误 - 手动用运行时 CLI 拉镜像验证：
crictl pull nginx:1.25，失败则说明是运行时自身能力限制，不是集群配置问题 - 避免混用构建工具：生产环境统一用
docker build或buildah bud --format=docker输出 Docker 格式镜像，减少 OCI 兼容性干扰
想让不同命名空间跑不同运行时？Kubernetes 原生不支持，得靠调度器 + annotation 绕过
Kubernetes 没有“按命名空间绑定运行时”的机制，RuntimeClass 是 Pod 级别字段，且只能指定一个预注册的运行时名。所谓“多运行时并发管理”，本质是提前注册多个 RuntimeClass 对象，再由用户在 Pod spec 中显式声明。
实操建议：
- 先注册两个
RuntimeClass：containerd-default和crio-legacy，分别关联不同handler名（如io.containerd.runtime.v1.linux和cri-o） - 在 Pod YAML 中加：
runtimeClassName: crio-legacy
，注意该字段一旦设置，kubelet 就只找对应 handler，找不到就直接拒收 Pod - 容易忽略的一点：所有节点必须都安装并注册了该
RuntimeClass对应的运行时，否则调度过去就起不来 —— 没有 fallback 机制
真正麻烦的从来不是注册几个 RuntimeClass，而是当某个节点上两种运行时都装着，却因 socket 权限、cgroup v2 配置、或 SELinux 策略冲突导致其中一个静默失效。这种问题不会报错，只会让部分 Pod 随机失败。
