VMware快照恢复导致Kubernetes网络故障排查与修复
1. 问题现象与背景分析上周五晚上10点我在VMware Workstation 17上恢复了一个Kubernetes集群的快照后突然发现所有Pod之间的网络通信都中断了。这个集群原本运行着公司的微服务系统包含12个节点3个master9个worker使用Calico 3.24作为CNI插件。快照恢复前系统完全正常但恢复后出现以下典型症状kubectl get nodes显示所有节点状态为ReadyPod能够正常启动但跨节点无法ping通节点间的calico-node容器不断报错BGP peer not established使用tcpdump抓包发现ARP请求无响应这种情况在VMware环境中其实相当常见。当虚拟机通过快照回滚时虚拟硬件配置特别是网络适配器可能会发生微妙变化而Kubernetes网络插件往往依赖于稳定的网络标识。根据我的经验这类问题90%与以下三个因素有关虚拟机MAC地址变化导致网络标识混乱Calico等CNI插件存储的旧网络状态与新环境冲突VMware虚拟交换机端口组配置重置2. 关键排查步骤与工具使用2.1 基础网络连通性检查首先需要确认底层网络是否正常。在任意节点执行# 检查基础网络配置 ip addr show | grep -A 10 ens192 # 替换为你的实际网卡名 route -n # 测试节点间连通性 ping -c 4 其他节点IP traceroute 其他节点IP # 检查ARP表 arp -an在我的案例中发现节点间能ping通网关但无法互通且ARP表中缺少其他节点的记录。这提示二层连通性问题。2.2 Calico组件诊断接下来重点检查Calico组件的状态# 查看Calico Pod状态 kubectl get pods -n kube-system -l k8s-appcalico-node # 检查BGP对等体状态 kubectl exec -ti calico_pod -n kube-system -- birdcl show protocols # 查看IP地址分配情况 kubectl get ipamblocks -o yaml发现所有节点的BGP状态都是Active但从未建立连接。更可疑的是calico-node日志显示2023-08-20 22:15:47.123 [ERROR][8] int_dataplane.go 1023: Failed to query VXLAN device errorLink not found这说明Calico尝试访问的网络设备已不存在。2.3 VMware网络配置验证登录vSphere检查虚拟机的网络配置确认所有VM使用相同的端口组检查虚拟交换机的安全设置必须允许伪传输和MAC地址更改对比快照前后的VMX文件- ethernet0.generatedAddress 00:0c:29:12:34:56 ethernet0.generatedAddress 00:0c:29:ab:cd:ef果然发现MAC地址被重新生成。这是VMware快照恢复时的默认行为。3. 根本原因与解决方案3.1 问题根因分析综合以上现象问题链如下快照恢复 → VMware生成新MAC地址物理交换机保留旧MAC-port映射 → 网络流量被错误过滤Calico保留旧接口配置 → 无法建立BGP连接IPAM模块记录旧分配信息 → 新Pod获取冲突IP3.2 分步修复方案步骤1重置VMware网络标识# 关闭虚拟机 vmware-cmd vmx_path stop hard # 编辑.vmx文件 sed -i /ethernet0.generatedAddress/d /path/to/vm.vmx # 启动虚拟机 vmware-cmd vmx_path start这会让VMware在下次启动时重新生成MAC地址。步骤2清理Calico旧数据# 删除Calico节点配置 kubectl delete -n kube-system pods -l k8s-appcalico-node # 清理etcd中的网络数据如果使用etcd存储 etcdctl del --prefix /calico步骤3重建网络插件# 重新应用Calico清单 kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.24.1/manifests/calico.yaml # 强制CNI重新配置 kubectl delete pods --all -n kube-system4. 预防措施与经验总结4.1 VMware最佳实践固定MAC地址在.vmx文件中添加ethernet0.addressType static ethernet0.address 00:50:56:XX:XX:XX禁用网络过滤在端口组设置中启用伪传输MAC地址更改混杂模式4.2 Kubernetes配置建议# calico-config ConfigMap中的关键参数 apiVersion: v1 kind: ConfigMap metadata: name: calico-config data: veth_mtu: 1440 # 启用自动检测 ip_autodetection_method: can-reach8.8.8.84.3 实际踩坑心得快照前检查清单记录所有节点的MAC地址备份Calico CRD资源kubectl get bgppeers -o yaml bgppeers.yaml恢复后必做验证# 检查IP冲突 kubectl get pods -o wide | awk {print $6} | sort | uniq -d # 验证网络策略 kubectl get networkpolicies --all-namespaces最有效的排错命令# 实时查看Calico事件 kubectl get events -n kube-system -w # 深度诊断工具 calicoctl node status这次故障让我深刻认识到在虚拟化环境中网络标识的持久性比想象中更重要。现在我的团队在每次重大操作前都会执行完整的网络配置备份这个习惯已经帮我们避免了多次类似事故。