基于网络层的打通方案

1.Submariner

实现方式

通过 VPN 隧道（IPsec/WireGuard）连接不同集群的 Pod/Service CIDR。
使用 Lighthouse 实现跨集群 DNS 服务发现。
可选 Globalnet 解决集群间 CIDR 冲突问题。

特点：

L3/L4 层打通，支持 Pod IP 直连。
兼容大多数 CNI（Calico、Flannel 等）。
适合混合云、边缘计算场景。

适用场景：

需要跨集群 Pod 直接 Ping/SSH。
集群间网络隔离严格（如跨云厂商）。

介绍

Submariner 以安全高效的方式连接多个 Kubernetes 集群。Submariner 使连接的集群之间的网络更加扁平化，并实现 Pod 和服务之间的 IP 可达性。Submariner 还通过 Lighthouse 提供服务发现功能。服务发现模型基于以下建议构建： Kubernetes 多集群服务。

Submariner 由几个主要组件组成，它们协同工作，以安全地连接本地和公共云上的多个 Kubernetes 集群中的工作负载：

Gateway Engine：管理到其他集群的安全隧道。
Route Agent:：将跨集群流量从节点路由到活动网关引擎。
Broker：促进网关引擎之间的元数据交换，使它们能够相互发现。
Service Discovery：提供跨集群服务的 DNS 发现。

Submariner 具有提供附加功能的可选组件：

Globalnet 控制器：处理具有重叠 CIDR 的集群的互连。

组件介绍

broker

Submariner 使用一个中央 Broker 组件来促进参与集群中部署的网关引擎之间的元数据信息交换。该 Broker 本质上是一组由 Kubernetes 数据存储支持的自定义资源定义 (CRD)。此外，它还定义了 ServiceAccount 和 RBAC 组件，以使其他 Submariner 组件能够安全地访问 Broker 的 API。

虽然没有与 Broker 关联的服务，但使用subctl部署 Broker 也会部署一个安装 CRD 和 Globalnet 配置的操作员 Pod。

Submariner 定义了两个通过 Broker 进行交换的 CRD：Endpoint和Cluster。CRDEndpoint包含集群中活动网关引擎的信息，例如其 IP，这些信息是集群相互连接所必需的。CRDCluster包含源集群的静态信息，例如其服务和 Pod CIDR。

Broker 是一个单例组件，部署在一个集群上，该集群的 Kubernetes API 必须可供所有参与集群访问。如果混合使用本地集群和公共集群，则可以将 Broker 部署在公共集群上。Broker 集群可以是参与集群之一，也可以是未部署其他 Submariner 组件的独立集群。每个参与集群中部署的网关引擎组件都配置了安全连接到 Broker 集群 API 的信息。

Broker 集群的可用性不会影响参与集群上数据平面的运行，也就是说，在 Broker 不可用期间，数据平面将继续使用最新已知信息路由流量。但是，在此期间，控制平面组件将无法向其他集群通告新的或更新的信息，也无法从其他集群获取新的或更新的信息。当重新建立与 Broker 的连接时，每个组件将自动将其本地信息与 Broker 重新同步，并在必要时更新数据平面。

Gateway Engine

网关引擎组件部署在每个参与集群中，负责建立到其他集群的安全隧道可采用如下方式实现

使用VXLAN实现的非加密隧道方案。

IPsec方案

网关引擎实例在集群中特定指定的节点上运行，集群中可能存在多个节点，以实现容错。Submariner 支持网关引擎组件的主/被动高可用性，这意味着集群中一次只有一个活动的网关引擎实例。它们会执行领导者选举流程来确定活动实例，而其他实例则处于待命模式，以便在活动实例发生故障时接管。

网关引擎部署为 DaemonSet，配置为仅在标有 的节点上运行submariner.io/gateway=true。

活跃网关引擎与中央 Broker 进行通信，以将其资源通告Endpoint给Cluster连接到该 Broker 的其他集群，同时确保它是Endpoint其集群的唯一网关引擎。路由代理集群中运行的 Pod 会了解本地情况Endpoint，并设置必要的基础架构，以便将跨集群流量从所有节点路由到活动的网关引擎节点。活动的网关引擎还会在 Broker 上建立监视，以了解其他集群通告的活动Endpoint资源 Cluster。一旦两个集群彼此感知到对方的资源Endpoints，它们就可以建立一个安全的隧道，通过该隧道路由流量。

service discovery

Lighthouse Agent 在每个集群中运行，并访问 Broker 集群中运行的 Kubernetes API 服务器，与其他集群交换服务元数据信息。本地服务信息导出到 Broker，并导入其他集群的服务信息。

工作流程

Lighthouse Agent 连接到 Broker 的 Kubernetes API 服务器。
对于本地集群中每个已创建 ServiceExport 的服务，Agent 都会创建 ServiceImport 和 EndpointSlice 资源，并将其导出到 Broker 以供其他集群使用。
对于 Broker 从另一个集群导出的每个资源，它都会在本地集群中创建它的副本。

Lighthouse DNS 服务器

Lighthouse DNS 服务器作为拥有该域名的外部 DNS 服务器运行clusterset.local。CoreDNS 配置为将任何发送到clusterset.localLighthouse DNS 服务器的请求转发到该服务器，该服务器使用控制器分发的 ServiceImport 和 EndpointSlice 资源构建用于 DNS 解析的地址缓存。Lighthouse DNS 服务器支持使用 A 记录和 SRV 记录进行查询。

当单个服务部署到多个集群时，Lighthouse DNS 服务器会首先选择本地集群，然后以循环方式将流量路由到其他远程集群。

工作流程如下：

Pod 尝试使用域名解析服务名称clusterset.local。
CoreDNS 将请求转发到 Lighthouse DNS 服务器。
Lighthouse DNS 服务器将使用其地址缓存来尝试解析该请求。
如果记录存在，则会返回该记录，否则将返回 NXDomain 错误。

GLOBALNET 控制器

GLOBALNET 是 Submariner 项目中的一个关键组件，主要用于解决以下问题：

集群CIDR重叠问题：
当多个Kubernetes集群使用相同的Pod CIDR或Service CIDR时
提供全局唯一的IP地址空间（Global CIDR）
网络地址转换(NAT)：
在不同集群间透明地转换IP地址
使重叠的网络地址空间能够互相通信
跨集群服务发现：
与Lighthouse组件协同工作
实现跨集群的服务DNS解析

Submariner 遵循以下逻辑来进行跨集群集的服务发现：

如果导出的服务在本地集群中不可用，Lighthouse DNS 从服务导出的远程集群之一返回 ClusterIP 服务的 IP 地址。
如果导出的服务在本地集群中可用，Lighthouse DNS 总是返回本地 ClusterIP 服务的 IP 地址。
如果多个集群从同一个命名空间导出具有相同名称的服务，Lighthouse DNS 会以轮询的方式在集群之间进行负载均衡。
可以在 DNS 查询前加上 cluster-id
前缀来访问特定集群的服务，<cluster-id>.<svc-name>.<namespace>.svc.clusterset.local

组件的安装方式：

安装 subctl

curl -Lo subctl-release-0.14-linux-amd64.tar.xz https://github.com/submariner-io/subctl/releases/download/subctl-release-0.14/subctl-release-0.14-linux-amd64.tar.xz
tar -xf subctl-release-0.14-linux-amd64.tar.xz
mv subctl-release-0.14/subctl-release-0.14-linux-amd64 /usr/local/bin/subctl
chmod +x /usr/local/bin/subctl

使用 karmada-host 用作 Broker

subctl --context kind-broker deploy-broker

cluster1 和 cluster2 接入到 Broker

subctl --context kind-c1 join broker-info.subm --clusterid c1
subctl --context kind-c2 join broker-info.subm --clusterid c2

查看集群的链接情况

subctl show connections --context kind-c1
subctl show connections --context kind-c2

醋醋百科网

Good Luck To You!

多集群网络打通实现的方案(Submariner)