Flannel网络插件导致Kubernetes节点间通信故障的排查与解决

问题现象

在基于Flannel 0.26.4的Kubernetes 1.29.14集群中，当工作节点加入集群后，出现以下异常情况：

1. 节点间ICMP(ping)通信失败，返回"Destination Port Unreachable"错误
2. kubectl命令无法连接API Server，报错"connection refused"
3. Flannel组件日志显示无法通过inClusterConfig方式获取Pod信息

根本原因分析

通过现象可以判断这是典型的Kubernetes网络插件初始化失败导致的通信问题。具体表现为：

1. Flannel网络初始化失败
   日志显示Flannel无法通过in-cluster方式访问Kubernetes API（10.96.0.1:443），这表明控制平面网络尚未就绪。Flannel需要先获取集群网络配置才能建立Overlay网络。

2. 节点间基础网络中断
   节点加入集群后原本正常的ICMP通信中断，说明CNI插件可能修改了主机的网络规则或路由表，但未能正确建立替代通信路径。

3. API Server不可达
   工作节点无法连接6443端口，表明kube-proxy可能未正确运行或网络策略阻止了通信。

解决方案

经过深入排查，最终通过以下步骤解决问题：

1. 完全清理集群配置
   在所有节点执行kubeadm reset清除残余配置，确保干净的安装环境。

2. 重新初始化控制平面
   在master节点使用kubeadm init时，确保指定了正确的Pod网络CIDR：

   kubeadm init --pod-network-cidr=10.244.0.0/16
   

3. 按顺序部署网络组件
   先确保控制平面完全就绪后再安装Flannel：

   kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
   

4. 验证网络状态
   使用以下命令确认网络组件正常运行：

   kubectl get pods -n kube-system
   ip route show
   

经验总结

1. Kubernetes网络问题通常表现为"多米诺骨牌效应"，一个组件失败会引发连锁反应
2. Flannel等CNI插件对初始化顺序敏感，必须等待控制平面完全就绪后再部署
3. 在裸机环境中要特别注意防火墙规则，确保以下通信畅通：
   • 控制节点与工作节点间的6443端口
   • 节点间的Overlay网络通信（通常是8472/UDP用于Flannel VXLAN）
4. 当网络出现问题时，建议按以下顺序排查：
   • 基础网络连通性（ping）
   • 服务端口可达性（telnet/nc）
   • 网络插件日志（journalctl -u kubelet）
   • IP路由表和iptables规则

最佳实践建议

1. 在生产环境中建议使用--config文件进行kubeadm初始化，明确所有网络参数
2. 考虑使用网络诊断工具如Weave Scope实时监控集群网络状态
3. 对于关键业务集群，建议在部署CNI插件前先备份网络配置：

   iptables-save > iptables.bak
   ip route show > routes.bak
   

4. 定期检查CNI插件与Kubernetes版本的兼容性矩阵，避免版本冲突

通过系统化的排查和规范的部署流程，可以有效避免类似网络问题的发生。