k8s网络插件初始化失败常因宿主机残留虚拟网卡（如cni0、flannel.1及veth设备）导致，需先解绑再删除：ip link set vethxxx master none后执行ip link delete vethxxx，并清理桥接设备、重启docker/kubelet、清空/var/lib/cni/目录。
遇到 K8s 网络插件（如 Flannel 或 Calico）初始化失败、节点反复卡在 CNI 准备阶段时，常因宿主机残留旧的虚拟网卡（尤其是 veth 设备和桥接设备如 cni0、flannel.1）导致。这些设备未被正确清理，会干扰新 CNI 插件的网络配置，典型报错包括：failed to set bridge addr has an IP address different from 10.244.x.1/24 或 networkPlugin cni failed to set up pod network。此时不能直接暴力删所有 veth，而要精准识别、安全解绑后再删除。
先确认哪些 veth 是真残留，不是正在用的
盲目执行 ip link delete vethxxx 容易失败（报 Device or resource busy），甚至引发网络抖动。关键第一步是验证该 veth 是否已“失主”：
- 查它是否还挂在网桥上：
readlink /sys/class/net/vethxxx/master—— 若输出类似/sys/devices/virtual/net/cni0，说明仍绑定在网桥，需先解绑 - 查它是否关联到某个活跃网络命名空间：
grep -l "vethxxx" /proc/*/net/ns 2>/dev/null—— 若无输出，基本可判定 netns 已销毁 - 查创建时间是否远早于当前容器：
stat /sys/class/net/vethxxx对比docker ps -a --format "{{.CreatedAt}}\t{{.Names}}" | head -10，若 veth 的 Birth 时间远早于所有容器，大概率是残留
强制清理前必须解绑再删除
veth 是成对存在的虚拟设备，一端在容器 netns，一端在宿主机并挂载到网桥（如 cni0 或 docker0）。只要没从网桥摘除，内核就认为它还在使用。所以标准流程是两步：
- 解除与网桥的逻辑绑定：
ip link set vethxxx master none（这一步不可省，否则ip link delete必报错） - 再执行删除：
ip link delete vethxxx - 验证是否清空：
bridge link | grep vethxxx应无输出；ip link show vethxxx应提示Device "vethxxx" does not exist
配合清理 CNI 核心桥接设备
除了 veth，Flannel/Calico 初始化失败常因旧桥接设备冲突。例如：
-
cni0：CNI 默认桥，若已有 IP（如 10.244.0.1/24）但新配置要求 10.80.0.1/16，必须删掉重建 -
flannel.1：Flannel VXLAN 后端的 overlay 接口，重复存在会导致 vxlan 端口冲突 - 操作命令：
ip link delete cni0和ip link delete flannel.1（注意：确保 kubelet 和 docker 已停，否则可能被自动重建）
清理后别忘了同步服务状态
删完网卡只是第一步，后续必须让系统重新进入干净初始化流程：
- 重启依赖服务：
systemctl start docker && systemctl start kubelet - 检查 cgroup driver 是否一致（常见坑）：
kubelet和docker必须同用systemd或cgroupfs；不一致会卡在启动，需统一修改/etc/docker/daemon.json和kubelet启动参数 - 重跑初始化：
kubeadm init或kubeadm join前，确保/var/lib/cni/目录为空，避免旧 IPAM 缓存干扰
