K8s Pod卡在ContainerCreating状态（Kata运行时）排查求助

已排除的故障方向 #

• 镜像拉取异常：worker-001节点本地已存在业务nginx镜像、pause基础镜像，无镜像缺失问题
• 基础运行时/网络异常：同节点使用默认runc运行的kube-proxy、flannel、普通nginx DaemonSet Pod均正常运行，CRI、CNI基础链路无故障
• 调度异常：Pod已成功绑定到worker-001节点，调度流程全量完成

核心故障范围 #

报错Failed to create pod sandbox: rpc error: code = DeadlineExceeded desc = context deadline exceeded出现在使用kata-containers RuntimeClass创建Pod沙箱阶段，普通runc Pod无异常，故障点明确在Kata Containers运行时链路，和业务镜像、K8s核心组件无关。
结合现有配置，高概率故障点按优先级排序：

1. 节点KVM虚拟化不可用：Kata基于QEMU启动轻量虚拟机创建沙箱，如果节点未加载kvm内核模块、/dev/kvm设备权限不足、虚拟机场景未开嵌套虚拟化，会导致QEMU启动VM流程卡住，直到触发kubelet沙箱创建超时
2. Kata配置不匹配：configuration-qemu.toml中配置shared_fs = "virtio-9p"，但同时配置了virtio-fs专用的virtiofsd守护进程路径，配置项冲突会导致沙箱启动流程卡住
3. CRI-O未正确识别Kata运行时：现有运行的Pod均使用default（runc）运行时，无Kata运行时的Pod成功创建记录，不排除CRI-O加载Kata runtime配置失败的可能

下一步排查操作 #

在worker-001节点执行以下命令获取精准报错：

• 检查KVM虚拟化可用性

# 确认kvm内核模块加载状态
lsmod | grep kvm
# 确认KVM设备权限
ls -l /dev/kvm
# 验证QEMU程序可正常执行
/usr/libexec/qemu-kvm --version

• 查看CRI-O服务日志中Kata相关报错

journalctl -u crio --since "1 hour ago" | grep -iE 'kata|sandbox'

• 验证CRI-O是否正确识别Kata运行时

crictl info | jq '.config.runtimes'

对应修复方案 #

• KVM不可用场景：物理机执行modprobe kvm_intel（Intel CPU）或modprobe kvm_amd（AMD CPU）加载内核模块；虚拟机场景先在宿主机开启嵌套虚拟化配置，再加载对应kvm模块
• Kata配置冲突场景：如果部署的Kata版本默认使用virtio-fs，将shared_fs = "virtio-9p"修改为shared_fs = "virtio-fs"，保存后执行systemctl restart crio重启CRI-O服务
• 运行时识别失败场景：核对CRI-O配置中kata的runtime_path路径和实际containerd-shim-kata-v2二进制路径一致，修正后重启CRI-O
  修复完成后删除故障Pod，触发Deployment自动重建即可：

kubectl delete pod sandboxed-nginx-98bb68c4d-26ljd

内容的提问来源于stack exchange，提问作者mickt