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三个单节点集群
• 测试服务：使用whereami应用作为测试服务

问题现象深度分析

1. DNS解析差异：

   • 短域名解析失败：whereami-cs.sample.svc.clusterset.local
   • 完整域名成功：c1.whereami-cs.sample.svc.clusterset.local
   • nslookup测试显示两种域名都能解析到正确的ClusterIP

2. 网络连通性表现：

   • 使用不同客户端容器测试时表现出不同行为
   • 基础nettool镜像完全无法解析
   • Alpine镜像能解析但无法建立连接

3. 关键发现： 最终定位到主机上运行的网络加速软件的Tun模式影响了Pod的网络通信，这是典型的网络命名空间隔离被破坏的表现。

根本原因

网络加速软件的Tun模式创建了虚拟网络设备，劫持了所有网络流量，导致：

1. Pod的DNS查询请求被错误路由
2. 跨集群的Service IP通信被中断
3. 破坏了Kubernetes标准的网络隔离机制

解决方案

1. 临时解决方案：

   • 关闭网络加速软件的Tun模式
   • 检查主机网络配置是否恢复默认状态

2. 长期建议：

   • 在生产环境避免在Kubernetes节点运行会修改网络栈的软件
   • 使用专门的网络策略管理工具而非全局加速
   • 考虑使用--net-host参数的特殊Pod来运行需要特殊网络配置的应用

3. Submariner使用建议：

   • 升级到最新版本（当前推荐0.18+）
   • 部署前确保基础网络环境纯净
   • 使用subctl diagnose命令进行预检查

经验总结

这个案例展示了Kubernetes网络问题排查的典型思路：

1. 从应用层现象（curl失败）入手
2. 逐步向下排查（DNS解析→网络连通性→主机网络配置）
3. 特别注意主机环境对容器网络的影响
4. 对比测试不同工具/镜像的表现差异

Submariner作为跨集群网络方案，对底层网络环境有较高要求，部署前应确保：

• 节点网络配置标准化
• 没有其他网络管理工具干扰
• 所有必要的端口开放
• 网络插件兼容性确认

通过这次问题排查，我们再次认识到Kubernetes网络问题的复杂性，以及系统化排查方法的重要性。建议用户在遇到类似问题时，采用从下至上或从上至下的系统化排查方法，同时注意控制变量进行对比测试。