1. 多集群拓扑基础：ClusterMesh 架构概览
1.1 ClusterMesh 架构概览
ClusterMesh 是 Cilium 提供的原生多集群互联方案，它允许跨 Kubernetes 集群的 Pod 通过 Pod IP 直接通信，而无需网关或 NAT 转换。其核心思想是：每个集群仍保留独立的控制面，但通过共享服务与端点信息，构建一个扁平化的逻辑网络。
关键设计原则： 去中心化控制面、保留集群自治性、Pod IP 直达、原生安全策略跨集群生效。
下图展示了两个集群通过 ClusterMesh 互联后的核心组件与数据流：
ClusterMesh 通过以下组件实现跨集群互联：
- ClusterMesh Agent（clustermesh-apiserver）： 每个集群部署一个，负责对外暴露本集群的服务与端点信息，同时拉取对端集群的数据。
- KVStore（etcd）： 存储集群的全局标识、服务导出/导入状态、身份认证信息。
- Cilium Agent： 消费来自对端集群的端点信息，生成跨集群的 eBPF 转发规则与网络策略。
- gRPC 双向同步通道： 集群之间通过 mTLS 加密的 gRPC 流实时同步服务与端点变更。
1.2 ClusterMesh 与 Cilium 的关系
理解 ClusterMesh 与 Cilium 的关系，需要从功能分层和部署依赖两个维度来看：
| 维度 | Cilium | ClusterMesh |
|---|---|---|
| 定位 | 单集群 CNI 插件 + 网络策略引擎 | Cilium 的多集群扩展组件 |
| 核心能力 | Pod 网络、Service 负载均衡、网络策略、可观测性 | 跨集群 Pod IP 路由、全局 Service 发现、跨集群网络策略 |
| 依赖关系 | 独立运行，不依赖 ClusterMesh | 必须运行在已部署 Cilium 的集群之上 |
| 数据面 | eBPF 程序直接挂载到网络设备 | 复用 Cilium 的 eBPF 数据面，仅增加跨集群路由表 |
| 控制面 | Kubernetes API + KVStore | 额外启动 clustermesh-apiserver，与对端集群建立 gRPC 连接 |
| 安全策略 | CiliumNetworkPolicy（单集群） | CiliumClusterwideNetworkPolicy（跨集群生效） |
一句话总结： Cilium 是单集群的“地基”，ClusterMesh 是在此基础上搭建的“桥梁”。没有 Cilium，ClusterMesh 无法工作；但 Cilium 可以独立运行，无需 ClusterMesh。
从部署架构上看，ClusterMesh 并不修改 Cilium Agent 的核心代码，而是通过插件式组件（clustermesh-apiserver）和额外的配置数据（集群 ID、对端集群端点、共享的 CA 证书）来扩展 Cilium 的能力。Cilium Agent 在启动时如果检测到 ClusterMesh 配置，会自动加载跨集群的端点信息和路由规则。
1.3 多集群网络模型对比
在生产环境中，多集群网络互联有多种实现方案。下表从网络模型、性能、安全、运维复杂度四个维度对比主流方案：
| 方案 | 网络模型 | 性能开销 | 安全隔离 | 运维复杂度 | 典型场景 |
|---|---|---|---|---|---|
| ClusterMesh | 扁平 Overlay（VXLAN/Geneve）或 Native Routing | 低（eBPF 内核态转发） | 强（mTLS + 身份标识 + 跨集群策略） | 中（需配置集群 ID、证书、KVStore） | 多集群微服务互通、跨集群高可用 |
| Submariner | Gateway + IPsec/WireGuard 隧道 | 中（用户态网关转发） | 中（隧道加密，策略依赖第三方） | 高（需部署 gateway、broker、service discovery） | 多云/混合云集群互联 |
| Istio Multi-Cluster | 应用层代理（Sidecar） | 高（Envoy 代理引入额外延迟） | 强（mTLS + 应用层策略） | 高（需管理多个控制面、证书、DNS） | 服务网格多集群、灰度发布 |
| KubeFed + 自定义 CNI | 依赖底层 CNI 实现 | 取决于 CNI | 弱（无统一跨集群策略模型） | 高（需组合多个组件） | 资源分发、联邦调度 |
| 直接 VPC 对等 | 原生 L3 路由 | 最低（无额外封装） | 弱（依赖云厂商安全组） | 低（云厂商原生能力） | 同云厂商、同区域集群互联 |
从对比中可以看出，ClusterMesh 在性能和安全策略两个维度上具有显著优势。其核心差异在于：
- 数据面性能： ClusterMesh 利用 eBPF 在内核态完成转发，避免了 Submariner 的用户态网关和 Istio 的 Sidecar 代理带来的额外延迟。
- 安全模型统一： ClusterMesh 将跨集群网络策略与单集群策略模型（CiliumNetworkPolicy）统一，运维人员可以用相同的 YAML 语法定义跨集群的访问控制。
- Pod IP 直达： 与 VPC 对等类似，ClusterMesh 实现了 Pod IP 级别的直接路由，但不受云厂商网络限制，适用于混合云和多云场景。
选型提醒： 如果集群之间需要严格的租户隔离（如金融行业的多租户环境），ClusterMesh 的身份标识（Identity）机制和集群级网络策略是其他方案难以替代的。但如果只是简单的资源联邦调度，KubeFed 或直接 VPC 对等可能更轻量。
下图从网络栈层次的角度对比 ClusterMesh 与 Istio Multi-Cluster 的差异：
ClusterMesh 在网络层（L3）完成跨集群互联，对上层应用完全透明；而 Istio Multi-Cluster 在应用层（L7）通过 Sidecar 代理处理流量，虽然提供了更丰富的流量管理能力，但也引入了更高的延迟和资源开销。
核心结论： 如果你的首要目标是高性能、低延迟、强安全隔离的跨集群 Pod 通信，ClusterMesh 是最优选择；如果你需要精细的流量治理（灰度发布、故障注入、请求重试），Istio Multi-Cluster 更合适。两者也可以结合使用——ClusterMesh 提供网络层互联，Istio 在应用层做流量管理。