crictl 的 inspect/run/stats 是 cri 兼容性验证探针，非通用调试命令；其异常行为（如字段缺失、状态为空、stats 为 0）反映运行时未严格遵循 cri 规范，需检查配置、端点、cgroup 及分步执行流程。
crictl 的 inspect/run/stats 不是通用调试命令，而是 CRI 兼容性验证的“探针”——它们的行为必须严格符合 CRI 规范，否则说明运行时（如 containerd）或配置存在底层偏差。
crictl inspect 返回字段缺失或结构异常
常见错误现象：crictl inspect 输出中缺少 info.runtimeSpec、status.state 为空、status.pid 为 0 —— 这不是 crictl 本身的问题，而是容器运行时未按 CRI spec 正确填充 PodSandbox 或 Container 状态。
- 检查运行时是否启用 CRI 插件（例如 containerd 需确认
[plugins."io.containerd.grpc.v1.cri"]在/etc/containerd/config.toml中未被注释且disabled = false） - 确认
crictl连接的是 CRI 端点而非直连 runc 或低层 socket：运行crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock pods显式指定端点，排除 dockershim 遗留配置干扰 - 若使用 cri-o，需注意其
inspect默认不返回完整 OCI runtimeSpec，需加--verbose参数才输出runtimeSpec字段
crictl run 启动容器后立即退出，且无日志可查
这通常不是镜像问题，而是 CRI 层对容器生命周期管理的兼容性断点：CRI 要求运行时在创建容器后必须进入 “Created” 状态，再由 kubelet 调用 StartContainer；而 crictl run 是绕过 kubelet 的裸调用，某些运行时（尤其旧版 cri-o）会跳过状态机校验直接执行并退出。
- 优先改用
crictl pull <image></image>+crictl create <sandbox><config><runtime></runtime></config></sandbox>+crictl start <container-id></container-id>分步执行，观察哪一步失败 - 检查容器配置 json 中
linux.security_context.privileged是否为true：部分运行时在 CRI 模式下拒绝裸 privileged 容器，需显式开启privileged_without_host_devices或关闭该字段 - 避免使用
crictl run --rm：CRI 不定义 –rm 语义，该参数会被忽略，但可能触发运行时未处理的清理逻辑导致静默失败
crictl stats 显示 CPU/Mem 为 0 或 NaN
crictl stats 依赖运行时通过 CRI 的 ListContainerStats 接口返回 cgroup v1/v2 的原始统计值。若返回空或无效数字，大概率是运行时未正确挂载 cgroup 子系统，或节点未启用对应 cgroup 版本。
- 确认节点 cgroup 版本：运行
cat /proc/1/cgroup | head -1，输出含0::/表示 cgroup v2，含8:perf_event:/等数字前缀则为 v1 - containerd 必须与内核 cgroup 版本匹配：v1 模式下需确保
/sys/fs/cgroup/cpu,cpuacct等目录可读；v2 模式下需开启systemd.unified_cgroup_hierarchy=1并重启 containerd - stats 数据延迟约 5–10 秒，不要依赖
crictl stats -o json的瞬时值做自动化判断；建议用crictl stats --no-trunc配合watch -n 2观察趋势
真正难排查的不是命令报错，而是命令“看似成功却返回不符合 CRI spec 的数据”——比如 inspect 里 status.started_at 是零值时间戳，或 stats 中 memory working_set_bytes 恒为 0。这些细节不会中断操作，但会让上层控制器（如 kubelet、vertical-pod-autoscaler）做出错误决策。