Submariner跨集群服务通信问题排查与解决指南

问题背景

在使用Submariner连接两个Kubernetes集群时，用户遇到了跨集群服务无法访问的问题。两个集群部署在相同的AWS VPC网络中，使用kubeadm部署，并采用Calico作为CNI插件。集群配置如下：

• 集群1:

  • Pod CIDR: 10.241.0.0/16
  • Service CIDR: 10.111.0.0/16

• 集群2:

  • Pod CIDR: 10.242.0.0/16
  • Service CIDR: 10.112.0.0/16

问题现象

用户按照官方文档部署Submariner后，发现以下异常现象：

1. 使用subctl show connections命令检查时，只显示一个方向的连接，而不是预期的双向连接
2. 跨集群服务无法解析和访问
3. 服务导出后没有创建相应的ServiceImport资源

排查过程

1. 基础环境检查

首先确认了两个集群的网络配置没有重叠，这是Submariner非Globalnet模式工作的前提条件。Calico的IP池配置也正确设置了对应集群的CIDR范围。

2. Submariner组件状态检查

使用subctl show all命令检查Submariner各组件的部署状态，确认网关、路由代理等核心组件都已正常运行。

3. 连接性测试

执行subctl verify命令进行连接性测试时，发现服务发现功能存在问题。测试结果显示跨集群的TCP连接可以建立，但服务发现相关的验证失败。

4. 日志分析

通过subctl gather收集的日志显示：

• IPSec隧道已成功建立
• 路由信息已正确传播
• 但服务发现组件(lighthouse)存在异常日志

5. 资源检查

检查发现ServiceExport资源创建后，没有自动生成对应的ServiceImport资源，这是导致服务无法跨集群发现的关键原因。

解决方案

经过深入排查，发现问题可能出在服务发现组件的配置上。用户尝试启用Globalnet功能后，问题得到解决。虽然在此场景中Globalnet并非必需（因为CIDR没有重叠），但它可能绕过了某些配置问题。

对于非Globalnet模式的正确配置，建议：

1. 确保Calico的IPPool配置正确，特别是跨集群CIDR的配置
2. 检查服务发现组件的日志是否有异常
3. 验证ServiceExport控制器是否正常工作
4. 确认kube-proxy或CNI插件没有阻止跨集群流量

经验总结

1. 即使CIDR不重叠，某些网络插件配置也可能影响Submariner的正常工作
2. Globalnet模式可以作为排查问题的备选方案
3. 完整的日志收集(subctl gather)对问题诊断至关重要
4. 服务发现问题的核心检查点包括ServiceImport资源的生成和lighthouse组件的状态

后续建议

对于遇到类似问题的用户，建议：

1. 按照官方文档逐步验证每个组件的功能
2. 优先解决非Globalnet模式的问题，以保持最简单的配置
3. 在社区寻求帮助时，提供完整的subctl gather输出和详细的配置信息
4. 考虑使用subctl diagnose命令进行自动化问题检测

通过系统性的排查和验证，大多数Submariner的跨集群通信问题都可以找到解决方案。