Pod卡在ContainerCreating状态的常见原因有五类：①Init容器失败；②Volume挂载失败；③CRI层（如containerd）创建sandbox失败；④CNI网络配置异常；⑤SecurityContext或SELinux限制触发拒绝。
Pod 卡在 ContainerCreating 状态，且 kubectl describe pod 显示的不是常见的 ImagePullBackOff，而是其他原因，说明问题出在镜像拉取之后、容器真正启动之前的阶段。这类情况往往更隐蔽，需要逐层排查初始化环节。
Init 容器失败（Init:Error 或 Init:CrashLoopBackOff）
如果 Pod 定义了 initContainers，Kubernetes 会严格按顺序执行它们，全部成功后才启动主容器。只要任一 init 容器退出非 0 状态、崩溃或超时，Pod 就卡在 ContainerCreating，describe 输出中会显示类似 Init:Error 或 Init:CrashLoopBackOff，而非主容器的状态。
- 运行
kubectl logs <pod-name> --all-containers --prefix查看所有容器（含 init）的日志 - 用
kubectl get pod -o wide确认 Pod 调度到哪个节点，再登录该节点检查journalctl -u kubelet -n 100 --no-pager，常能发现 init 容器因权限、挂载、网络或命令不存在等失败的具体错误 - 常见陷阱：init 容器用了 alpine 镜像但执行了 bash 脚本（alpine 默认无 bash）、尝试写入只读路径、依赖 ConfigMap/Secret 未就绪
Volume 挂载失败（如 NFS、CSI 插件未就绪、PV/PVC 绑定异常）
当 Pod 声明了 volume（尤其是 network storage 类型），kubelet 在启动容器前需先完成挂载。若挂载卡住或失败（例如 NFS 服务不可达、CSI driver Pod 未运行、StorageClass 动态供给超时），Pod 就会滞留在 ContainerCreating，describe 中可能只显示 Waiting for volumes to attach or mount，或事件里出现 MountVolume.SetUp failed。
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 检查 PVC 状态：
kubectl get pvc <name>是否为Bound；如是Pending，用kubectl describe pvc看事件原因（如 StorageClass 不存在、配额不足） - 确认对应 PV 是否存在且状态正常；若用 CSI，检查
kubectl get csidriver和kubectl get pods -n kube-system | grep csi - 在 Node 上手动测试挂载：比如
showmount -e <nfs-server>或mount -t nfs4 <server>:/path /mnt/test，验证底层存储连通性
Kubelet 无法创建容器运行时沙箱（CRI 层问题）
即使镜像已存在、volume 已挂载，kubelet 调用容器运行时（如 containerd 或 dockerd）创建 sandbox 容器时仍可能失败。此时 describe 通常无明确错误，事件里可能只有模糊的 Failed to create pod sandbox，需查 kubelet 日志定位。
- 登录 Pod 所在 Node，执行
sudo crictl ps -a | grep <pod-id>（containerd）或docker ps -a | grep <pod-name>（dockershim），看是否有残留的 pause 容器或异常状态 - 检查 containerd 日志：
sudo journalctl -u containerd -n 200 --no-pager，常见报错如failed to load cni config、no available IP addresses（CNI 分配失败）、permission denied on /run/containerd - CNI 是高频雷区：确认
/etc/cni/net.d/下配置文件存在且格式正确，/opt/cni/bin/中插件二进制可执行，Calico/Flannel 等 CNI Pod 是否全 Running
SecurityContext 或 SELinux 限制触发拒绝
当 Pod 或容器设置了 securityContext（如 runAsUser、seLinuxOptions、privileged: true），而节点策略或内核模块不满足时，容器运行时可能静默拒绝创建 sandbox。describe 不报具体错误，但 kubelet 日志会出现 failed to create containerd task 或 permission denied 类提示。
- 临时去掉 securityContext 字段测试是否恢复，快速验证是否为此类问题
- 在 Node 上检查 SELinux 状态：
getenforce，若为Enforcing，查看sudo ausearch -m avc -ts recent是否有拒绝日志 - 对 privileged 容器，确认 kubelet 启动参数含
--allow-privileged=true（v1.26+ 已废弃，需通过 PSP 或 PodSecurityPolicy 替代）
