Kube-OVN中OVN EIP/FIP外部网关配置问题分析

问题背景

在Kube-OVN v1.13版本中，用户报告了一个关于OVN EIP（External IP）和FIP（Floating IP）功能的问题。具体表现为：当配置为外部网关的两个工作节点全部宕机后，通过EIP的通信仍然能够正常工作，这与预期行为不符。

环境配置

用户环境包含3个节点：

• 1个控制平面节点（vnode-103-176）
• 2个工作节点（vnode-103-177和vnode-117-46），这两个工作节点被标记为外部网关节点

网络配置包括：

• 创建了名为external0的ProviderNetwork和对应的Vlan
• 建立了VPC1及其子网vpc1-subnet1
• 配置了OvnEip和OvnFip资源，将外部IP 10.9.101.9映射到Pod IP 192.168.0.4

预期行为

按照Kube-OVN的设计原理，当所有外部网关节点不可用时，通过EIP的通信应该中断，因为外部流量需要经由外部网关节点进行转发。

实际观察

测试发现：

1. 当两个外部网关节点被设置为NotReady状态后
2. 从集群外部仍然能够成功访问EIP 10.9.101.9
3. 在非网关节点（控制平面节点）上观察到NAT规则仍然存在
4. 流量似乎通过控制平面节点进行了转发

问题分析

经过深入调查，发现这是由于Kube-OVN中OVN FIP功能的分布式特性导致的。在Kube-OVN的实现中：

1. DNAT和SNAT规则是分布式的，会绑定到Pod所在的节点
2. 即使外部网关节点不可用，只要Pod所在节点正常运行，NAT功能仍然可以工作
3. 这种设计提供了更高的可用性，但可能与用户对"外部网关"功能的传统理解存在差异

技术细节

从OVN的配置可以看到：

• 路由器端口vpc1-external0确实配置了两个网关chassis
• 但NAT规则a023aada-62d9-4df1-882a-191dc3fd4d6f是独立存在的
• 当外部请求到达时，OVN会在Pod所在节点直接完成地址转换，而不一定经过外部网关节点

解决方案建议

对于需要严格依赖外部网关节点的场景，可以考虑以下方案：

1. 修改网络策略，确保外部流量必须经过特定网关节点
2. 使用节点选择器将Pod调度到外部网关节点上
3. 考虑使用集中式网关模式而非分布式模式

总结

这个问题揭示了Kube-OVN中OVN EIP/FIP功能实现的一个特性：NAT功能是分布式的，不严格依赖外部网关节点的可用性。这种设计提供了更高的容错能力，但需要用户在架构设计时充分理解这一特性。

对于需要严格网关控制的场景，建议重新评估网络架构设计，或考虑使用其他网络功能来满足需求。