minikube启用gVisor后无法启动Pod 提示cni0添加IP权限被拒绝

这个报错的核心原因是gVisor runsc沙箱缺少网桥操作权限，叠加旧版本插件配置缺陷、启动参数冗余的问题，按以下步骤排查修复即可：

• 第一步：清理异常旧环境
  如果你用的minikube版本低于1.30，先升级到最新稳定版，旧版本gVisor插件自动生成的containerd配置存在权限遗漏。升级后执行以下命令彻底清理旧集群：

  minikube delete --all
  

  重新启动集群时不要加多余的docker相关参数，--docker-opt是给docker runtime用的，containerd runtime下加这个参数会导致socket挂载异常，正确启动命令：

  minikube start --container-runtime=containerd
  minikube addons enable gvisor
  

• 第二步：校验runsc运行时权限配置
  等gvisor插件Pod运行正常后，执行minikube ssh进入节点，检查containerd配置文件/etc/containerd/config.toml中runsc运行时的cap配置，必须包含CAP_NET_ADMIN、CAP_NET_RAW两个网络操作权限，否则沙箱没有权限修改cni0网桥的IP地址。
  正确的runsc配置段参考：

  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc]
    runtime_type = "io.containerd.runsc.v1"
    binary_name = "/usr/local/bin/runsc"
    privileged_without_host_devices = false
    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc.options]
      Root = "/run/containerd/runsc"
      Caps = ["CAP_NET_ADMIN", "CAP_NET_RAW", "CAP_SYS_CHROOT", "CAP_DAC_OVERRIDE"]
  

  如果配置缺失，手动补全后执行sudo systemctl restart containerd重启服务生效。
• 第三步：清理异常残留网桥
  之前创建失败的请求会留下状态异常的cni0网桥，在ssh会话中执行以下命令删除残留网桥，后续创建Pod时CNI会自动重建配置正确的网桥：

  sudo ip link set cni0 down
  sudo brctl delbr cni0
  

• 第四步：功能验证
  新建带gVisor runtime类的测试Pod：

  apiVersion: v1
  kind: Pod
  metadata:
    name: nginx-gvisor-test
  spec:
    runtimeClassName: gvisor
    containers:
    - name: nginx
      image: nginx:alpine
  

  正常情况下Pod会在10秒内进入Running状态，不会再出现沙箱创建失败的权限报错。

避坑提示：不要手动替换为calico等第三方CNI，minikube的gVisor插件默认和内置bridge CNI做适配，手动更换CNI会导致网络规则不匹配触发其他问题。如果之前修改过CNI配置，直接删除集群重新初始化是效率最高的修复方式。

内容的提问来源于stack exchange，提问作者morloch