Submariner跨集群服务访问问题排查与解决方案

背景概述

在使用Submariner构建多Kubernetes集群网络时，用户遇到一个典型的服务发现异常问题：在集群c2中无法通过短域名whereami-cs.sample.svc.clusterset.local访问集群c1导出的服务，但使用带集群ID的完整域名c1.whereami-cs.sample.svc.clusterset.local却能正常访问。这种现象直接影响了跨集群服务发现的便捷性。

环境配置

• Kubernetes发行版：k3s v1.27.2
• Submariner版本：v0.13.0
• 网络拓扑：包含broker集群、c1和c2三个集群，均采用单master节点架构
• 测试服务：使用whereami应用作为测试服务，通过ServiceExport机制暴露服务

问题现象深度分析

1. DNS解析差异
   通过nslookup工具验证发现：

   • 短域名查询返回NXDOMAIN（域名不存在）
   • 带集群ID的长域名能正确解析到目标集群的服务IP

2. 网络连通性验证
   虽然DNS解析异常，但实际网络层连通性正常，这体现在：

   • 使用长域名时服务可访问
   • subctl diagnose命令显示跨集群连接正常

3. 客户端环境干扰
   最终发现测试环境中运行的某些网络优化软件的TUN模式会劫持Pod的网络流量，导致：

   • Pod内无法解析任何外部域名
   • 主机网络正常的现象掩盖了这个问题

解决方案

1. 关闭干扰软件
   停用相关网络优化软件的TUN模式后，Pod网络恢复正常：

   • 短域名解析立即生效
   • 服务访问完全正常

2. 版本升级建议
   虽然本案例中问题与Submariner版本无关，但建议升级到更新的0.18版本：

   • 包含更多稳定性改进
   • 提供更完善的诊断工具

经验总结

1. 网络诊断方法论
   当遇到跨集群服务发现问题时，建议按以下顺序排查：

   • 验证基础网络连通性（subctl diagnose）
   • 检查DNS解析（nslookup/dig）
   • 排除本地网络环境干扰

2. 测试环境净化
   在进行网络插件测试时，应当：

   • 保持测试环境网络纯净
   • 避免使用可能干扰流量的网络工具
   • 优先使用标准测试工具验证基础功能

3. Submariner服务发现机制
   标准的服务发现流程应该是：

   • 短域名自动路由到任意可用集群实例
   • 长域名用于指定特定集群的实例
   • 两种方式都应当正常工作

延伸思考

这个案例揭示了Kubernetes网络插件测试中的一个重要原则：网络问题的表象往往与实际原因存在一定距离。作为运维人员，需要建立系统化的排查思路，从底层网络到上层应用逐层验证，同时保持测试环境的简洁性，才能快速准确定位问题根源。