Kubernetes集群网络故障排查与VMware快照恢复实践

1. 问题现象与背景分析

上周五下午，我们生产环境的Kubernetes集群突然出现大规模网络连接异常。当时第一反应是回滚到上午的VMware快照，没想到恢复后问题更加严重——所有Pod之间的网络通信完全中断，kubectl命令虽然能执行但无法获取Pod日志，整个集群陷入瘫痪状态。

这个场景特别典型：当你在虚拟化环境中运行Kubernetes，特别是使用VMware的vSphere时，快照恢复可能会引发一系列隐蔽的网络问题。我花了整整6个小时才彻底解决，过程中发现这其实是个"复合型故障"，涉及虚拟网卡MAC地址变更、kube-proxy的iptables规则失效、CNI插件状态不一致等多个层面的问题。

2. 故障排查全流程记录

2.1 第一阶段：基础网络检查

首先通过vSphere Client确认ESXi主机物理网卡状态正常，然后登录到Kubernetes节点执行基础检查：

bash复制# 检查节点IP配置
ip addr show | grep -A 5 "eth0"

# 测试节点间互通性
ping <其他节点IP>

# 检查默认路由
ip route show

发现所有节点的eth0网卡MAC地址与恢复快照前不同（关键发现！）。这是因为VMware默认配置下，恢复快照会为虚拟机生成新的MAC地址，而我们的Kubernetes网络配置中固定了旧MAC地址相关的设置。

2.2 第二阶段：Kubernetes组件诊断

检查核心组件日志发现异常：

bash复制journalctl -u kubelet --since "1 hour ago" | grep -i error

# 发现大量类似错误
networkPlugin cni failed to set up pod "nginx-deployment" network: failed to set bridge addr: "cni0" already has an IP address different from 10.244.0.1/24

这说明Flannel CNI插件检测到网络配置冲突。进一步检查发现：

1. kube-proxy的iptables规则仍指向旧的Pod CIDR
2. /var/lib/cni/目录下残留