Harvester项目中Kube-OVN与Canal CNI的iptables PREROUTING链冲突分析与解决方案

在Kubernetes网络生态中，多CNI插件的共存往往会带来意料之外的网络规则冲突。本文将以Harvester项目（基于Rancher的云原生超融合基础设施）为例，深入分析Kube-OVN网络插件与Canal/Calico CNI在iptables PREROUTING链上的规则冲突问题，并探讨其技术解决方案。

---

问题现象与背景

当在Harvester集群（特别是v1.5.0版本）部署Kube-OVN v1.13.x时，运维人员观察到以下异常现象：

1. 规则混乱：节点上iptables的PREROUTING链出现规则顺序频繁变动、规则重复插入等问题。初始正常规则应包含：

   -P PREROUTING ACCEPT
   -A PREROUTING -j cali-PREROUTING  # Calico规则
   -A PREROUTING -j KUBE-SERVICES    # kube-proxy规则
   -A PREROUTING -j CNI-HOSTPORT-DNAT
   

   但实际会出现大量重复的-j OVN-PREROUTING规则。

2. 组件异常：kube-ovn-cni Pod持续处于非就绪状态，日志显示其不断尝试删除和重建iptables规则：

   delete iptables rule by pos 3...
   failed to delete iptables PREROUTING rule: iptables: Index of deletion too big.
   

3. 功能影响：推测该冲突会影响Kube-OVN的负载均衡功能、Kubernetes Service的正常工作以及hostPort功能。

---

技术根因分析

通过深入排查，发现问题的本质在于规则插入策略的竞争：

1. 优先级竞争：
   Kube-OVN和Calico都试图将自己的规则插入到PREROUTING链的顶部位置（position 1），而kube-proxy的规则需要保持较低优先级。

2. 规则管理缺陷：
   Kube-OVN的规则协调逻辑存在两个关键缺陷：

   • 删除规则时依赖动态索引号，但索引会在删除操作后发生变化
   • 缺乏对现有规则的兼容性检查，导致重复插入

3. 设计局限：
   当前Kube-OVN的架构假设其作为唯一CNI运行，未充分考虑与Canal/Calico共存的场景。

---

解决方案设计

核心原则

1. 规则优先级保障：确保OVN规则优先级高于kube-proxy但低于Calico
2. 原子性操作：采用规则指纹比对而非索引号定位
3. 幂等性处理：避免规则重复插入

具体实现

上游Kube-OVN项目通过以下改进解决问题：

1. 规则匹配优化：
   改用iptables-save获取完整规则快照，通过注释内容（comment）精准定位规则，而非依赖易变的索引号。

2. 位置策略调整：
   不再强制插入链首，而是：

   • 保留Calico规则在顶部
   • 将OVN规则插入到Calico之后、kube-proxy之前

3. 错误处理增强：
   对iptables操作添加重试机制和状态校验，避免因临时失败导致规则不一致。

---

验证与效果

该方案经测试验证具有以下改进：

1. 规则稳定性：
   PREROUTING链保持预期结构：

   -P PREROUTING ACCEPT
   -A PREROUTING -j cali-PREROUTING      # Calico（保持首位）
   -A PREROUTING -j OVN-PREROUTING       # Kube-OVN（固定第二位）
   -A PREROUTING -j KUBE-SERVICES        # kube-proxy
   -A PREROUTING -j CNI-HOSTPORT-DNAT
   

2. 组件健康度：
   kube-ovn-cni Pod可正常进入就绪状态，日志中不再出现规则操作错误。

3. 功能兼容性：
   负载均衡、Service和hostPort功能测试通过，与Calico网络策略无冲突。

---

经验总结

该案例为CNI插件开发提供了重要启示：

1. 多CNI兼容性应作为基础设计考量，特别是对iptables等共享资源的管理
2. 规则管理策略需采用声明式而非命令式，通过唯一标识（如注释）定位规则
3. 位置敏感性规则应提供可配置的插入策略，而非硬编码位置

该修复已随Kube-OVN v1.13.13版本发布，为Harvester等需要多CNI共存的场景提供了稳定支持。未来建议CNI开发者通过Kubernetes Network Plumbing Working Group等渠道建立更完善的CNI交互规范。