3、多集群网络模型:Cluster Mesh 概念、跨集群 Pod IP 路由、Global Service 与 Endpoint 同步原理

当单一 Kubernetes 集群无法满足规模、地域或故障隔离需求时,多集群架构成为必然选择。Cilium 的 Cluster Mesh 功能允许将多个集群的 Pod 网络无缝连接,使 Pod 能够像在同一个集群内一样直接通信,同时保留集群的独立管理边界。本章深入解析 Cluster Mesh 的核心概念、跨集群 Pod IP 路由机制,以及 Global Service 与 Endpoint 同步的实现原理。

3.1 Cluster Mesh 概念与架构

Cluster Mesh 是 Cilium 提供的一种多集群网络互联方案,它通过在每个集群的 Cilium Agent 之间建立加密或非加密的隧道(通常基于 WireGuard 或 IPsec),将多个集群的 Pod CIDR 和 Service 信息进行交换,从而构建一个扁平化的多集群网络平面。

关键前提:Cluster Mesh 要求所有参与集群的 Pod CIDR 不能重叠,且集群间网络可达(通常通过节点 IP 或网关)。Cilium 会自动处理跨集群的 IP 路由和策略实施。

Cluster Mesh 的核心组件包括:

  • Cilium Agent:每个节点上的代理,负责管理本地 Pod 网络、策略执行,并通过 Cluster Mesh 协议与其他集群的 Agent 交换路由和 Service 信息。
  • KVStore(可选):用于跨集群共享状态,如 Global Service 的 Endpoint 信息。通常使用 etcd 或 Consul。
  • Cluster Mesh API:一组 CRD(如 CiliumClusterwideNetworkPolicy)和配置,用于定义跨集群的网络策略和服务发现。
Cluster Mesh 多集群互联架构 Cluster Mesh 多集群互联架构 集群 A (Cluster A) Cilium Agent A1 Cilium Agent A2 Pod 10.0.1.2 Pod 10.0.2.3 Service: svc-a (ClusterIP) 集群 B (Cluster B) Cilium Agent B1 Cilium Agent B2 Pod 10.1.1.5 Pod 10.1.2.7 Service: svc-b (ClusterIP) WireGuard / IPsec 隧道 KVStore (etcd/Consul)

3.2 跨集群 Pod IP 路由

Cluster Mesh 实现跨集群 Pod 通信的核心机制是 路由注入与隧道封装。每个集群的 Cilium Agent 通过 Cluster Mesh 协议学习到其他集群的 Pod CIDR,并将这些路由注入到本地节点的路由表中。当本地 Pod 访问远端 Pod 时,数据包根据路由表被转发到本集群的出口节点,然后通过隧道封装发送到目标集群的入口节点,最终解封装并路由到目标 Pod。

跨集群路由的关键步骤:

  1. 路由学习:Cilium Agent 通过 Cluster Mesh 的 BGP 或直接 API 交换,获取远端集群的 Pod CIDR 列表。
  2. 路由注入:将远端 Pod CIDR 作为下一跳指向本集群的隧道端点(通常是节点 IP)。
  3. 隧道封装:数据包在出口节点被封装(如 Geneve、VXLAN 或 WireGuard),添加目标集群的节点 IP 作为外层头部。
  4. 解封装与转发:目标集群的入口节点收到封装包后,解封装并根据内层目标 Pod IP 转发到本地 Pod。
性能优化:Cilium 支持直接路由模式(Direct Routing),当集群间网络二层可达时,可以绕过隧道封装,直接通过原生路由转发,显著降低延迟和 CPU 开销。但需要底层网络支持(如 AWS VPC 路由表、BGP 等)。

以下表格对比了 Cluster Mesh 支持的两种主要路由模式:

路由模式 封装方式 适用场景 性能 网络要求
隧道模式 Geneve / VXLAN / WireGuard 跨数据中心、云间互联、不可信网络 中等(有封装开销) 仅需节点 IP 可达
直接路由模式 无封装(原生路由) 同一 VPC、二层可达、高性能场景 高(无封装开销) 需要底层路由支持(如 BGP、云路由表)

3.3 Global Service 与 Endpoint 同步原理

在多集群环境中,仅实现 Pod 网络互联还不够,还需要让 Service 能够跨集群发现和负载均衡。Cilium 通过 Global Service 机制实现这一目标。Global Service 本质上是一个跨集群的 Service,其 Endpoint 由所有参与集群的 Pod 共同组成。

Global Service 的核心原理:

  • Service 定义:在每个集群中定义一个同名的 Service(通常使用相同的 ClusterIP 或通过 DNS 解析),并标记为 Global(通过 annotation 或 CRD)。
  • Endpoint 同步:Cilium Agent 通过 KVStore 或直接 Agent 间通信,将本地集群中匹配该 Service 的 Pod Endpoint 信息同步到其他集群。
  • 本地负载均衡:每个集群的 Cilium Agent 根据同步后的全局 Endpoint 列表,在本地生成 eBPF 负载均衡规则,实现跨集群的流量分发。
Global Service Endpoint 同步流程 Global Service Endpoint 同步流程 集群 A Cilium Agent A Pod: 10.0.1.2 Global Service: svc-g Pod: 10.0.2.3 本地 Endpoint: [10.0.1.2, 10.0.2.3] 集群 B Cilium Agent B Pod: 10.1.1.5 Global Service: svc-g Pod: 10.1.2.7 本地 Endpoint: [10.1.1.5, 10.1.2.7] 同步 Endpoint 全局 Endpoint: [10.0.1.2, 10.0.2.3, 10.1.1.5, 10.1.2.7]

Endpoint 同步的详细流程:

  1. 本地 Endpoint 收集:每个集群的 Cilium Agent 通过监听 Kubernetes API 或直接 eBPF 事件,收集本地匹配 Global Service 的 Pod Endpoint(IP + 端口)。
  2. 状态发布:Agent 将本地 Endpoint 列表写入 KVStore(如 etcd)的特定路径,或通过 Cluster Mesh 协议直接推送给其他集群的 Agent。
  3. 远端 Endpoint 订阅:其他集群的 Agent 订阅 KVStore 中的变化事件,或接收推送消息,获取远端 Endpoint 列表。
  4. 本地 eBPF 规则更新:Agent 将全局 Endpoint 列表合并到本地 eBPF 负载均衡映射中,使得本地 Pod 访问 Global Service 时,流量可以分发到所有集群的 Pod。
注意:Global Service 的 Endpoint 同步存在一定的延迟(通常秒级),在频繁扩缩容或故障转移场景下,可能导致短暂的流量黑洞或负载不均。建议结合就绪探针(Readiness Probe)和优雅终止(Graceful Shutdown)来减少影响。

3.4 多集群网络策略与安全

Cluster Mesh 不仅提供网络互联,还支持跨集群的网络策略实施。Cilium 的 CiliumClusterwideNetworkPolicy 可以定义跨集群的流量规则,例如:

  • 允许集群 A 的特定命名空间访问集群 B 的特定 Service。
  • 禁止跨集群的某些高危端口通信。
  • 基于身份(Identity)的跨集群微隔离。

跨集群策略的执行依赖于 Cilium 的身份机制:每个 Pod 被分配一个全局唯一的 Security Identity,该 Identity 在 Cluster Mesh 中跨集群同步。当数据包到达远端集群时,目标节点的 Cilium Agent 根据数据包携带的源 Identity 和本地策略进行过滤,实现跨集群的零信任网络。

下表总结了 Cluster Mesh 中关键组件的功能对比:

组件 功能 跨集群依赖 性能影响
Pod IP 路由 跨集群 Pod 直接通信 隧道或直接路由 隧道模式有封装开销
Global Service 跨集群 Service 发现与负载均衡 KVStore 或 Agent 间同步 同步延迟秒级
网络策略 跨集群流量安全控制 Identity 同步 策略匹配在 eBPF 中完成,开销极低
KVStore 状态共享与协调 所有集群共享 读写延迟取决于存储性能