3、多集群网络模型:Cluster Mesh 原理、跨集群 Service 发现、Global Service 与本地 Service 的区别

3.1 Cluster Mesh 核心原理

Cilium Cluster Mesh 通过将多个 Kubernetes 集群的 Pod 网络 和 Service 网络 逻辑上打通,实现跨集群的 Pod 直接通信与 Service 透明发现。其底层依赖 eBPF 程序在节点上直接路由或封装数据包,无需传统网关或代理。

关键前提: 每个集群必须使用唯一的 Pod CIDR 和 Service CIDR,避免 IP 地址重叠。Cluster Mesh 依赖 BGP 或直接路由(如 VXLAN/Geneve)在集群间交换路由信息。
Cluster Mesh 跨集群通信架构 集群 A (Cluster-A) Node-A1 Pod: 10.0.1.2 Node-A2 Pod: 10.0.2.3 Service: svc-a (ClusterIP: 10.96.1.10) Global Service: true Cilium Agent (eBPF) 路由表 + Service 映射 集群 B (Cluster-B) Node-B1 Pod: 10.1.1.4 Node-B2 Pod: 10.1.2.5 Service: svc-b (ClusterIP: 10.97.2.20) Global Service: true Cilium Agent (eBPF) 路由表 + Service 映射 BGP / VXLAN Service 同步 每个集群的 Cilium Agent 通过 KV Store (etcd) 交换 Pod 路由和 Global Service 信息

3.2 跨集群 Service 发现机制

Cluster Mesh 实现跨集群 Service 发现的核心组件是 KV Store(etcd) 和 Cilium Agent 的同步控制器。每个集群的 Cilium Agent 将本集群的 Service 信息(特别是标记为 global 的 Service)写入共享的 KV Store,同时从 KV Store 读取其他集群的 Service 信息,并注入到本集群的 eBPF 映射表中。

组件 职责 数据流向
KV Store (etcd) 存储跨集群共享的 Service 和 Endpoint 信息 所有集群的 Cilium Agent 读写
Cilium Agent 监听本集群 Service 变化,同步到 KV Store;从 KV Store 拉取远端 Service 本地 → KV Store → 远端
eBPF 映射表 存储本地 + 远端 Service 的 ClusterIP 到后端 Pod IP 的映射 Agent 写入,数据面直接查找
DNS 代理 将跨集群 Service 名称解析为正确的 ClusterIP Pod → DNS → Agent → eBPF
故障排查要点: 如果跨集群 Service 无法发现,首先检查 KV Store 连通性(cilium clustermesh status),然后确认远端 Service 是否已标记为 global,最后在目标集群节点上执行 cilium service list 查看是否出现远端 Service 条目。

3.3 Global Service 与本地 Service 的区别

在 Cluster Mesh 中,Service 分为 本地 Service 和 Global Service 两种类型。两者的核心区别在于是否将 Endpoint 信息同步到其他集群。

Global Service vs 本地 Service 对比 本地 Service svc-local (ClusterIP: 10.96.1.10) shared: false 集群 A 内 Pod 可访问 后端 Pod: 10.0.1.2, 10.0.2.3 ❌ 不写入 KV Store ❌ 其他集群不可见 ✅ 仅本集群内负载均衡 Global Service svc-global (ClusterIP: 10.96.2.20) shared: true 所有集群 Pod 均可访问 后端 Pod: 跨集群分布 ✅ 写入 KV Store ✅ 其他集群自动发现 ✅ 跨集群负载均衡

3.4 关键差异对比表

对比维度 本地 Service Global Service
YAML 标记 cilium.io/global-service: "false" 或未设置 cilium.io/global-service: "true"
Endpoint 同步 仅本集群内可见 同步到所有已连接的集群
KV Store 写入 不写入 写入共享 etcd
跨集群访问 不支持 支持,自动路由到远端 Pod
负载均衡范围 本集群后端 Pod 所有集群的后端 Pod
典型场景 内部监控、集群本地缓存 多活应用、全局入口网关

3.5 故障排查中的关键观察点

  • Service 是否标记为 Global: 使用 kubectl get svc <svc-name> -o yaml | grep global-service 确认 annotation 是否存在且为 "true"。
  • KV Store 连通性: 执行 cilium clustermesh status 查看所有集群的 etcd 连接状态,重点关注 remote clusters 是否显示 connected。
  • 远端 Service 是否注入: 在目标集群节点上执行 cilium service list,查找带有 cluster 标签的远端 Service 条目。
  • DNS 解析是否跨集群: 在 Pod 内执行 nslookup <svc-name>.<namespace>.svc.clusterset.local,确认返回的 ClusterIP 是否与远端 Service 一致。
  • 数据面连通性: 使用 cilium monitor 或 tcpdump 在源节点和目标节点抓包,确认数据包是否被正确封装/路由到远端集群。
常见陷阱: 如果 Global Service 的后端 Pod 分布在多个集群,但某个集群的节点无法访问远端 Pod,请检查该节点的 路由表 是否包含远端 Pod CIDR 的路由条目(ip route show),以及底层网络(如 VXLAN 隧道或 BGP 邻居)是否正常。