在云原生架构不断演进的今天，单一Kubernetes集群往往难以满足大规模业务的高可用和资源隔离需求，多集群架构逐渐成为企业级容器的标准形态。然而，不同集群之间的网络通常是相互隔离的，默认情况下Pod无法直接跨集群通信。在中标麒麟操作系统这一国产化基础平台上，引入Submariner开源组件可以有效解决这一痛点。Submariner通过在集群间建立安全的IPsec隧道，实现了跨集群的Pod和Service网络直连，不仅保留了原生的网络性能，还提供了自动化的路由管理和DNS解析能力，为构建跨数据中心、跨可用域的分布式应用提供了坚实的网络底座。
Submariner核心架构与跨集群通信原理
Submariner的设计初衷是为了打破Kubernetes集群之间的网络孤岛，其核心架构包含多个关键组件，协同工作以实现透明的跨集群网络通信。其中，Gateway Engine负责在选定的网关节点上建立和维护与其他集群的IPsec隧道连接。Route Agent则运行在每一个工作节点上，负责将跨集群的流量重定向到网关节点，并处理Pod网络的路由规则。Service Discovery组件通过聚合多集群的服务信息，使得应用可以通过标准的Kubernetes DNS机制发现并访问其他集群中的服务。
在底层网络通信层面，当集群A中的Pod需要访问集群B中的Pod时，数据包首先被节点上的Route Agent拦截。Route Agent通过修改iptables或IPVS规则，将目的地址为集群B Pod网段的流量重定向到本集群的Gateway节点。Gateway节点接收到数据包后，利用IPsec协议对其进行加密封装，并通过宿主机网络发送到集群B的Gateway节点。集群B的Gateway节点解密数据包后，根据本地路由表将流量转发给目标Pod。这种架构设计不仅保证了跨集群通信的安全性，还最大程度地减少了网络开销，使得跨集群通信的延迟接近于底层物理网络的延迟。
对于中标麒麟系统而言，其底层基于Linux内核，完全支持Submariner所需的网络命名空间、VXLAN、IPsec等内核级网络特性。这意味着在中标麒麟上运行Submariner，能够直接利用内核态的高效数据转发能力，避免了用户态网络栈带来的性能损耗。同时，Submariner的网关选举机制保证了高可用性，当主网关节点发生故障时，会自动切换到备用节点，确保跨集群隧道的持续连通。
中标麒麟环境下的前置准备与网络配置
在中标麒麟系统上部署Submariner之前，需要确保各个Kubernetes集群的网络配置满足特定要求。首先是Pod CIDR和Service CIDR不能重叠。每个集群必须分配唯一的网络段，否则跨集群路由将发生冲突。其次，所有节点之间的宿主机网络必须互通，特别是UDP 4500端口必须开放，因为Submariner默认使用该端口进行IPsec NAT穿透和数据传输。中标麒麟系统默认可能启用了严格的防火墙规则，需要通过firewall-cmd或iptables进行相应放行。
除了网络端口，还需要配置内核参数以支持透明代理和路由转发。在中标麒麟上，可以通过修改系统配置文件来开启IP转发功能，并关闭可能干扰数据包转发的防火墙追踪机制。此外，如果集群节点运行在虚拟化环境中，还需要确保虚拟机网络处于同一广播域或者配置了正确的网关路由，避免二层网络隔离导致IPsec隧道建立失败。
下面是一个在中标麒麟系统上配置环境前置依赖的示例脚本，主要涉及内核参数调整和防火墙规则放行：
# 开启IP转发功能 echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf echo "net.ipv4.conf.all.forwarding = 1" >> /etc/sysctl.conf # 刷新系统参数配置 sysctl -p # 关闭防火墙或者开放Submariner所需端口 # 这里以firewall-cmd为例放行IPsec和NAT-T端口 firewall-cmd --permanent --add-port=500/udp firewall-cmd --permanent --add-port=4500/udp # 重新加载防火墙规则 firewall-cmd --reload # 验证内核转发是否开启 cat /proc/sys/net/ipv4/ip_forward
部署Submariner实现跨集群网络互通实战
完成环境准备后，可以使用Submariner官方提供的subctl工具进行跨集群网络的部署和连接。subctl是一个命令行工具，能够简化Submariner组件的安装和集群间的认证配置。首先需要在中标麒麟的管理节点上下载并安装subctl工具。接着，通过subctl broker命令在一个中心集群部署Broker组件，Broker负责存储和交换各个集群的网关信息、路由元数据等。
部署好Broker后，分别将需要互通的集群注册到Broker中。subctl会自动在每个集群中寻找合适的节点作为网关，并部署Gateway Engine和Route Agent等组件。在注册过程中，subctl会提示输入Pod CIDR和Service CIDR，工具会自动检测是否存在冲突。如果检测到网络重叠，部署将会中止，此时需要手动修改集群的网络配置。在中标麒麟环境中，由于网络插件的底层实现可能略有不同，subctl能够自适应识别并配置相应的路由规则。
以下是使用subctl连接两个集群的典型操作流程：
# 在管理节点下载subctl工具 curl -Ls https://github.com/submariner-io/releases/releases/download/v0.14.0/subctl-v0.14.0-linux-amd64 -o subctl # 赋予执行权限 chmod +x subctl # 将其移动到系统路径 mv subctl /usr/local/bin/ # 在集群A部署Broker subctl deploy-broker --kubeconfig cluster-a.kubeconfig # 将集群A加入Broker subctl join --kubeconfig cluster-a.kubeconfig --clusterid cluster-a # 将集群B加入Broker subctl join --kubeconfig cluster-b.kubeconfig --clusterid cluster-b
跨集群服务发现与DNS解析机制
仅仅实现Pod网络的互通是不够的，在微服务架构中，应用通常通过Service名称进行互相访问。Submariner通过Lighthouse组件实现了跨集群的DNS解析和服务发现。Lighthouse作为一个自定义的DNS解析器，会拦截集群内对特定后缀域名的解析请求，并从Broker获取其他集群的Service信息，从而返回跨集群Service的真实IP地址。
当集群A中的Pod尝试访问集群B中的服务时，其DNS请求会被Lighthouse Agent拦截。Lighthouse发现该服务属于集群B，便会返回集群B中对应Service的Cluster IP。随后，Pod发出的数据包目的地址为集群B的Service IP，该数据包被路由到集群A的网关节点，网关节点通过IPsec隧道将其发送到集群B。集群B的网关接收到数据包后，通过本地的kube-proxy规则将其负载均衡到后端的Pod上。整个过程对应用层完全透明，开发者无需修改任何代码即可实现跨集群的服务调用。
为了确保跨集群DNS解析的稳定性和效率，在中标麒麟环境中建议对CoreDNS进行适当的性能调优。可以增加CoreDNS的副本数，并根据节点资源情况调整CPU和内存限制。同时，Lighthouse组件本身也支持多实例部署，通过Leader Election机制保证高可用。在实际生产环境中，还需要监控跨集群DNS解析的延迟，如果发现解析超时，可以检查Broker的连接状态以及Lighthouse Agent的日志，确保多集群状态同步正常。
中标麒麟Submariner跨集群网络修改时间：2026-08-30 13:47:09