Submariner在私有云OKD集群中连接问题的分析与解决

问题背景

在私有云环境中部署Submariner时，用户遇到了两个OKD集群之间无法建立连接的问题。具体表现为连接状态一直停留在"Connecting"状态，无法达到"Connected"状态。这种情况发生在两个位于同一公有IP后端的私有云OKD集群环境中。

环境配置

用户的环境配置如下：

• 两个OKD集群部署在私有云环境中
• 集群1：OKD 4.13运行在RHV 4.4上
• 集群2：OKD 4.14运行在OpenStack Bobcat上
• 两个集群共享相同的公有IP地址
• 使用Submariner版本v0.16.3

问题分析

通过分析Submariner网关Pod的日志，发现了以下关键信息：

1. 网关Pod无法通过UDP端口4490与对端集群通信
2. 一个集群的网关能够发送请求，但另一个集群的网关无法接收响应
3. NAT发现过程超时，导致连接无法建立

具体表现为：

• 集群1(192.168.30.16)无法连接到集群2(192.168.60.83和181.117.10.119)的4490端口
• 集群2能够发送请求到集群1的4490端口并收到响应

根本原因

问题的根本原因在于网络访问控制配置不当。虽然用户已经使用了subctl cloud prepare命令为OpenStack环境创建了安全组，但这些安全组的规则可能存在以下问题：

1. 没有正确允许必要的UDP端口通信
2. 规则可能只针对特定端口而非Submariner所需的所有端口
3. 安全组可能没有正确应用到所有相关节点

解决方案

用户通过以下步骤解决了问题：

1. 创建新的安全组，允许所有UDP端口通信
2. 移除由subctl cloud prepare rhos自动生成的安全组
3. 将新安全组应用到所有网关节点

这种方法确保了Submariner所需的UDP通信能够正常进行，特别是在NAT穿越和隧道建立过程中。

最佳实践建议

对于类似环境的Submariner部署，建议采取以下措施：

1. 全面检查访问控制规则：确保所有必要的UDP端口(特别是4500和4490)都已开放
2. 验证安全组应用：确认安全组已正确应用到所有网关节点
3. 使用诊断工具：定期运行subctl diagnose all和subctl gather命令检查连接状态
4. 考虑网络拓扑：在共享公有IP的环境中，可能需要额外的NAT配置或端口转发
5. 日志监控：密切关注网关Pod日志中的NAT发现和连接建立信息

总结

在私有云环境中部署Submariner时，网络配置特别是访问控制规则的正确设置至关重要。通过仔细分析日志和系统性地排查网络连接问题，可以有效解决集群间的连接问题。本例展示了如何通过调整安全组配置来解决Submariner连接问题，为类似环境的部署提供了有价值的参考。