不同节点pod ip无法ping通，说明flannel overlay网络异常，需逐层排查：先验证节点间主机ip连通性及udp 8472端口开放，再确认flannel子网配置与pod-network-cidr一致、flannel.1接口up且有ip，接着检查跨节点路由是否同步、arp/fdb表项是否正常，最后通过日志和抓包定位隧道中断点。
当Kubernetes集群中不同节点上的Pod IP无法互相ping通，说明Flannel构建的Overlay网络未正常打通，跨主机容器通信链路中断，必须逐层验证底层网络、Flannel配置、路由与隧道状态。
确认节点间基础网络连通性
先排除物理或云平台层面的阻断：在master节点执行ping 192.168.79.138（替换为目标node真实IP），若不通，直接卡在第一步。
接着检查Flannel依赖的UDP端口是否放行：nc -zv 192.168.79.138 8472。VXLAN模式下，【内核必须通过UDP 8472端口封装和转发数据包】，该端口被云平台安全组或本地防火墙拦截是腾讯云轻量应用服务器最常见原因。
Ubuntu系统运行sudo ufw allow 8472/udp；CentOS/RHEL运行sudo firewall-cmd --permanent --add-port=8472/udp && sudo firewall-cmd --reload。
验证Flannel子网分配与接口状态
执行kubectl -n kube-system get configmap kube-flannel-cfg -o jsonpath='{.data.net-conf\.json}' | jq '.Network'，确认输出值（如"10.244.0.0/16"）与kubeadm init时指定的--pod-network-cidr完全一致。不一致会导致flanneld拒绝启动或分配错误subnet。
登录任一node，运行ip addr show flannel.1。如果无输出或状态为DOWN，说明VXLAN设备未创建成功——此时需删除对应flannel Pod触发重建：kubectl -n kube-system delete pod -l app=flannel。
等待新Pod Running后再次检查，flannel.1必须存在且含合法IPv4地址（如10.244.1.0/32）。
检查并修复跨节点路由表
第一步：在node01上执行ip route show | grep flannel，观察是否有指向其他节点Pod网段的via条目，例如10.244.2.0/24 via 10.244.2.0 dev flannel.1。缺失即表示路由未同步。
第二步：若路由缺失，立即查看flanneld日志：kubectl -n kube-system logs -l app=flannel --tail=50。常见报错如failed to acquire lease或etcd server unavailable，说明flanneld无法读取etcd中其他节点的subnet注册信息。
第三步：临时绕过故障，手动添加缺失路由（仅调试用）：ip route add 10.244.2.0/24 via 192.168.79.139 dev eth0（注意：目标IP必须是node02的主机IP，不是flannel.1地址；dev名需替换成实际主网卡名，如ens33）。
排查ARP与FDB隧道映射
方法一：在源节点执行arp -n | grep 10.244.2.10（目标Pod IP），若无结果，说明VXLAN隧道未学习到对端VTEP MAC。此时需确认flannel.1接口UP且有IP，再检查bridge fdb show | grep 10.244.2.0是否含有效MAC+IP映射。
方法二：抓包定位隧道中断点：tcpdump -i flannel.1 icmp and host 10.244.2.10 -nn。若在源节点收不到ICMP请求，在目标节点也收不到，说明UDP封装包根本未发出——回到第一步重检8472端口连通性。
注意：若bridge fdb show中某条目MAC为00:00:00:00:00:00，代表FDB未正确填充，大概率因etcd中subnet信息损坏或flanneld版本与K8s不兼容。
