1. 问题现象与根因分析
1.1 “节点NotReady”是最典型的表面症状
这段时间后台好几个同学问我同一个问题：新节点加入Kubernetes集群后，kubectl get nodes一直显示NotReady，节点上Pod调度不过去，kube-system命名空间里的flannelPod反复CrashLoopBackOff，日志刷满了标准输出。
我这边复现出来的现象比较统一：节点明明已经执行过kubeadm join，证书流程也走完了，但节点状态就是起不来。直接看kubectl describe node会看到类似network plugin is not ready: cni config uninitialized的提示。这个提示基本就是在点名说——容器的网络插件没就绪，CNI配置压根没生成出来。顺着这个方向查下去，最后定位到的根因不是kubelet的问题，不是容器运行时的问题，而是flannel启动时网卡选择错了。
要理解这个问题，得先明白flannel的工作原理。flannel属于CNI方案里的Overlay网络插件，它在每个节点上启动一个flanneld进程，负责从etcd或Kubernetes API Server拉取子网配置，然后把本节点的Pod网段路由信息下发到宿主机路由表里，再通过VXLAN或host-gw模式将跨节点的Pod流量封装转发出去。核心前提是：flannel必须选对本节点上承载真实业务流量的那张网卡，并且集群所有节点上这张网卡的身份标识要能对上号。
问题就出在“选对网卡”这个环节。flannel默认的行为逻辑是：在启动时获取第一个满足条件的网卡，判断依据是网卡是否有内网IP、是否是UP状态、是否属于默认路由所在网卡。实际生产环境里，服务器往往有多个网卡：物理网卡、管理网卡、bond接口、虚拟网桥，再加上云厂商环境里常见的eth0、eth1这种命名，很容易导致flannel在自动探测时抓到一张完全不该用的网卡。最经典的情况就是：某控制节点上存在一张ens192的网卡负责实际业务通信，另一张docker0网桥或某虚拟网卡排在前面，flannel默认探测捕到了后者，于是它把Pod网段和路由信息全部绑定到了错误的网卡上，VXLAN隧道始终建不起来，节点网络一直处于异常状态。
比“选错网卡”更隐蔽的，是标题里这个“网卡名不兼容”。什么是网卡名不兼容？就是flannel在节点上通过-iface参数写死了特定网卡名，或者不同节点上同名网卡的IP网段互相冲突。比如你在一台机器上给flannel指定了--iface=eth0，但新加的节点上物理网卡叫enp3s0或ens160，根本不存在eth0这个逻辑名。这种情况下flannel要么启动时报找不到接口，要么启动成功但抓到了另一张毫无关联的网卡，节点进入半死不活的状态。这种问题在由不同型号服务器、不同虚拟化平台混合组成的集群里尤其常见，硬件命名规则不统一，网卡名编号对不上号，排错路径非常容易走偏。
1.2 多网卡环境下的身份混淆与隧道失效
从底层原理上看，flannel在VXLAN模式下做的事情可以简化成三步：第一，确定本节点的Pod网段（比如10.244.1.0/24）；第二，用一张物理网卡的IP和MAC地址作为VTEP的对外身份，与对端节点建立VXLAN隧道；第三，把节点上每个Pod的流量从flannel.1虚拟网卡送进隧道，再交给物理网卡发出去。任何一个环节里“网卡身份错乱”，整条链路就断了。
在实际多网卡场景中，最坑的还不是选错网卡本身，而是你很难一眼看出它选错了。因为flannel日志里通常不会直接写“我选错了网卡”，而是暴露出一堆看似不相关的错误。比如：
Failed to find any valid interface to use这是比较干脆的报错，说明所有网卡都过不了它的过滤条件。还有另外一种：
Error adding route to 10.244.1.0/24 via 10.244.0.1: network is unreachable这种就很迷惑，看着像路由问题，其实是flannel把路由加到了错误的网卡上，导致包根本发不出去。还有一种常见表现是flannelPod能运行，kubectl get pods显示Running，但节点状态就是永远卡在NotReady，因为CNI配置文件和节点状态的上报链路始终没走通。
我遇到过一个案例，某公司内部Kubernetes集群用的是自建机房，控制节点上同时存在一张em1（千兆业务网）和一张em2（千兆存储网），还有一块br0管理网桥。flannel默认抓取了br0这张桥接网卡，原因是它被系统列为“第一个非loopback接口”。结果VXLAN隧道建起来了，但是所有跨节点Pod流量都走到了管理网桥上，不仅不通，还把管理网络打出了高延迟。排查了很久，最后看/run/flannel/subnet.env和ip route才确认是网卡选择错位。
这里要强调的是，flannel选错网卡，本质上是自动探测逻辑无法覆盖你环境的“语义信息”。它不知道哪张网卡是你业务用的，它只知道规则“取第一个有内网地址的UP网卡”。所以解决思路从来不是跟探测逻辑较劲，而是显式告诉它“用哪张”，或者通过配置让正确的网卡成为它的首选。
1.3 为什么说“网卡名不兼容”比“网卡选错”更棘手
网卡选错，你改个参数指定--iface=eth0就能绕过，但如果两个节点的网卡名一样、IP段是不同网段，或者同一个节点上有一张网卡的名字在不同重启后发生漂移，问题就变得更复杂。
我在一次混合云场景下遇到过更奇葩的情况：某台节点上有一张eth0，但这张eth0是虚拟机管理程序模拟出来的虚拟网卡，真正承载业务的是后加的ens160。flannel默认识别到eth0，指定了--iface=eth0之后，表面上看flannel启动成功了，隧道也能建立，但Pod流量只要一跨节点就断。因为eth0的IP段是管理网段，它根本无法路由到对端Pod网段。
这类问题之所以棘手，是因为表面症状完全正常——Pod是Running状态，日志也没有明显异常，路由表看起来也有flannel的子网条目，但业务就是不通。只有把ip route、ip neigh、bridge fdb show全拉出来对照，才会发现flannel的VTEP地址用的是管理网IP，对端节点还在拿业务网IP找它。这种隐性故障比CrashLoopBackOff难查得多，也更值得在做网络规划时提前规避。
2. 排查思路与日志定位
2.1 先看节点状态，再分链路定位
拿到NotReady的节点，我不会第一时间翻flannel的日志，而是先按下面的顺序做一次快速体检：
- 查看节点状态和异常原因：
kubectl describe node <node-name>，关注Conditions里的Ready和NetworkUnavailable状态。 - 登录节点，查看kubelet日志：
journalctl -u kubelet -f，重点找network plugin is not ready或者cni config uninitialized。 - 查看容器运行时中的Pod状态：
crictl ps -a | grep flannel，确认flannel容器确实在重启。 - 进入flannel容器或者用
kubectl logs -n kube-system -l app=flannel --tail=200，抓现场日志。 - 直接暴力查看flannel生成的子网环境文件：
cat /run/flannel/subnet.env。
这几个动作做完，基本就能判断问题大致出在哪个环节。如果subnet.env文件不存在，说明flannel还没能从API Server获得子网配置，多半是网络连通性问题；如果subnet.env存在但里面的FLANNEL_IFACE字段指向了错误的网卡名或IP，那基本可以实锤是网卡识别异常了。
来看一个典型的异常样本。假设你的节点上有以下网卡：
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP inet 192.168.30.11/24 brd 192.168.30.255 scope global ens160 3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN inet 172.17.0.1/16 brd 172.17.0.255 scope global docker0docker0虽然没有实际流量，但它也在UP状态，且IP段是内网地址，flannel的默认探测逻辑完全有可能会抓到它。于是subnet.env里写的是：
FLANNEL_NETWORK=10.244.0.0/16 FLANNEL_SUBNET=10.244.1.0/24 FLANNEL_MTU=1450 FLANNEL_IFACE=172.17.0.1看到FLANNEL_IFACE是172.17.0.1，基本可以确认flannel把虚拟网桥当成了业务网卡。这个时候再去看路由表：
10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1 10.244.0.0/24 via 10.244.0.1 dev flannel.1 onlink缺失了对应的物理网卡路由条目，跨节点通信必定中断。
2.2 flannel日志里那句“I found interface”最关键
很多人在排障时喜欢翻到最后看Error，但flannel日志里真正有价值的信息其实藏在启动阶段。你会在日志开头看到类似这样的输出：
I1019 10:23:45.678901 1 main.go:203] Determining IP address of default interface I1019 10:23:45.678912 1 main.go:216] Using interface with name eth0 and address 192.168.30.11 I1019 10:23:45.678920 1 kube.go:132] Waiting for the cluster to become available重点看Using interface with name ... and address ...这一行。如果它显示的接口名或IP不是你所期望的业务网卡，那问题基本就在这了。如果在日志里看到：
W1019 10:23:45.678915 1 main.go:210] No default interface found, trying to find the first interface with a valid IP则说明默认路由探测失败，flannel进入了备选逻辑，这时候它选中的网卡往往更不靠谱。
排障时尤其要注意：flannel容器内看到的网卡名和宿主机上看到的不一定一致，但大多数情况是一致的（因为是hostNetwork模式，容器直接使用宿主网络命名空间）。如果你发现日志里写的网卡名跟你机器上的对不上，也可能是CNI网卡或网络策略工具的虚拟网卡插进来影响了判断。
2.3 用三条命令确认“网卡错位”实锤
确认网卡是否错位，我一般用三条命令搞定：
第一条，查看运行时flannel实际使用的网卡信息：
kubectl exec -n kube-system <flannel-pod-name> -- ip addr show这条命令可以看容器内实际看到的网卡和IP，比对subnet.env中的FLANNEL_IFACE值是否一致。
第二条，查看节点的路由表，重点找跟Pod网段相关的条目：
ip route | grep 10.244正常状态下，你会看到类似10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1的条目。如果只有一条，说明flannel还没有把跨节点路由下发到位。
第三条，查看VXLAN隧道对端信息：
bridge fdb show | grep flannel.1这条命令可以看到flannel.1上学习到的对端MAC地址，如果MAC地址和对应的IP不属于预期网卡，说明隧道对端的IP选错了。
这三条命令对照下来，基本能把“网卡错位”落实到具体层面：是选了一张虚拟网卡、选了一张管理网卡，还是选了一张IP完全跨网段的网卡，一目了然。
3. 解决方案与实操步骤
3.1 方案一：修改flannel DaemonSet参数，显式指定业务网卡
问题定位清楚之后，最直接有效的操作就是在flannel的DaemonSet配置里通过--iface参数告诉flannel该用哪张网卡。这个方案也是Kubernetes社区里最常见的规避手段。
步骤如下：
第一步，修改flannel的DaemonSet，让它通过环境变量或args参数指定网卡名。在kube-flannel.yml里找到容器启动参数的部分：
containers: - name: kube-flannel image: <你的flannel镜像地址> command: - /opt/bin/flanneld args: - --ip-masq - --kube-subnet-mgr - --iface=ens160这里把--iface=ens160加进去，将网卡名换为你实际业务网卡的名字。如果业务网卡在部分节点上名字不统一，可以改用--iface-regex按正则表达式匹配，比如：
--iface-regex=^(eth0|ens160|enp3s0)$这种方式适用于一个集群里混合了多种服务器型号、网卡命名规则不一致的场景，比写死单张网卡名要稳健得多。我在多节点集群上实测过，用--iface-regex做正则匹配能覆盖绝大多数混合硬件环境。
第二步，让修改生效。如果你之前是用kubectl apply -f kube-flannel.yml部署的，直接重新apply：
kubectl apply -f kube-flannel.yml如果是用Helm或者其他方式部署的，则通过对应的方式升级或重新渲染模板。
第三步，重启已有flannel Pod。DaemonSet的配置更新后，并非所有节点上的Pod都会自动滚动重启（取决于更新策略），最省事的做法是直接删除全部flannel Pod，让DaemonSet重新拉起来：
kubectl -n kube-system delete pod -l app=flannel第四步，清理可能残留的旧网络配置。这一步容易被忽略，但很重要。在部分节点上，kubelet的CNI配置目录/etc/cni/net.d/里可能残留之前flannel生成的配置，或者由于旧Pod未清理干净，导致新Pod启动时跳过了网络配置的重新生成。为了保险，先移除旧配置，再重启kubelet：
rm -f /etc/cni/net.d/* systemctl restart kubelet当然，如果节点上有其他CNI插件（比如Calico），删配置前要确认/etc/cni/net.d/下确实只有flannel相关文件。
3.2 方案二：通过环境变量指定网卡和IP
除了直接在DaemonSet的启动参数里写--iface，还有一种更灵活的方式：通过环境变量注入网卡信息。在kube-flannel.yml的容器定义里增加如下环境变量段：
env: - name: FLANNEL_IFACE value: "ens160"或者通过valueFrom字段从节点标签或字段引用动态取值，实现更细粒度的网络配置管理。比如给每个节点打上kubernetes.io/hostname对应的网卡标签，再通过环境变量引用它：
env: - name: FLANNEL_IFACE valueFrom: fieldRef: fieldPath: spec.nodeName不过这种方式需要配合正则匹配使用，否则直接把节点名当网卡名肯定不对。实际环境中，我更推荐把环境变量和--iface-regex结合起来用，既能在不同节点间保持差异，又不需要对每台机器单独改配置。
对于那种“节点上有多个业务网卡，不同网卡服务于不同网段Pod”的高级场景，flannel还有--iface-regex配合--public-ip的方式。前者确定接口标识，后者指定对外通告的IP地址。这部分比较进阶，普通场景用不到，但一旦涉及多网卡多网段隔离时，它能救命。
3.3 方案三：彻底重建flannel网络，防止配置残留
如果你的集群已经因为反复改配置产生了各种残留问题，而节点状态长期处于NotReady，那么“局部修”不如“全局重建”。重建前，先把集群里已有的flannel网络清理干净。
第一步，清理集群中的flannel资源：
kubectl delete -f kube-flannel.yml这会删除DaemonSet、ConfigMap和RBAC相关资源，但要注意它不会自动清除各节点上已经写入的子网环境文件和CNI配置。
第二步，登录所有节点逐一清理残留：
rm -f /run/flannel/subnet.env rm -f /var/lib/cni/flannel/* rm -f /etc/cni/net.d/10-flannel.conflist ip link delete flannel.1 2>/dev/null删除flannel.1虚拟网卡时，如果提示“Resource temporarily unavailable”，先重启kubelet，再删一次。
第三步，重新应用修正后的kube-flannel.yml。注意此时--iface参数已经是修正后的字段：
kubectl apply -f kube-flannel.yml第四步，观察恢复状态：
kubectl get nodes kubectl get pods -n kube-system -o wide | grep flannel正常状态下，所有节点在1分钟内会变为Ready，flannel Pod也不会再重启。
这套方案适合集群规模较小、业务影响可控的维护窗口期操作。如果集群已经在承载生产流量，直接重建flannel会引发所有节点的网络中断，务必先切换业务流量或选择业务低谷时段操作。
3.4 针对“多网卡名不一致”的预防性配置模板
既然标题点明了“网卡名不兼容”，这一节给出一个专门应对多服务器型号混合集群的flannel配置模板。这个模板我整理了很久，在多个生产集群里验证过，能解决大多数网卡名不一致的坑。
核心思路是：不直接写死单网卡名，而是通过--iface-regex结合变量，让每台节点自动匹配符合规则的网卡。下面是推荐的核心配置片段：
args: - --ip-masq - --kube-subnet-mgr - --iface-regex=^(ens160|enp3s0|eno1|eth0)$ - --ip-masq - --kube-subnet-mgr注意--iface-regex不要写得太宽泛，^(eth.*)$这种表达式会把虚拟网卡也匹配进来，反而更容易踩坑。匹配规则最好精确到本集群所有节点实际使用的物理网卡名，宁可多列几种，不要用模糊匹配。
另一种可选的解耦方式是用NodeSelector加自定义标签，比如给节点打network-iface=ens160，然后修改flannel DaemonSet的nodeSelector，让不同标签的节点跑不同配置的flannel副本。这种方式管理成本略高，但能实现真正的“按节点规划网络”，适合严谨的生产环境。
3.5 修改后验证网络连通性的完整步骤
配置改完，所有节点状态也Ready了，网络是不是真的通了还要验证。我强烈建议不要只看节点状态，直接跑一轮Pod间的跨节点通信测试。
准备两个Pod，分别调度到两台不同节点上，Pod内自带ping和wget工具（这里以nginx镜像为例，或者你用busybox也行）：
kubectl run test-pod-1 --image=busybox --restart=Never --command -- sleep 3600 kubectl run test-pod-2 --image=busybox --restart=Never --command -- sleep 3600然后分别查看这两个Pod被调度到哪台节点、Pod IP是什么：
kubectl get pods -o wide | grep test-pod接着进入第一个Pod，ping第二个Pod的IP：
kubectl exec -it test-pod-1 -- ping <test-pod-2-ip>如果能够Ping通，说明跨节点Pod通信链路正常。如果Ping不通，再查一下两个节点的路由表和ARP表，看看VXLAN隧道是否建立成功。这一步往往能发现“节点Ready了，但网络通信还是受限”的隐蔽问题。
对于更严谨的验证，还要测服务访问。可以在集群里创建一个LoadBalancer或NodePort类型的服务，从外部访问一下，确认从Service到Pod的流量也正常。这样才能确定flannel修复后对整个集群网络栈的恢复是完整的。
4. 常见问题与排查技巧实录
4.1 “明明没改配置，为什么重启后镜像变了？”
一种非常奇怪的故障是：某节点网络配置明明一直正常，重启后却突然变NotReady。重查发现/run/flannel/subnet.env里面写的网卡名变了。这种现象通常发生在系统版本升级或者重启后网卡名发生漂移的场景下。比如某服务器原来物理网卡是eth0，重启后由于udev规则调整，变成了enp3s0，而flannel配置里写的是eth0，于是就容易出现“找不到接口”或“接口IP不对”的情况。
解决方案有两种：一种是把配置从--iface改为--iface-regex，正则里包含多个可能的网卡名，这样无论重启后变成哪种命名，只要物理链路还在，flannel就有机会匹配成功；另一种是给网卡的MAC地址绑定固定命名，通过/etc/udev/rules.d/70-persistent-net.rules写入固定的NAME。不过这种方式在部分虚拟化环境下配置起来比较繁琐，也更难维护。
经验表明，在Kubernetes这类基础设施平台中，过度依赖固定的物理网卡名本身就是一种脆弱设计。更好的方式是把网络规划重心放在IP和路由上，用IP绑定业务，而不是用网卡名绑定业务。这一点在后续规划多集群和混合云时会尤其明显。
4.2 flannel 与 kube-proxy 的模式冲突排查
另一个高频怪问题是：flannel修好了，节点Ready了，但Service的ClusterIP访问始终不通。这种问题十有八九出在kube-proxy的转发模式与flannel的转发模式不匹配上。
kube-proxy模式有三种基础选择：userspace（基本废弃）、iptables、ipvs。flannel默认的VXLAN模式在数据路径上依赖Linux内核的ip_forward和netfilter能力，而kube-proxy使用ipvs模式时，对Linux内核版本和内核模块有额外要求。如果节点上的ip_vs内核模块没加载，kube-proxy的ipvs模式运行会失败，表现为Service的ClusterIP访问超时或拒绝连接。
排查时敲一下：
lsmod | grep ip_vs如果找不到输出，说明ip_vs模块没加载。解决方法是编辑/etc/modules-load.d/ipvs.conf加入需要加载的模块名，然后重启节点或手动modprobe加载。
flannel网络与kube-proxy模式冲突的排查优先级我排在CNI问题之后，因为一旦CNI本身有问题，kube-proxy也不会正常工作。解决顺序建议是先把Pod间直连验证通过，再测Service访问。
4.3 为什么有时“删了Pod就恢复”反而误导排障方向
有些同学在遇到网络问题时喜欢删Pod重建，发现恢复了一段时间，就认定问题解决了。但如果是flannel网卡绑定错误导致的网络问题，删除Pod重建通常只是临时掩盖了症状，根因依然存在。因为Pod重建后，容器网络基于CNI配置重新创建，此时如果CNI配置是新生成的，且新生成的配置恰好和当前节点的真实网卡匹配上了（比如flannel在重建时显式带了正确的网卡参数），那么Pod通信能恢复。
但一旦节点重启，或者flannel Pod被重新调度到别的节点，之前临时修正过的配置又可能被覆盖或者丢掉了，问题会再次暴露。排障时如果看到“删Pod就好、过一阵又复发”的循环模式，建议把思路从临时修复转向配置根因，检查DaemonSet配置是否包含了错误网卡参数，节点上的subnet.env是否被写入了异常值。
4.4 常见问题速查表
| 现象 | 直接原因 | 快速定位方法 | 解决方向 |
|---|---|---|---|
| 节点NotReady，flannel CrashLoopBackOff | flannel容器找不到可用网卡或网卡IP不匹配 | kubectl logs -n kube-system -l app=flannel --tail=50 | 增加--iface或--iface-regex指定正确网卡 |
| 节点Ready但Pod跨节点不通 | flannel访问到了虚拟网桥或管理网卡 | 查看/run/flannel/subnet.env中的FLANNEL_IFACE | 修改DaemonSet指定业务网卡，重建flannel |
| flannel日志显示“Using interface with name docker0” | flannel自动探测优先级异常 | 启动日志前几行观察接口选择 | 显式指定--iface=物理网卡名 |
| 节点重启后flannel又挂了 | 网卡命名漂移 | 对比重启前后ip link show输出 | 改用--iface-regex正则匹配，或绑定固定网卡名 |
| 跨节点心跳正常，但Service IP不通 | kube-proxy模块缺失 | 执行lsmod | grep ip_vs | 加载ip_vs相关内核模块 |
| 节点状态Ready但Pod创建极慢 | CNI配置残留或子网环境文件过期 | 查看/var/lib/cni/flannel与/run/flannel/subnet.env状态 | 清理残留配置并重启kubelet |
这张表覆盖了大多数与“网卡不兼容”直接或间接相关的问题，实际排障时拿着它对症状找方向，效率会高很多。
5. 集群网络规划层面的避坑与扩展建议
5.1 在集群初始化前就确定网卡规划
回顾整个排障过程，最本质的教训不是“怎么修flannel”，而是“在集群初始化阶段就要明确网络规范”。集群里的所有节点，尤其是网络节点，在加入集群前就应该确认好：
- 节点的业务网卡是哪个，IP是什么；
- 是否有多网卡，管理网卡和业务网卡是否分离；
- flannel的默认探测规则是否会选错网卡；
- 是否有虚拟机或容器环境下的虚拟网卡干扰。
如果初始化时就用--iface或--iface-regex把网卡钉死，后面的绝大多数“网卡不兼容”问题根本不会发生。我在给新集群做规划时，会在准备阶段就用ip link和ip addr把每台节点的网卡情况摸底一遍，然后把统一的网卡匹配规则写进部署模板。这套事前准备流程大约多花20分钟，但能省掉后期几天的排障时间。
5.2 关于VXLAN与host-gw的选择，顺带说一句
这个标题主要讲的是网卡名兼容问题，但修好网络之后很多人也会纠结：既然flannel网卡问题这么多，要不要换个CNI方案？我的建议是，flannel在中小型集群里依然是非常简单可靠的网络方案，只要网卡选择问题被正确解决，它的性能、稳定性和运维复杂度都是可接受的。相比Calico的BGP模式、Cilium的eBPF模式，flannel的综合门槛最低，排障路径也最清晰。
真到了需要更高性能、更精细网络策略或更强多租户隔离的场景，才需要考虑迁移到Calico或Cilium。而无论选哪种方案，“显式指定网卡”这项基础配置都是通用的，这点必须在初期规划时就落实。
5.3 后续扩展：从“修好”到“监控保障”
修复只是第一步，后续的保障同样重要。建议在集群里加一项基础的网络监控：定期检查各节点/run/flannel/subnet.env中FLANNEL_IFACE的IP是否与节点的业务IP一致。可以把这条检查写成一个简单的脚本，通过定时任务或Prometheus的文本采集器上报。一旦发现网卡IP异常变化，立即告警。
另外一个值得做的增强是：在集群初始化时就把Pod网段和Service网段规划成预留网段，不与任何已有网段冲突。flannel的--net参数要显式指定，避免它从etcd中获取的网段与真实环境冲突。
我个人在实际操作中的体会是：Kubernetes网络问题的排障，大多不是“不懂命令”，而是“没有把网络原理和实际环境对上号”。flannel网卡不兼容这个问题，表面是一个配置问题，实质是对节点网络拓扑认知的缺失。先把每台节点上有哪些网卡、哪张网卡该承担什么角色搞清楚，再去看flannel选没选对，排障速度和准确度都会完全不一样。这套方法论不仅适用于flannel，拿到Calico、Cilium场景下同样有效——网络插件永远只是执行者，决策者始终是你自己。
