Kubernetes网络故障排查：VMware快照恢复引发的CNI冲突

1. 问题现象与背景分析那天下午我正在测试一个Kubernetes集群的新功能。为了快速回滚测试环境我随手点下了VMware的恢复快照按钮。几秒钟后虚拟机回到了之前的干净状态但当我尝试kubectl get nodes时却看到了令人窒息的报错Unable to connect to the server: dial tcp 192.168.1.100:6443: connect: no route to host更诡异的是ifconfig显示网卡还在IP地址也正常分配但就是无法访问任何Kubernetes服务。这个看似简单的快照恢复操作竟然让整个Kubernetes网络人间蒸发了。2. 初步排查与关键发现2.1 基础网络检查首先确认基础网络连通性ping 8.8.8.8 # 成功 ping gateway # 成功 curl https://www.baidu.com # 成功这说明底层网络栈是正常的问题出在Kubernetes自身的网络组件。2.2 核心组件状态检查查看kubelet日志发现关键线索journalctl -u kubelet -n 100 --no-pager输出中反复出现networkPlugin cni failed to set up pod kube-controller-manager-node1_kube-system network: failed to set bridge addr: cni0 already has an IP address different from 10.244.0.1/242.3 CNI网络残留证据执行ip link show发现异常ip link show cni0输出显示4: cni0: BROADCAST,MULTICAST mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000 link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff这个接口处于DOWN状态且MTU值异常。3. 问题根源深度解析3.1 VMware快照的隐藏陷阱VMware的快照恢复机制存在一个鲜为人知的特点它只恢复磁盘状态而虚拟机的运行时状态包括网络配置会被保留。这就导致磁盘上的Kubernetes配置回滚到了旧版本内存中的网络命名空间、CNI配置保持现状新旧网络配置产生冲突3.2 Kubernetes网络组件冲突细节具体到CNI插件以flannel为例快照恢复后/etc/cni/net.d/中的配置回滚但宿主机的网络命名空间保留了之前的cni0网桥kubelet尝试用旧配置初始化新网桥时发生冲突3.3 关键时间线还原通过分析系统日志还原出完整的事件链快照恢复前cni0网桥IP10.244.1.1/24flannel配置子网10.244.1.0/24快照恢复后flannel配置回滚到10.244.0.0/24但旧cni0网桥10.244.1.1仍存在4. 完整解决方案与操作步骤4.1 紧急恢复方案# 1. 清理残留网络设备 sudo ip link delete cni0 sudo ip link delete flannel.1 # 2. 重启关键服务 sudo systemctl restart flanneld sudo systemctl restart kubelet # 3. 验证网络恢复 kubectl get pods -n kube-system4.2 永久解决方案创建快照前标准操作流程# 优雅关闭Kubernetes kubectl drain node-name --ignore-daemonsets sudo systemctl stop kubelet sudo systemctl stop docker # 清理网络命名空间 sudo ip link delete cni0 sudo ip link delete flannel.1使用自动化脚本管理快照#!/bin/bash # snapshot_helper.sh NODE_NAME$(hostname) kubectl drain $NODE_NAME --ignore-daemonsets systemctl stop kubelet docker ip link delete cni0 2/dev/null ip link delete flannel.1 2/dev/null vmrun snapshot /path/to/vm Snapshot_$(date %Y%m%d)5. 深度防护措施5.1 监控预警配置在Prometheus中添加以下告警规则groups: - name: k8s-network rules: - alert: CNIBridgeDown expr: count(ip_link_up{interfacecni0} 0) 0 for: 5m labels: severity: critical annotations: summary: CNI bridge is down on {{ $labels.instance }}5.2 架构级优化建议考虑使用Multus CNI实现多网络平面冗余在关键节点部署NetworkPolicy备份控制器实现定期网络配置备份# 备份网络配置 crontab -e 0 3 * * * /usr/bin/nsenter --net/var/run/netns/cni-$(cat /var/run/flannel/subnet.env | grep NETWORK | cut -d -f2 | sed s/\//-/) ip addr show /backup/network_$(date \%Y\%m\%d).log6. 同类问题扩展排查6.1 其他CNI插件处理方案CNI类型清理命令注意事项Calicocalicoctl node diags需要先收集诊断信息Weaveweave reset会丢失所有网络配置Ciliumcilium cleanup需要重启cilium-agent6.2 VMware高级配置建议在.vmx文件中添加以下参数可增强稳定性ethernet0.noRestoreState TRUE vmci0.noRestoreState TRUE7. 故障复盘与经验总结这次事故教会我几个关键经验快照不是万能药对复杂系统要理解快照的局限性网络状态具有特殊性网络命名空间不随快照恢复而重置操作顺序很重要关闭服务→清理网络→创建快照的标准流程实际测试发现在VMware ESXi 7.0环境下以下操作序列最可靠kubectl drainsystemctl stop kubelet dockerip -all netns delete等待30秒创建快照关键提示永远不要在Kubernetes节点运行时直接创建快照这相当于在飞机飞行时更换发动机