【Cilium / eBPF】ClusterMesh：多集群身份、服务发现与明确不保证

多集群常被说成「一个平面」。ClusterMesh 实际交付的是：跨集群的 Pod 可达性、身份感知策略、以及可选的跨集群服务发现/负载均衡——在控制面同步与 IP 规划成立的前提下。它不交付「跨集群强一致事务」「统一故障域」或「免运维的全球 DNS」。本篇钉机制边界与 不保证清单，避免把产品能力读成分布式系统定理。

本文是「Cilium / eBPF 数据面内核」系列第 11 篇（共 16 篇）。→ 系列目录

篇目	核心内容
第 2 篇 · Identity	单集群身份
第 10 篇 · L7 边界	网格边界
第 11 篇 · ClusterMesh	多集群身份与发现；不保证
第 12 篇 · 可观测	运维口径

版本锚定：Cilium v1.20.0 — Cluster Mesh 简介、Setup。v1.20 叙述含 MCS API 实现稳定化等能力；正文以文档机制为准，不把发行说明当 benchmark。

一、ClusterMesh 交付的三件事

官方 Intro 归纳的能力可收成：

1. Pod↔︎Pod 连通（扁平地址空间假设下，节点间直连转发，不强制再插一层网关代理）；
2. 集群感知的 NetworkPolicy（selector 可表达远端集群身份）；
3. 跨集群服务发现与负载均衡（含 affinity 等控制，见 load-balancing / affinity 章）。

控制面形状（v1.20 架构叙述）：每集群 clustermesh-apiserver 暴露本地状态；组件通常包括嵌入 etcd（或复用已有 kvstore）、apiserver（把本地 Cilium/K8s 状态写入可共享存储）、kvstoremesh（把远端状态同步进本地）。Agent 编程数据面时，本地 API Server 状态 + 远端 ClusterMesh 状态一并使用。

flowchart LR
  c1["Cluster A agents"] --> local1["Local kube-apiserver"]
  c1 --> cm1["clustermesh-apiserver\netcd + kvstoremesh"]
  c2["Cluster B agents"] --> local2["Local kube-apiserver"]
  c2 --> cm2["clustermesh-apiserver"]
  cm1 <-->|"mTLS sync"| cm2

数据面仍是「节点到节点」转发；ClusterMesh 不是把所有东西向流量泵进中心代理。延迟与丢包首先服从 底层路由 / 专线 / 隧道，其次才是身份与服务 map 是否已同步。

二、身份：集群 ID 进入安全等价类

单集群里，Security Identity 是安全相关标签的数字编号（第 2 篇）。多集群时：

• cluster name / cluster id 进入身份分配语境；文档写明：变更运行中集群的 cluster ID/name 后，需要重启工作负载以重建身份，否则跨集群访问会坏。
• 远端 Identity 与 IP→Identity 映射经 ClusterMesh 同步后，本地策略编译才能把「远端 frontend」写成可查的数字键（第 7 篇蒸馏过程的输入变完整）。

2.1 maxConnectedClusters 与身份空间

Setup 文档给出硬权衡（数值以 v1.20 文档表为准）：

要点：

• 全 mesh 内各集群必须配置 相同 maxConnectedClusters；
• 安装时设定，实况集群上更改可能导致连接中断与 错误的策略强制；
• 该选项影响数字身份的 比特分配，不是装饰性配额名。

这是分布式系统里典型的「用编码空间换拓扑规模」：扩集群数上限，就压缩单集群身份容量。标签爆炸的集群在 511 档更危险。

2.2 策略跨集群

跨集群 NetworkPolicy 依赖远端身份可见。同步滞后时的失败模式与第 7 篇「编译输入不完整」相同：本地已写 fromEntities / 远端 selector，map 尚无远端 ID → 该通的被拒。分区恢复后可能出现短暂双向不一致，直到 kvstoremesh 追平。

v1.20 发行叙述含便于选中整个 mesh 的策略实体等增强——方便表达，不消除同步窗口。

三、服务发现：全局服务不是魔法 DNS

ClusterMesh 的负载均衡章描述如何把服务后端扩展到远端集群、以及 affinity（偏本地或允许远端）。v1.20 对 MCS API（Multi-Cluster Services）有稳定化叙述，用于更可移植的跨集群服务发现——仍要求：

• 服务导出/导入对象按 API 配置；
• 后端就绪与身份同步；
• 调用方集群的 DNS/客户端行为符合该 API 模型。

不是「同名 Service 自动全球 Anycast 且会话永不打断」。客户端仍可能缓存旧后端；优雅终止与 EndpointSlice 条件在多集群下的表现更绕。

与 KPR（第 6 篇）叠加：跨集群后端出现在 LB map 中后，选路受算法与 affinity 约束；把 Maglev 的单集群假设直接套到全球入口会误判。

四、ClusterMesh 不保证什么（显式清单）

下列条目是工程边界，不是抱怨：

把 ClusterMesh 画进架构图时，建议在边上注明：同步延迟预算与 CIDR/身份容量预算；否则图上的「全连通」会在第一次分区演练里打脸。

五、失败模式与运维顺序

启用与连接流程以官方 cilium clustermesh enable / connect 为准（证书、Service 暴露类型 LoadBalancer/NodePort/ClusterIP 的前提不同）。本篇不展开逐步点击；强调 暴露类型选错时控制面「连上了但状态不全」 比完全连不上更难查。

# 语义：查看 ClusterMesh 状态（需多集群上下文；勿伪造）
cilium clustermesh status
# 语义：确认集群名与 ID 配置在安装期已钉死
# kubectl get cm -n kube-system cilium-config -o yaml

六、谱系、争论与开放问题

谱系：数据中心互联与 VPN → Kubernetes 联邦早期尝试 → 厂商多集群方案并行 → Cilium ClusterMesh 以 共享身份与服务状态 + 节点直连数据面 降低「每跳网关」税。多集群服务发现同时存在 MCS API、DNS 联邦、网格联邦等多条线；ClusterMesh 是其中 CNI 原生 的一条。

争论：

1. 扁平可达 vs 网关互连：扁平简单、爆破半径大；网关可审、延迟与单点更高。ClusterMesh 偏前者（在路由允许时）。
2. 身份空间编码：255↔︎65535 vs 511↔︎32767——规模与多租户标签基数的产品权衡，无免费午餐。
3. 「多集群 = 高可用」：网络平面连通 ≠ 应用状态高可用；把 ClusterMesh 当数据库同步会买错层。

开放问题：

1. 跨地域分区恢复时，身份/服务同步与策略强制的可证明收敛时间？（peer-reviewed 公开对比仍少于单集群 KPR 案例，引用延迟须标注版本与 WAN 假设——呼应 k8s-network/13 开放问题）
2. MCS 稳定化后，与网格侧多集群 API 如何避免双权威？（第 14–16 篇）

七、地址规划、暴露方式与「连上了但状态不全」

跨集群连通的前置条件往往在文档安装章之外就被踩爆：Pod CIDR（及需要时的节点 CIDR）不得冲突，底层要有路由或隧道把「远端 Pod IP」送到正确节点。ClusterMesh 不会替你做 NAT 重整整个地址空间；地址一冲突，症状是间歇黑洞或错误宿主机接收，Hubble 上则可能看到怪异的 identity 配对。

控制面暴露类型（LoadBalancer / NodePort / ClusterIP）决定远程集群如何稳定找到 clustermesh-apiserver：

• LoadBalancer：依赖云 LB 稳定 VIP；LB 抖动表现为同步中断而非数据面瞬时全断；
• NodePort：节点集合变化时要能收敛到仍存活的节点；全体节点不可达才需要重连流程；
• ClusterIP：要求该 ClusterIP 跨集群可路由——多数环境并不天然满足。

「mTLS 握手成功」只说明控制面通道在；若 kvstoremesh 落后，agent 仍可能用陈旧远端服务后端编程。因此健康检查应同时看：连接状态 + 远端集群数 + 同步是否追平（具体字段以 cilium clustermesh status 输出语义为准），而不是只看 Pod Ready。

与灾备叙事对齐：把有状态应用的 RPO/RTO 写在 ClusterMesh 边上，是架构错误。网络平面最多让你 继续访问另一集群里已经复制好的实例；复制本身属于存储/数据库域（可对照站内存储系列，但不在本篇展开）。

安全策略跨集群写好后，还要回答 谁有权改远端集群的标签：远端若被植入恶意标签从而获得被放行的 Identity，本地策略会「正确执行错误身份」。ClusterMesh 放大的是信任边界——加入 mesh 等于把对方集群的身份供给纳入自己的强制输入。治理上应限制哪些集群可连接、证书如何轮换、以及标签准入是否在各集群一致。

最后回到系列主线：第 6 篇的 Service map、第 7 篇的策略编译、第 8 篇的 Hubble，在多集群下都多了一个自变量——远端状态是否已到达本地 agent。把这个自变量写进每一张排障表，ClusterMesh 才从「架构彩页」变成可运维系统。

一句话补钉：能 ping 通远端 Pod，只证明路由；不能证明策略输入与服务后端已是同一世代的状态。

八、本篇边界与系列位置

不写：逐步建 mesh 的截图教程、每个云 LB 注解、全球流量管理系统。
第三部分从第 12 篇起收观测与排障；对照 Calico/sidecar/Ambient 见第 14 篇；选型排除树见第 16 篇。

一句话收束：ClusterMesh 扩展的是身份、策略与服务后端的共享半径；它保证不了控制面强一致，更保证不了应用层 HA——同步窗口与身份编码空间才是多集群值班的第一坐标。

参考资料

官方文档（A）

• Cilium v1.20 — Multi-Cluster (Cluster Mesh) — 架构、组件
• Cilium v1.20 — Setting up Cluster Mesh — maxConnectedClusters、cluster ID
• Cilium v1.20 — ClusterMesh load-balancing / policy / affinity 章
• Kubernetes MCS API 相关规范（对照跨集群服务发现语义）

源码（A）

• cilium/cilium v1.20.0：clustermesh-apiserver、kvstoremesh 相关包；identity 比特分配与 max-connected-clusters

站内

• 第 2 篇 · Endpoint 与 Identity
• 第 7 篇 · 策略编译
• 第 6 篇 · kube-proxy 替代
• k8s-network/13 · ClusterMesh 产品节

→ 上一篇：L7 与 Mesh 边界 · 系列目录 · 下一篇：可观测与运维口径