3. Multi-Cluster 架构模式概述：主流模式对比
在 Multi-Cluster 架构设计中，控制平面与租户边界的接口设计高度依赖于底层集群的组织模式。不同的架构模式决定了控制面的管理粒度、网络拓扑、租户隔离方式以及跨集群通信的效率。本章对三种主流模式——Hub-Spoke、Federation 和 Cluster Mesh——进行系统性对比，帮助你在实际项目中做出架构选型决策。
3.1 三种模式的核心思想
| 模式 | 核心思想 | 控制平面位置 | 典型场景 |
|---|---|---|---|
| Hub-Spoke | 中心化管控，Hub 集群作为控制与策略下发中心，Spoke 集群执行工作负载 | Hub 集群集中部署 | 多环境管理、合规管控、边缘计算 |
| Federation | 联邦控制面，通过 Federation API 将多个集群抽象为单一资源池 | 独立的 Federation 控制面或宿主集群 | 跨区域应用分发、全局调度、灾备 |
| Cluster Mesh | 扁平化互联，通过服务网格或 Overlay 网络实现跨集群 Pod 直连 | 分布式，每个集群保留自治控制面 | 微服务跨集群调用、低延迟互通、混合云 |
选型提示： 如果你的首要需求是 集中策略管控与合规审计，Hub-Spoke 是最直接的选择；如果需要 全局资源调度与统一 API，Federation 更合适；如果追求 低延迟跨集群服务调用，Cluster Mesh 是首选。
3.2 Hub-Spoke 模式详解
Hub-Spoke 是当前企业级 Multi-Cluster 管理中最广泛采用的模式。其核心特征是 控制面与数据面分离：Hub 集群承载全局控制平面组件（如策略引擎、审计日志、租户管理 API），Spoke 集群仅运行用户工作负载和必要的 Agent。
Hub-Spoke 的租户边界设计要点
- 租户定义在 Hub 层：租户信息、配额、RBAC 策略统一在 Hub 控制面管理，通过 CRD 下发到 Spoke。
- Spoke 集群无租户概念：Spoke 仅感知 Namespace 和 ResourceQuota，租户映射由 Hub 的 Admission Webhook 完成。
- 网络隔离：Spoke 之间默认不互通，跨 Spoke 通信必须经过 Hub 的 API 网关或 Service Mesh 出口。
生产案例： 某金融科技公司使用 Hub-Spoke 模式管理 50+ 边缘集群。Hub 集群部署在中心机房，统一下发合规策略和镜像白名单；每个边缘 Spoke 集群仅运行交易服务，通过 Agent 定期上报状态。租户边界通过 Hub 的
Tenant CRD 定义，每个租户对应一组 Spoke 集群的 Namespace 集合。
3.3 Federation 模式详解
Federation（联邦）模式通过 Federation API 将多个 Kubernetes 集群抽象为一个统一的资源池。其核心组件是 Federation Control Plane，负责将用户提交的 Federated 资源（如 FederatedDeployment）同步到成员集群。
Federation 的租户边界设计要点
- 租户映射复杂：Federation 本身不定义租户，租户边界依赖成员集群的 Namespace 隔离。跨集群的租户一致性需要额外的同步机制。
- 资源分发策略：通过
ReplicaSchedulingPreference控制每个成员集群的副本分布，租户配额需要在每个集群单独配置。 - 状态回写：成员集群的资源状态通过
FederatedResourceStatus回写到 Federation 控制面，用于全局视图展示。
注意： Federation 模式在租户数量超过 50 时，控制面的状态同步压力会显著增加。每个 Federated 资源在每个成员集群上都会产生一个对应资源，导致 etcd 存储量线性增长。建议在租户边界设计时，将 Federation 控制面仅用于 应用分发，租户管理仍由上层平台（如 Multi-Cluster API Gateway）处理。
3.4 Cluster Mesh 模式详解
Cluster Mesh 模式通过 服务网格（如 Istio、Cilium）或 Overlay 网络 实现跨集群的 Pod 直连。每个集群保留完整的自治控制面，Mesh 控制面仅负责服务发现和网络策略的同步。
Cluster Mesh 的租户边界设计要点
- 租户边界由 Mesh 策略定义：通过
ServiceEntry、VirtualService和AuthorizationPolicy控制跨集群的租户访问范围。 - 身份与证书：每个 Pod 拥有 SPIFFE 身份，Mesh 控制面负责跨集群的证书分发与信任锚点建立。
- 网络性能：由于 Pod 直连，租户间的网络隔离依赖 mTLS 和 L7 策略，而非传统的 VPC 或 Subnet 隔离。
3.5 三种模式综合对比
| 对比维度 | Hub-Spoke | Federation | Cluster Mesh |
|---|---|---|---|
| 控制面复杂度 | 中等（Hub 集中管控） | 高（Federation API + 同步逻辑） | 低（每个集群自治） |
| 租户隔离粒度 | Hub 层统一管理，Spoke 层 Namespace 隔离 | 依赖成员集群自身隔离机制 | Mesh 策略 + mTLS 身份隔离 |
| 跨集群网络延迟 | Spoke 间需经 Hub 网关，延迟较高 | 无默认网络互通，需额外配置 | Pod 直连，延迟最低 |
| 状态同步开销 | 低（仅 Agent 上报） | 高（每个资源全量同步） | 低（仅服务发现同步） |
| 适用集群规模 | 10-100+ 集群 | 3-50 集群 | 2-20 集群（Mesh 控制面压力） |
| 典型工具 | Karmada, Clusternet, OCM | KubeFed (v2), Admiral | Istio Multi-Cluster, Cilium Cluster Mesh |
3.6 模式选型决策树
- 是否需要集中策略管控？
- 是 → 选择 Hub-Spoke
- 否 → 进入下一步
- 是否需要全局资源调度与统一 API？
- 是 → 选择 Federation
- 否 → 进入下一步
- 是否需要低延迟跨集群服务调用？
- 是 → 选择 Cluster Mesh
- 否 → 根据团队技术栈选择：熟悉 Service Mesh 选 Cluster Mesh，熟悉集中管控选 Hub-Spoke
架构师建议： 在实际生产环境中，三种模式并非互斥。例如，你可以使用 Hub-Spoke 管理集群生命周期和租户策略，同时在 Hub 与关键 Spoke 之间部署 Cluster Mesh 实现低延迟服务互通。这种混合模式在大型金融和电商平台中已有成功实践。