Submariner项目在OCP 4.18环境下的TCP连通性故障分析与解决方案

背景

Submariner是一个开源的Kubernetes网络插件，用于实现跨集群的网络连通性。在最新测试中发现，当运行在OpenShift Container Platform (OCP) 4.18环境中时，Submariner的TCP连通性测试会出现失败情况。这个问题既出现在全局网络(Globalnet)模式下，也出现在非全局网络模式下。

问题现象

当在两个集群间部署Submariner（至少一个集群运行OCP 4.18）并执行连通性验证时，测试会失败。具体表现为：

1. 监听端Pod能够接收到连接请求
2. 数据能够从连接端Pod传输到监听端Pod
3. 但监听端输出的日志中无法识别连接端Pod的全局IP地址

技术分析

数据流路径

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

1. 源Pod → Submariner出口网关
2. Submariner出口网关 → IPSec隧道 → OVN-Kubernetes入口网关
3. OVN-Kubernetes入口网关 → 目标Pod

问题根源

经过深入分析，发现问题出在OCP 4.18中OVN-Kubernetes的网络包处理机制发生了变化：

1. SNAT行为变化：在入口段(OVN-K入口 → 目标Pod)，OVN-Kubernetes会对源IP执行SNAT，将其转换为CNI接口IP

2. 防火墙规则变更：OCP 4.18中OVN-Kubernetes开始使用nftables替代iptables作为包过滤机制。虽然Submariner配置了iptables规则来允许这种流量，但nftables的SNAT规则仍然会生效

3. IP保留失效：Submariner原本的设计意图是保留源IP（可用于多集群网络策略），但由于上述SNAT行为，导致源IP信息丢失

解决方案

短期方案

1. 修改Submariner的测试验证逻辑，使其能够识别和处理经过SNAT后的IP地址
2. 在OVN-Kubernetes配置中添加例外规则，避免对Submariner流量执行SNAT

长期方案

1. 与OVN-Kubernetes社区合作，提供更细粒度的SNAT控制机制
2. 增强Submariner对nftables的支持，确保规则能够正确应用
3. 考虑实现端到端的IP保留机制，不依赖底层CNI的默认行为

影响评估

该问题主要影响以下场景：

1. 需要精确识别源IP的多集群应用
2. 依赖IP白名单的安全策略
3. 网络流量审计和监控功能

对于大多数仅需基本连通性的应用场景，虽然测试会失败，但实际通信仍然可以正常工作。

最佳实践建议

对于使用OCP 4.18及更高版本的用户：

1. 在部署Submariner前，确认OVN-Kubernetes的版本和配置
2. 如果不需要源IP保留功能，可以接受当前的SNAT行为
3. 关注Submariner的版本更新，及时应用相关修复

总结

Submariner在OCP 4.18环境下遇到的TCP连通性问题，本质上是由于底层网络组件行为变更导致的兼容性问题。通过深入理解数据流路径和包处理机制，可以找到有效的解决方案。这个问题也提醒我们，在多集群网络方案中，需要更加关注底层平台的变化可能带来的影响。