pod-sandbox-failed

Pod 创建沙箱失败（failed to create pod sandbox）的定位与修复

现象

Pod 长时间停在 ContainerCreating，kubectl describe pod 的 Events 出现 failed to create pod sandbox，后面通常跟一段运行时错误，例如连接 CRI socket 失败、创建 pause 容器失败、网络命名空间配置失败或 cgroup 设置失败。kubelet 日志里也能看到同一错误的完整堆栈。

沙箱是 Pod 的基础环境，包含 pause 容器、网络命名空间、IPC 命名空间和 cgroup。沙箱没有建好，业务容器就不会开始拉镜像。排查时要先分清失败发生在运行时层、CNI 网络层还是节点资源层。Events 里的错误经常被截断，完整堆栈在 kubelet 日志中，定位时不要只复制第一行。同一节点所有新 Pod 都失败时优先怀疑节点级问题；只有个别 Pod 失败时，优先检查 Pod 配置和安全策略。

快速定位

先看 Pod 事件和节点：

kubectl describe pod <pod> -n <ns>
kubectl get events -n <ns> --sort-by=.lastTimestamp | tail -30
kubectl get node <node> -o wide

登录节点查看 kubelet 与运行时日志：

journalctl -u kubelet --since '30 min ago' | grep -i -E 'sandbox|runtime|containerd|cni'
systemctl status containerd
crictl info
crictl pods
crictl images | grep -i pause

检查 CNI 和节点资源：

ls -l /etc/cni/net.d/ /opt/cni/bin/
df -h
df -i
dmesg -T | tail -50

如果 crictl info 连不上，先确认运行时 endpoint 和 socket 权限：

crictl --runtime-endpoint unix:///run/containerd/containerd.sock info
ls -l /run/containerd/containerd.sock

再核对 kubelet 与运行时的 cgroup driver 是否一致：

grep -i cgroup /var/lib/kubelet/config.yaml
containerd config dump | grep -i -E 'cgroup|sandbox'

同时确认节点没有 NotReady、DiskPressure、MemoryPressure 等 Condition，并检查 kubelet 是否在持续重启。

事件里出现 network plugin is not ready、failed to setup network for sandbox 时，优先查 CNI；出现 failed to create containerd container、no such image、context deadline exceeded 时，优先查运行时和 pause 镜像；出现 no space left on device、too many open files、cannot allocate memory 时，优先查节点资源。

常见根因

1. 容器运行时没有启动、崩溃或卡住，CRI socket 不可达，kubelet 无法创建沙箱。
2. CNI 插件未就绪、配置缺失或冲突，Pod 网络命名空间和 IP 分配失败。
3. pause/sandbox 镜像缺失、拉取失败，或运行时配置的镜像地址不可访问。
4. 节点磁盘或 inode 耗尽，无法创建容器快照、rootfs 或写入元数据。
5. kubelet 与运行时的 cgroup driver 不一致，systemd 与 cgroupfs 混用导致 cgroup 创建失败。
6. overlayfs、br_netfilter 等内核模块缺失，或 /var/lib/containerd 状态损坏。
7. SELinux/AppArmor 拒绝挂载、写目录或创建命名空间。
8. 节点 PID、线程或文件描述符耗尽，触发 pids.max 或内核限制。
9. 节点升级后 kubelet 与运行时 CRI 版本不兼容，或 socket 路径配置错误。
10. 残留的网络命名空间、CNI 状态文件或旧沙箱与本次创建冲突。
11. kubelet 自身配置错误、证书过期或与 API server 通信异常，导致创建流程半途失败。
12. Pod 的 securityContext、sysctl 或设备请求与节点内核能力冲突，在沙箱阶段被拒绝。

修复

• 先从 Events 和 kubelet 日志确认失败层次，不要直接重启节点。
• 重启运行时或清理状态前先保留现场：收集 journal、crictl info、crictl pods、dmesg 和存储目录状态，避免问题复现后证据丢失。
• 运行时不可用就检查 systemctl status containerd 和 journal，修复配置后重启运行时；重启会影响节点容器管理，应在维护窗口评估。
• crictl info 正常但创建仍失败时，检查运行时配置、sandbox 镜像和存储目录；必要时清理无主的沙箱、容器和快照。
• pause 镜像缺失时，从可达的仓库预拉取，或配置镜像加速/私有仓库；用 crictl images 确认镜像已存在。
• CNI 问题恢复 CNI DaemonSet，清理冲突的 /etc/cni/net.d 配置，检查 IP 池、路由和 NetworkPolicy。
• 清理 CNI 状态或网络命名空间前，先 cordon 节点阻止新 Pod 调度，处理完再 uncordon；直接删除命名空间可能影响正在运行的 Pod。
• cgroup 问题统一 kubelet 与运行时的 cgroup driver，重启两者后验证；cgroup v2 环境还要检查挂载和委托配置。
• 资源问题清理磁盘、inode 和未使用镜像；提高 PID/文件描述符限制，并确认没有进程泄漏。
• SELinux/AppArmor 问题查看审计日志，恢复正确标签或调整策略，不要直接关闭安全模块。
• 内核或文件系统异常先看 dmesg，修复模块和存储；状态目录损坏且无法恢复时，drain 节点后重建。
• Pod 级 sysctl、securityContext 或设备请求与节点能力冲突时，调整 Pod 配置或在节点启用对应特性，先在小范围验证再推广。
• 修复后删除卡住的 Pod 让它重新创建，并验证同节点其他 Pod、跨节点网络和 Service 访问。

相关命令

• kubectl — Pod 事件和节点状态
• crictl — 沙箱、镜像和运行时诊断
• containerd — 运行时配置与状态
• kubelet — kubelet 配置与日志
• cni — CNI 插件与配置
• journalctl — kubelet 和运行时日志
• systemctl — 服务状态与重启
• df — 磁盘和 inode 容量
• dmesg — 内核与文件系统错误

参考链接

• Kubernetes 容器运行时
• containerd CRI 配置
• CNI 规范
• Kubernetes Pod 生命周期

读完自测

合上页面，先回答，再展开对照。

1. 看到 failed to create pod sandbox，应先区分哪几个失败层次？
2. pause 镜像缺失会表现成什么，如何确认并修复？
3. 哪些节点资源或内核问题会导致沙箱创建失败？