Submariner跨集群网络连接故障排查与解决方案

问题背景

在Kubernetes多集群环境中，Submariner是一个重要的网络插件，用于实现跨集群的直接Pod间通信。本文记录了一个典型的Submariner安装和连接故障案例，涉及两个OpenShift 4.16.38集群间的连接问题。

故障现象

用户在尝试在两个OpenShift集群(分别称为site1和site2)之间部署Submariner时遇到了以下问题：

1. 初始安装时，subctl deploy-broker命令长时间无响应
2. 诊断命令subctl diagnose firewall inter-cluster出现goroutine错误
3. 连接建立后不稳定，频繁断开
4. 网关Pod日志显示Endpoint资源被异常删除

关键错误分析

从网关Pod日志中发现以下关键错误信息：

2025-04-30T13:35:16.737Z DBG Tunnel controller successfully removed Endpoint cable submariner-cable-site1-172-20-200-26 from the engine

这表明site1的Endpoint资源被意外删除，导致跨集群连接无法建立。正常情况下，网关Pod启动后会创建本地Endpoint并保持其存在。

根本原因

经过深入分析，发现问题的根本原因包括：

1. 资源冲突：在site1集群中，存在多个未完成的uninstall Pod（如submariner-gateway-uninstall-*），这些Pod干扰了新安装的正常运行。

2. 异常删除操作：日志显示Submariner资源被删除后又快速重建，导致新旧资源冲突：

   2025-04-30T13:35:12.312Z INF Submariner is being deleted
   2025-04-30T13:35:13.259Z DBG Reconciling Submariner
   

3. Endpoint资源异常：正常情况下每个集群应只有一个Endpoint，但诊断显示site2有三个Endpoint，site1有两个，表明资源管理出现混乱。

解决方案

1. 清理残留资源：

   • 删除所有残留的uninstall Pod和DaemonSet
   • 确保submariner-k8s-broker命名空间只存在于一个集群中

2. 完整重新安装：

   # 卸载Submariner
   subctl uninstall --kubeconfig <kubeconfig>
   
   # 确认所有资源已清理后重新安装
   subctl deploy-broker --kubeconfig broker-cluster-kubeconfig
   subctl join --kubeconfig cluster1-kubeconfig broker-info.subm
   subctl join --kubeconfig cluster2-kubeconfig broker-info.subm
   

3. 验证安装：

   • 使用subctl show all检查连接状态
   • 使用subctl diagnose all进行全面诊断

经验总结

1. 安装前检查：在安装Submariner前，应确保集群中没有残留的Submariner资源。

2. 操作间隔：执行卸载操作后，应等待足够时间让清理过程完成，再进行新安装。

3. 监控机制：建立对Submariner连接状态的持续监控，及时发现连接异常。

4. 版本兼容性：确认Submariner版本与OpenShift版本的兼容性，本例中使用的是Submariner 0.19.2和OCP 4.16.38。

通过系统性的排查和规范的安装流程，最终成功建立了稳定的跨集群网络连接。此案例展示了在复杂环境中部署网络插件时可能遇到的问题及解决方法，为类似场景提供了有价值的参考。