3. 多集群架构基础：Hub-Spoke、Federation、Cluster API 等常见多集群管理架构对比
在构建企业级云原生平台时，单一 Kubernetes 集群往往无法满足隔离性、地域分布、合规要求或规模扩展的需求。多集群管理架构应运而生，但不同架构在控制面复杂度、运维开销、故障隔离和发布一致性上差异显著。本章聚焦三种主流多集群管理架构——Hub-Spoke、Federation 和 Cluster API，从设计理念、控制流、适用场景和 Operator 发布适配性四个维度进行系统对比。
3.1 Hub-Spoke 架构：中心管控，边缘执行
Hub-Spoke（中心-辐射）是目前生产环境中最广泛采用的多集群管理模型。其核心思想是：一个中心集群（Hub）作为控制面，负责策略下发、资源分发和状态聚合；多个工作集群（Spoke）仅运行工作负载，不直接暴露控制面给用户。
关键特征： Hub 集群不运行业务 Pod，只运行管理组件（如 OCM、Karmada 的调度器、ArgoCD 的 ApplicationSet Controller）；Spoke 集群通过 Agent 或 Pull 模式与 Hub 通信，避免 Hub 故障影响 Spoke 已有工作负载。
3.1.1 典型实现与 Operator 发布适配
- Open Cluster Management (OCM)： 通过 ManifestWork 将资源分发到 Spoke，支持 Work 级别的回滚和状态反馈。
- Karmada： 提供 ResourceTemplate 和 PropagationPolicy，支持跨集群差异化配置和灰度发布。
- ArgoCD + ApplicationSet： 利用 Pull 模式在每个 Spoke 部署 ArgoCD Agent，Hub 端 ApplicationSet 根据集群列表生成 Application。
Operator 发布建议： 在 Hub-Spoke 架构中，Operator 本身应部署在 Hub 集群，通过 OLM 的 MultiNamespace 模式或手动配置，将 Operator 的 CRD 和 Controller 分发到 Spoke。回滚时只需在 Hub 端调整 PropagationPolicy 或 Work 的版本字段，Spoke 端自动同步。
3.2 Federation 架构：联邦控制面，全局一致
Federation（联邦）架构通过一个逻辑上的联邦控制面，将多个集群抽象为一个统一的资源池。Kubernetes Federation v2（KubeFed）是此模型的代表。与 Hub-Spoke 不同，Federation 强调跨集群资源模板化和调度策略的声明式管理。
注意： KubeFed 项目已进入维护模式，社区推荐迁移至 Karmada 或 OCM。但 Federation 的设计思想（Template + Placement + Override）仍被广泛借鉴。
3.2.1 Federation 的 Operator 发布局限
- CRD 同步问题： Federation 不会自动同步 CRD，需要手动在每个成员集群安装相同版本的 CRD。
- 状态反馈延迟： 联邦资源的状态聚合存在时间窗口，Operator 的回滚决策可能基于过时状态。
- Override 复杂度： 当不同集群需要差异化配置时，Override 策略的维护成本随集群数量线性增长。
3.3 Cluster API：声明式集群生命周期管理
Cluster API（CAPI）是 Kubernetes SIG 推出的声明式集群管理项目，专注于集群的创建、升级、扩缩容和销毁。与前两种架构不同，CAPI 不直接管理跨集群的资源分发，而是将集群本身视为 Kubernetes 资源（Cluster 对象），通过 Provider 模式对接不同基础设施（AWS、vSphere、OpenStack 等）。
核心价值： 将集群的运维操作（如升级 Kubernetes 版本、替换 Worker 节点）标准化为声明式 API，非常适合需要频繁创建/销毁集群的 CI/CD 场景（如 Preview Environment、Ephemeral Cluster）。
3.3.1 Cluster API 架构组件
| 组件 | 职责 | 与 Operator 发布的关系 |
|---|---|---|
| Management Cluster | 运行 CAPI Controller，管理所有 Workload Cluster 的生命周期 | Operator 的 CRD 和 Controller 需部署在此集群 |
| Workload Cluster | 运行实际业务负载，由 Management Cluster 通过 Bootstrap Provider 创建 | Operator 通过 ClusterResourceSet 或手动安装到 Workload Cluster |
| Infrastructure Provider | 对接云/虚拟化平台，管理虚拟机、网络、存储等资源 | 不直接参与 Operator 发布，但影响集群创建速度 |
| Bootstrap Provider | 生成集群初始化所需的 cloud-init 或 kubeadm 配置 | 可在初始化阶段注入 Operator 的 Helm Chart 或 Manifest |
3.4 三种架构对比总结
| 维度 | Hub-Spoke | Federation | Cluster API |
|---|---|---|---|
| 控制面位置 | Hub 集群 | 独立联邦控制面 | Management 集群 |
| 资源分发方式 | Push / Pull 策略下发 | 双向同步 | 不直接分发资源，只管理集群 |
| 故障隔离 | 高（Hub 故障不影响 Spoke 存量） | 低（控制面故障导致全局不可更新） | 中（Management 故障不影响已有 Workload 集群） |
| Operator 发布适配 | 优（通过 ManifestWork / ApplicationSet 分发） | 中（需手动处理 CRD 同步和 Override） | 良（通过 ClusterResourceSet 或 Bootstrap 注入） |
| 回滚粒度 | Work / Application 级别 | FederatedResource 级别 | Cluster 级别（回滚集群版本或重建） |
| 典型场景 | 生产多集群策略管控、灰度发布 | 跨集群资源模板化（已逐步被替代） | CI/CD 临时集群、集群升级、混合云集群生命周期 |
3.5 架构选型建议
- 如果你需要长期稳定的多集群策略管控和 Operator 发布： 优先选择 Hub-Spoke 架构（OCM 或 Karmada），故障隔离好，回滚机制成熟。
- 如果你的场景需要频繁创建/销毁集群（如 Preview Environment、E2E 测试集群）： 选择 Cluster API，将集群生命周期与 CI/CD 流水线深度集成。
- 避免直接使用 Federation v2： 除非已有存量系统，否则建议迁移至 Karmada 或 OCM，它们继承了 Federation 的模板化思想，同时解决了故障隔离和 CRD 同步问题。
本课程后续章节将基于 Hub-Spoke 架构（Karmada + OCM）展开 Operator 发布与回滚策略的自动化验证。 选择 Hub-Spoke 是因为它在生产环境中的成熟度最高，且回滚策略的验证逻辑最清晰——只需在 Hub 端调整分发策略，Spoke 端即可自动收敛到期望状态。