Submariner项目中VXLAN接口通信问题的分析与解决

问题背景

在Kubernetes多集群网络解决方案Submariner的实际部署中，用户发现了一个关于VXLAN接口通信的异常现象：在同一集群内部，非网关节点上的vx-submariner接口无法正常ping通网关节点上的对应接口。这个问题不仅出现在本地kind集群测试环境中，在AWS EKS生产环境也同样存在。

现象描述

通过详细的网络抓包分析发现，当非网关节点向网关节点的vx-submariner接口发送ICMP请求时，虽然请求包能够正常发出，但始终无法收到任何回应。检查网络配置时，发现vx-submariner接口状态显示为"UP"，且FDB(转发数据库)表中包含正确的目标节点MAC地址映射。

根本原因分析

深入排查后发现，问题的根源在于Submariner的iptables规则中有一条特殊的SNAT规则：

-A SUBMARINER-POSTROUTING -s 240.0.0.0/8 -o vx-submariner -j SNAT --to-source 10.9.0.1

这条规则的设计初衷是为了支持HostNetwork Pod与远程集群的通信，它会将源IP地址转换为节点的CNI接口IP。然而，正是这条规则导致了同一集群内VXLAN接口间的通信异常。

Submariner网络架构解析

Submariner的网络架构设计有几个关键特点：

1. 跨集群通信模型：Submariner专门处理跨集群通信的出站(egress)流量，而依赖CNI处理入站(ingress)流量（在IPsec解密后）

2. 流量路径：

   • 当非网关节点上的PodA需要与另一个集群的非网关节点上的PodB通信时
   • 流量会经过：PodA → 本集群网关节点(vx-submariner接口) → IPSec隧道 → 目标集群

3. VXLAN接口角色：vx-submariner接口主要用于跨集群通信，而非同一集群内部节点间的通信

解决方案

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

1. 临时方案：直接删除导致问题的iptables规则，但这会影响HostNetwork Pod的跨集群通信能力

2. 推荐方案：理解并接受Submariner的设计原则，同一集群内节点间通信应通过CNI提供的原生网络方案，而非依赖Submariner的VXLAN接口

3. 高级定制：如需特殊场景下的VXLAN通信，可考虑自定义NetworkPolicy或修改Submariner的route-agent配置

最佳实践建议

1. 在测试Submariner功能时，应优先使用subctl verify命令进行自动化验证，而非手动ping测试

2. 理解Submariner的定位是解决跨集群通信问题，集群内部通信应交给CNI处理

3. 在需要调试网络问题时，建议同时检查以下组件：

   • 网关节点的路由表
   • IPSec隧道状态
   • 相关iptables规则链
   • CNI插件的日志信息

总结

Submariner作为专业的Kubernetes多集群网络解决方案，其设计重点在于跨集群通信而非集群内部网络。理解这一设计理念对于正确使用和排查Submariner相关问题至关重要。在实际部署中，应当遵循官方推荐的最佳实践，使用专用工具进行功能验证，避免因误解架构设计而导致不必要的配置调整。