Kube-Router中IPVS与网络策略控制器间的竞态条件问题分析

问题背景

在Kube-Router网络插件中，当同时启用IPVS服务和网络策略功能时，存在一个微妙的竞态条件问题。该问题会导致服务ExternalIP在ipset集合中被意外移除，进而造成网络流量被错误拒绝。

问题现象

运维人员观察到，当以下条件同时满足时会出现网络连接问题：

1. 服务配置了ExternalIP
2. 新Pod被调度到节点上
3. 网络策略控制器与IPVS服务控制器同时运行

具体表现为：IPVS服务控制器将ExternalIP添加到kube-router-svip-prt ipset集合后，网络策略控制器随后执行同步时，该IP会从集合中消失，导致流量被iptables规则拒绝。

根本原因分析

经过深入代码分析，发现问题根源在于两个控制器间的状态同步机制：

1. IPVS服务控制器在syncIpvsFirewall中：

   • 获取ipset互斥锁
   • 将服务ExternalIP添加到内存中的ipSetHandlers映射
   • 更新实际的ipset集合

2. 网络策略控制器在syncNetworkPolicyChains中：

   • 基于内存中的ipSetHandlers状态刷新ipset
   • 由于它不知道IPVS控制器添加的ExternalIP，导致这些IP被移除
   • 最终在cleanupStaleIPSets中才保存当前状态

这种设计导致了"后写覆盖"问题 - 网络策略控制器使用过时的内存状态覆盖了IPVS控制器刚刚写入的实际ipset内容。

解决方案

修复方案的核心思想是：在每次ipset操作前强制同步磁盘状态到内存。具体实现为：

1. 在网络策略控制器的syncNetworkPolicyChains开始时：

   for _, ipset := range npc.ipSetHandlers {
       err := ipset.Save()
       if err != nil {
           klog.Warningf("Error saving ipset rules...")
       }
   }
   

2. 类似地，在IPVS服务控制器的syncIpvsFirewall中也添加相同逻辑

这个修改确保了：

• 每次构建新规则前都从磁盘加载最新状态
• 消除了内存状态与实际ipset内容不一致的可能性
• 保持了原有的互斥锁机制，确保线程安全

实施效果

经过实际部署验证，该修复方案能够：

• 彻底解决ExternalIP被意外移除的问题
• 保持网络策略的正常功能
• 对系统性能影响极小
• 提高整个系统的状态一致性

最佳实践建议

对于使用Kube-Router的生产环境，特别是同时启用IPVS和网络策略的场景，建议：

1. 定期检查kube-router-svip-prt ipset集合内容
2. 监控关键服务的网络连通性
3. 考虑升级到包含此修复的版本
4. 在变更网络策略或服务配置后，验证ipset集合完整性

这种类型的竞态条件问题在复杂网络系统中并不罕见，该案例也为处理类似的多控制器协调问题提供了很好的参考模式。