kube-vip ARP模式与Leader选举配置不当导致网络故障分析

问题现象

在使用kube-vip 0.7.0及以上版本时，用户报告了严重的网络连接问题。具体表现为：

1. 节点eth0接口IP地址丢失
2. 整个集群内部连接中断
3. etcd持续尝试选举新leader
4. 网络性能显著下降
5. 问题甚至影响到同一网络中的其他非k3s设备(如手机Wi-Fi)

环境信息

• 操作系统: Ubuntu Server 20.04
• Kubernetes版本: v1.28.3至v1.29.0
• kube-vip版本: 0.7.0至0.7.2(0.6.4版本工作正常)

根本原因分析

经过深入排查，发现问题源于kube-vip配置中的两个关键参数组合：

1. ARP模式启用(vip_arp: "true")
2. 同时启用了控制平面和服务负载均衡(cp_enable和svc_enable同时为true)
3. Leader选举禁用(vip_leaderelection: "false")

这种配置组合会导致每个节点都尝试宣告相同的VIP地址，而ARP协议无法正确处理这种情况，从而引发网络冲突。

技术原理

在ARP模式下，kube-vip使用ARP协议来宣告虚拟IP地址。当禁用Leader选举并同时启用控制平面和服务负载均衡功能时：

1. 每个节点都会独立地尝试宣告相同的VIP地址
2. ARP协议无法协调多个节点对同一IP地址的宣告
3. 网络交换机/路由器会收到冲突的ARP信息
4. 导致网络设备无法正确路由流量
5. 最终结果是网络连接中断和性能下降

解决方案

针对此问题，有以下几种解决方案：

方案一：启用Leader选举

vip_leaderelection: "true"

启用Leader选举后，只有一个节点会负责宣告VIP地址，避免了ARP冲突。

方案二：分离控制平面和服务负载均衡功能

建议将控制平面和服务负载均衡功能分开部署，使用不同的DaemonSet实例。

方案三：回退到稳定版本

如果问题持续存在，可以暂时回退到已知稳定的0.6.4版本。

最佳实践建议

1. 在ARP模式下，避免同时启用cp_enable和svc_enable
2. 如果必须同时使用两种功能，务必启用Leader选举
3. 生产环境中建议使用BGP模式而非ARP模式
4. 升级前充分测试新版本配置
5. 监控网络ARP表状态，及时发现异常

总结

kube-vip是一个强大的Kubernetes负载均衡和VIP管理工具，但需要正确配置才能发挥其作用。特别是在ARP模式下，需要特别注意Leader选举和功能组合的配置，避免引发网络冲突。通过合理配置和遵循最佳实践，可以确保集群网络稳定可靠。