crictl 是 Kubernetes 中专用于 CRI 运行时（如 containerd、CRI-O）的调试工具，可绕过 kubelet 直接查看真实容器与 Pod 沙箱状态，支持 inspect、logs、exec 等操作快速定位镜像拉取失败、Pod 卡住、容器异常退出等问题。
在 Kubernetes 中，crictl 是专为 CRI（Container Runtime Interface）设计的命令行工具，适用于使用 containerd、CRI-O 等符合 CRI 规范的运行时环境。当 Node 节点出现 Pod 异常、容器卡住、无法拉镜像或状态不一致时，crictl 可直接与底层容器运行时交互，绕过 kubelet，快速定位真实容器状态。
确认 crictl 已正确配置并连接到运行时
crictl 默认通过 Unix socket 与容器运行时通信，需确保配置指向正确的 socket 路径和运行时类型：
- 检查配置文件：
/etc/crictl.yaml（若不存在可手动创建），内容示例：
runtime-endpoint: unix:///run/containerd/containerd.sock image-endpoint: unix:///run/containerd/containerd.sock timeout: 10 debug: false
- 验证是否连通：运行
crictl version，应返回运行时名称（如 containerd）及版本；若报错“connection refused”，说明 socket 路径错误或容器运行时未运行 - 常见 socket 路径：
/run/containerd/containerd.sock（containerd）、/var/run/crio/crio.sock（CRI-O）
查看节点上所有容器及对应 Pod 信息
不同于 kubectl get pods（展示 API 层视图），crictl 显示的是运行时实际存在的容器实例，包括已退出、沙箱未清理或被强制删除但残留的容器：
-
crictl ps -a：列出所有容器（含已停止的），重点关注STATUS（如Exited(137)）、CREATED时间、ATTEMPT（重启次数） -
crictl ps -a --pod：附加显示所属 Pod ID，便于关联到具体工作负载 -
crictl pods：列出所有 Pod 沙箱（sandbox），注意STATUS是否为Ready；若为NotReady或长时间Creating，说明沙箱启动失败（常见于镜像拉取超时、CNI 初始化异常）
深入排查单个容器或 Pod 的详细状态
定位到异常容器 ID 或 Pod ID 后，可进一步获取运行时原生状态：
-
crictl inspect <container-id>：查看容器完整配置、挂载、网络命名空间、启动参数、健康检查设置等；特别关注state.status、state.finishedAt、status.message字段 -
crictl inspectp <pod-id>：检查 Pod 沙箱级信息，包括 infra 容器状态、网络配置（如network.networkNamespace）、DNS 设置 - 若容器反复崩溃，结合
crictl logs <container-id>查看最后输出（注意：仅对仍存在 stdout/stderr 缓冲的容器有效；已退出且未启用日志驱动持久化的容器可能无日志）
辅助诊断常见问题的实用组合操作
针对典型故障场景，可快速执行以下命令链：
-
Pod 卡在 ContainerCreating：先
crictl pods --quiet | xargs -L1 crictl inspectp 2>/dev/null | grep -A5 'status.*Creating\|reason\|message'，查找沙箱创建失败原因（如 CNI 插件未就绪、/etc/cni/net.d 为空） -
容器状态显示 Running，但业务无响应：用
crictl exec -it <container-id> sh进入容器内部验证进程、端口、配置；若 exec 失败，说明容器内 init 进程异常或 PID 命名空间损坏 -
镜像拉取失败但 kubectl 不提示：运行
crictl pull <image>手动触发，观察错误（如证书问题、registry 认证失败、镜像不存在）；再查crictl images确认本地是否存在该镜像及 tag 是否匹配
