资讯动态

gVisor 在 Kubernetes 上报 RuntimeHandler “runsc“ not supported 怎么排查?

发布时间:2026/9/14 13:13:59 来源:尧图企业网站定制
gVisor 在 Kubernetes 上报 RuntimeHandler runsc not supported 怎么排查【免费下载链接】gvisorApplication Kernel for Containers项目地址: https://gitcode.com/GitHub_Trending/gv/gvisor在 Kubernetes 集群的节点上配置好 gVisor 的containerd-shim-runsc-v1后用runtimeClassName: gvisorhandler 为runsc创建 Pod 时一个常见失败是 Kubernetes 报出RuntimeHandler runsc not supported。这个错误说明 Kubernetes 使用的 CRI runtime 没有被配置为处理runsc这个 runtime handler——也就是说 kubelet 请求的 runtime在你实际使用的 CRI 运行时通常是 containerd里并没有对应的配置项。排查路径按顺序是先核对 containerd 配置是否包含runscruntime 并且 containerd 已重启再核对runsc与 shim 二进制是否已安装就位如果集群是用 kubeadm 搭建的且同时装了 Docker还要处理 kubeadm 默认偏向 Docker 的问题。以下命令均来自 FAQ 和 Containerd Quick Start。第一步核对 containerd 配置并重启RuntimeHandler runsc not supported的直接含义是 Kubernetes CRI runtime 没有把runsc设置为 runtime handler。FAQ 给出的第一条排查建议是确认 containerd 的配置已正确创建并且 containerd 已经重启过。检查/etc/containerd/config.toml中是否存在runsc这个 runtime。官方快速开始文档给出的参考配置是cat EOF | sudo tee /etc/containerd/config.toml version 2 [plugins.io.containerd.runtime.v1.linux] shim_debug true [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc] runtime_type io.containerd.runc.v2 [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runsc] runtime_type io.containerd.runsc.v1 EOF两个适用条件containerd-shim-runsc-v1必须在${PATH}中或位于containerd二进制同一目录下否则 containerd 找不到 shimcontainerd 最低支持版本为 1.3.9 或 1.4.3。如果你在用 containerd 2.x文件头部应使用version 3。配置修改后必须重启 containerd 才会生效sudo systemctl restart containerd注意该命令会重启 containerd 服务节点上正在运行的 containerd 管理容器会短暂受影响生产环境需先评估。核对二进制是否已安装配置正确的前提下还要确认runsc和containerd-shim-runsc-v1两个二进制已按 安装指南 装好。gVisor 要求 Linux 5.6支持 x86_64 和 ARM64。apt 仓库或 release tarball 两种方式都会同时提供这两个二进制tarball 解压到/usr/local/bin后runsc还会查找其旁边的gvisor-bin/目录两者不要拆开。第二步kubeadm 集群特有的坑——Docker 抢占了 CRI socketFAQ 明确指出如果你已经确认 containerd 配置正确、集群又是用 kubeadm 创建的请检查该节点上是否同时安装了 Docker。Kubeadm 在 Docker 和 containerd 同时存在时会优先使用 Docker这样 kubelet 连接的 CRI socket 根本不是 containerdrunscruntime handler 自然不可用。两种修复方式按集群现状选择方式一重建集群文档给出的推荐做法在 kubeadm 命令上显式指定 CRI socketkubeadm init --cri-socket/var/run/containerd/containerd.sock ...方式二修复现有集群编辑/var/lib/kubelet/kubeadm-flags.env文件把--container-runtime设为remote并把--container-runtime-endpoint指向 containerd 的 socket例如/var/run/containerd/containerd.sock。第三步验证 runsc runtime 是否真的可用修好配置后可以用 crictl 直接通过 CRI 接口验证安装方式见快速开始文档此处仅列关键步骤# crictl 配置文件 cat EOF | sudo tee /etc/crictl.yaml runtime-endpoint: unix:///run/containerd/containerd.sock EOFsudo crictl pull nginx创建 sandbox 请求文件sandbox.json文档示例内容cat EOF | tee sandbox.json { metadata: { name: nginx-sandbox, namespace: default, attempt: 1, uid: hdishd83djaidwnduwk28bcsb }, linux: { }, log_directory: /tmp } EOF关键是--runtime runsc这个参数如果 runtime handler 未注册crictl runp这一步就会失败能成功拿到SANDBOX_ID说明 containerd 侧的runschandler 已就位SANDBOX_ID$(sudo crictl runp --runtime runsc sandbox.json)再验证容器确实跑在 gVisor 里——在容器内执行dmesg输出应包含 gVisor 的启动日志以下为文档示例输出sudo crictl exec ${CONTAINER_ID} dmesg | grep -i gvisor[ 0.000000] Starting gVisor... [ 0.445958] Forking spaghetti code... [ 0.794963] Feeding the init monster... ... [ 2.789133] Ready!通过 Kubernetes 做最终验证回到 Kubernetes 层面按快速开始文档部署 RuntimeClass 并使用它创建 Podcat EOF | kubectl apply -f - apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: gvisor handler: runsc EOFcat EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: nginx-gvisor spec: runtimeClassName: gvisor containers: - name: nginx image: nginx EOFkubectl get pod nginx-gvisor -o wide如果此前报RuntimeHandler runsc not supported的 Pod 现在能正常调度并进入 Running 状态问题即解决。排查要点回顾与限制错误本身只指向一件事CRI runtime 端缺少runschandler 配置。所以排查顺序是「containerd 的 config.toml 是否有runtimes.runsc段 → containerd 是否重启 → kubeadm 集群是否被 Docker 抢占了 CRI socket」。CNI 插件是完成 pod 网络的前提快速开始文档建议用 containerd 项目自带的./script/setup/install-cni脚本按默认设置安装脚本会安装 CNI 插件到节点需要相应权限。更底层的 shim/runsc 参数配置/etc/containerd/runsc.toml、shim 日志、gVisor debug log见 Containerd Advanced Configuration当crictl runp --runtime runsc已能成功、问题转向 Pod 启动异常时才需要。CRI-O 走的是另一套配置路径/etc/crio/crio.conf.d/99-gvisor.conf且 CRI-O 文档 明确说明它不受 gVisor 官方支持、不覆盖集成测试遇到同样报错时优先核对上面的 containerd 路径。修完集群层面的配置后如果 Pod 还能起来但业务容器行为异常属于另一类兼容性问题按 Debugging 指南 处理即可。【免费下载链接】gvisorApplication Kernel for Containers项目地址: https://gitcode.com/GitHub_Trending/gv/gvisor创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价