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

背景概述

在Kubernetes多集群环境中，Submariner作为跨集群网络解决方案，其核心功能是实现不同Kubernetes集群间的Pod直接通信。本文记录了一个典型的Submariner v0.16.3在OCP 4.12-4.14环境中的网络连通性问题，尽管基础诊断工具显示状态正常，但实际跨集群Pod通信失败的情况。

环境配置

• 集群拓扑：两个OpenShift集群组成
  • 站点1：OCP 4.13升级至4.14中
  • 站点2：稳定运行OCP 4.12
• 网络组件：均采用OVNKubernetes CNI插件
• Submariner版本：v0.16.3标准部署（非Globalnet模式）

故障现象

通过常规检查工具subctl show all和subctl diagnose all显示所有组件状态正常：

• 网关连接状态显示"connected"
• 各组件Pod均处于Running状态
• 网络CIDR无冲突
• OVN版本兼容性验证通过

但实际测试中，跨集群Pod间的ping测试出现100%丢包，表明数据平面通信存在异常。

深度诊断方法

1. 基础状态验证
   使用subctl show connections确认隧道建立情况，特别注意RTT延迟值（本例中显示700-800μs，属正常范围）。

2. 增强诊断工具
   推荐使用subctl verify命令执行端到端测试，该命令会：

   • 自动部署测试Pod
   • 验证跨集群TCP/UDP连通性
   • 检查服务发现功能
   • 测试跨集群Service IP通信

3. 数据平面检查
   在网关节点上通过ip xfrm state检查IPsec安全关联(SA)，使用tcpdump抓取VXLAN封装流量，验证数据包是否正常穿越集群边界。

根本原因分析

虽然最终通过重新安装Submariner解决问题，但典型原因可能包括：

1. OVN网络策略冲突：升级过程中残留的网络策略规则可能阻断跨集群流量
2. IPsec配置漂移：集群升级导致节点证书或隧道密钥不一致
3. 路由表异常：submariner-routeagent未能正确注入跨集群路由

运维建议

1. 预防性措施

   • 在集群升级前执行subctl backup保存关键配置
   • 使用subctl verify建立基线测试用例

2. 故障排查流程

   # 1. 检查实时连接状态
   subctl show connections --detailed
   
   # 2. 检查网关节点转发规则
   oc debug node/<gateway-node> -- chroot /host ip route show table 150
   
   # 3. 验证数据包路径
   kubectl run test-pod --image=nicolaka/netshoot -- ping <remote-pod-ip>
   

3. 监控配置
   建议部署以下监控指标：

   • submariner_connection_status：隧道连接状态
   • submariner_tx_bytes：跨集群传输字节数
   • submariner_rx_bytes：跨集群接收字节数

经验总结

Submariner的基础状态检查工具虽然能发现大部分配置问题，但对于数据平面故障需要结合更深入的网络诊断。运维团队应当：

• 建立定期的端到端连通性测试机制
• 在集群升级前后执行完整验证
• 掌握底层网络工具链的使用方法

通过本次故障处理，我们认识到在云原生网络方案中，声明式的状态检查与实际数据平面行为可能存在差异，需要建立多维度的监控验证体系。