多集群拓扑基础：Hub-Spoke、Federation、ClusterSet 等常见拓扑模式对比
在多集群架构设计中，拓扑模式决定了控制面如何分布、资源如何同步、以及故障域如何隔离。不同的拓扑模式适用于不同的业务规模和运维成熟度。本章从控制面耦合度、资源同步方向、租户边界隔离三个维度，对比三种主流模式：Hub-Spoke、Federation、ClusterSet。
1. 三种拓扑模式的核心特征
| 维度 | Hub-Spoke | Federation | ClusterSet |
|---|---|---|---|
| 控制面位置 | 中心 Hub 集群 | 独立 Federation 控制面 | 成员集群对等 |
| 资源同步方向 | Hub → Spoke（单向推送） | Federation → 成员（双向同步） | 成员间对等同步 |
| 租户隔离粒度 | 按 Spoke 集群隔离 | 按 Federation Namespace 隔离 | 按 ClusterSet 标签隔离 |
| 故障影响范围 | Hub 故障影响全局 | Federation 控制面故障影响同步 | 单成员故障不影响其他成员 |
| 典型工具 | Karmada, OCM, Rancher | KubeFed (v1/v2) | Kubernetes Cluster API, Submariner |
选型提示： 如果你的团队刚起步，推荐从 Hub-Spoke 开始，控制面集中、运维简单；当集群数量超过 50 且需要跨集群资源对等调度时，再考虑 Federation 或 ClusterSet。
2. Hub-Spoke 模式详解
Hub-Spoke 是最广泛使用的多集群拓扑。一个中心集群（Hub）作为控制面，管理多个工作集群（Spoke）。Hub 上运行调度器、资源模板和分发策略，Spoke 只运行实际工作负载。
- 资源流向： Hub 通过
ResourceBinding将模板推送到指定 Spoke。 - 租户边界： 每个 Spoke 集群可以绑定一个租户，租户间完全隔离。
- 版本差异风险： Hub 与 Spoke 的 Kubernetes API 版本不一致时，资源模板可能无法正确序列化。
3. Federation 模式详解
Federation 模式通过一个独立的 Federation 控制面，将多个集群的资源统一编排。Federation 控制面不运行工作负载，只负责资源模板的分发和状态同步。
- 资源流向： 双向同步——Federation 将模板推送到成员集群，成员集群的状态回写到 Federation。
- 租户边界： 通过 Federation Namespace 划分，不同 Namespace 可以映射到不同成员集群。
- 版本差异风险： 成员集群之间的 API 版本差异会导致状态回写失败或字段丢失。
4. ClusterSet 模式详解
ClusterSet 是 Kubernetes SIG 提出的对等多集群模型。集群之间没有中心控制面，通过 Cluster API 或 Submariner 实现网络互通和资源对等调度。
- 资源流向： 成员集群之间对等同步，没有中心协调者。
- 租户边界： 通过 ClusterSet 标签和 RBAC 实现逻辑隔离。
- 版本差异风险： 每个集群独立演进，版本差异可能导致跨集群调度失败或资源不兼容。
关键区别： ClusterSet 没有单点故障，但版本一致性保障最弱。每个集群可以独立升级，但跨集群资源依赖需要版本兼容性校验。
5. 三种模式的版本差异风险对比
| 风险维度 | Hub-Spoke | Federation | ClusterSet |
|---|---|---|---|
| API 版本不一致 | Hub 与 Spoke 之间 | 成员集群之间 | 所有成员之间 |
| CRD 版本差异 | Hub 推送时校验 | Federation 同步时校验 | 对等同步时校验 |
| 资源字段丢失 | Spoke 版本低时丢弃字段 | 回写时字段截断 | 跨集群调度时字段不兼容 |
| 故障恢复复杂度 | 低（重启 Hub 即可） | 中（需重建 Federation 状态） | 高（需逐集群修复） |
6. 选型建议与版本校验切入点
在实际项目中，拓扑模式的选择直接影响版本差异校验策略：
- Hub-Spoke： 适合版本校验集中在 Hub 侧，通过准入 Webhook 拦截不兼容资源。
- Federation： 适合在 Federation 控制面中增加版本兼容性检查器。
- ClusterSet： 适合在每个集群的入口处做版本校验，或通过 Service Mesh 做协议兼容。