Kubernetes pod 在 containerd 的“k8s.io”命名空间中运行。此“运行时命名空间”概念是 containerd 特有的，不是 CRI 的一部分。
如果 kubelet 确实遵循 CRI 标准，那么它一定无法在这样的 containerd 命名空间中运行容器。
crictl 不支持这个“运行时命名空间”，因此只能与默认命名空间中的 containerd 通信。
这符合错误报告的资格吗？
答案1
Kubernetes 容器运行时接口（CRI）定义了节点组件 kubelet 与容器运行时之间通信的主要 gRPC 协议。您的容器运行时必须至少支持容器运行时接口的 v1alpha2。
批判性思维为兼容 CRI 的容器运行时提供 CLI。这允许 CRI 运行时开发人员调试其运行时，而无需设置 Kubernetes 组件。这是 kubernetes v1.29 中的预期行为，kubelet 倾向于使用 CRI v1。如果容器运行时不支持 CRI 的 v1，则 kubelet 会尝试协商任何较旧的受支持版本。如果 kubelet 无法协商受支持的 CRI 版本，则 kubelet 会放弃并且不会注册为节点。
crictl 目前处于 Beta 阶段，仍在快速迭代中。它托管在 cri-tools 存储库中。Github 社区鼓励 CRI 开发人员报告错误或通过添加更多功能来帮助扩大覆盖范围。