“No networks found in /etc/cni/net.d”是kubelet因未找到CNI配置文件而拒绝启动Pod网络的硬性拦截信号，根因是CNI插件未加载，常见于kubeadm init后节点NotReady或reset后未重装插件，需核查kubelet实际读取的--cni-conf-dir路径、配置文件存在性、/opt/cni/bin下二进制完整性及权限、插件Pod就绪状态与运行时刷新。
“No networks found in /etc/cni/net.d” 是什么信号
这不是配置遗漏的提示，而是 kubelet 明确拒绝启动 Pod 网络的硬性拦截。它代表 CNI 插件根本没被加载——不是规则错、不是版本不兼容，是连配置文件都没见到。常见于 kubeadm init 后节点卡在 NotReady，或 kubeadm reset 清理后未重装插件。
检查 kubelet 实际读取的 CNI 路径是否匹配
kubelet 不一定读 /etc/cni/net.d，它的行为由启动参数控制。错误常出在路径被改过但插件没同步放过去。
- 运行
ps aux | grep kubelet，找--cni-conf-dir和--cni-bin-dir参数值 - 若参数指向
/opt/cni/net.d或其他路径，就去对应目录下确认是否存在.conf或.conflist文件 - 检查 systemd 服务配置：查看
/etc/systemd/system/kubelet.service.d/10-kubeadm.conf中是否覆盖了默认路径 - 如果路径被手动修改过，但
kubectl apply -f calico.yaml（或其他插件）仍往默认路径写配置，就会彻底失联
Calico/Cilium/Flannel 安装后仍超时的三个关键点
插件 YAML 应用成功 ≠ 插件已就绪。CNI 初始化超时往往卡在控制器未 ready 或节点未完成网络注册。
- 检查插件核心组件状态：
kubectl get pods -n kube-system -l k8s-app=calico-node（或cilium、flannel），确保全部为Running - 看日志有没有
Failed to create pod sandbox或failed to find plugin "calico"类报错，说明插件二进制缺失或权限不对 - Cilium 用户注意：
cilium status --verbose会暴露 BPF 加载失败、etcd 连接超时等真实瓶颈，比单纯看 Pod 状态更准 - Flannel 用户注意：确认
host-gw模式下节点间三层路由可达，vxlan模式下检查 UDP 8472 端口是否被防火墙拦截
超时阈值本身可调，但掩盖问题不如直击根因
kubeadm 默认等待 5 分钟初始化 CNI，可通过 --skip-phases=addon/coredns 跳过部分阶段，但真正卡住时，改超时只是拖延诊断。最常被忽略的是：
- 节点上
/opt/cni/bin目录为空 —— 多数插件 YAML 不自动部署二进制，需手动下载并 chmod +x - 容器运行时（如 containerd）未重启，导致旧缓存仍在尝试加载已删除的 CNI 配置
- 使用非标准架构（arm64、riscv64）时，插件二进制未适配，
file /opt/cni/bin/calico会显示 “cannot execute binary file”
网络插件初始化不是“apply 一下就完事”，它依赖路径、二进制、权限、运行时刷新四者严丝合缝。少一个，kubelet 就停在原地不动。
