Submariner项目中OCP 4.18环境下的TCP连通性测试问题分析

问题背景

在Submariner项目中，当运行环境升级到OpenShift Container Platform (OCP) 4.18版本时，subctl verify命令的连通性测试会出现失败情况。这个问题在全局网络(globalnet)和非全局网络环境下均会出现，表现为TCP连接测试无法通过。

技术细节分析

网络路径分析

在Submariner的网络架构中，数据包的传输路径可以分为以下几个关键段：

1. 源Pod到Submariner出口(SM_egress)
2. 通过IPSec隧道传输
3. OVN-Kubernetes入口(OVN-K ingress)
4. 最终到达目标Pod

问题根源

在OCP 4.18环境中，OVN-Kubernetes做出了一个重要的底层变更：从iptables转向使用nftables来实现数据包过滤规则。这一变更导致了以下问题：

1. SNAT行为变化：在入口方向，OVN-Kubernetes会将源IP地址SNAT为CNI接口在网关上的IP地址
2. 规则冲突：虽然Submariner已经配置了iptables规则来允许这种流量，但由于OVN-Kubernetes现在使用nftables，这些规则不再生效
3. 源IP保留失败：Submariner原本期望保留源IP地址（这对于多集群网络策略抽象很重要），但在新环境下无法实现

影响范围

这个问题主要影响以下场景：

• 跨集群TCP连接测试
• 使用全局网络功能的部署
• 源Pod和目标Pod都不在网关节点上的情况

解决方案方向

从技术角度来看，可能的解决方案包括：

1. 协调SNAT规则：确保Submariner的SNAT规则能够与OVN-Kubernetes的nftables规则协同工作
2. 规则迁移：将Submariner的相关规则从iptables迁移到nftables
3. 配置调整：修改OVN-Kubernetes的配置以适应Submariner的需求

后续发展

开发团队已经向OVN-Kubernetes项目提交了相关问题报告，寻求更底层的解决方案。同时，Submariner项目也在考虑如何更好地适应不同CNI实现和不同版本OpenShift环境的变化。

这个问题凸显了在云原生网络环境中，当底层组件发生重大变更时，上层网络解决方案需要做出的适应性调整。对于使用Submariner的用户来说，在升级到OCP 4.18时需要特别注意这一兼容性问题。