2. 多集群架构基础:Hub-Spoke、Federation、Cluster API 等常见多集群管理模型对比

在设计多集群 Operator 发布流水线之前,必须理解底层多集群管理模型。不同的模型决定了控制面的拓扑、资源传播方式、故障隔离边界以及回滚的粒度。本章聚焦三种主流模型:Hub-Spoke、Federation 与 Cluster API,从架构、适用场景、回滚能力三个维度进行对比。

2.1 Hub-Spoke 模型

Hub-Spoke 是目前生产环境中最广泛采用的多集群管理模型。其核心思想是:一个中心集群(Hub)作为控制面,多个工作集群(Spoke)作为数据面。Hub 集群运行 Operator、策略控制器、调度器,Spoke 集群仅运行工作负载。

关键特征: Hub 集群不承载业务 Pod,只负责编排与分发;Spoke 集群与 Hub 之间通过单向或双向的 API 聚合通信。
Hub-Spoke 多集群架构 Hub 集群 控制面 / Operator / 策略 Spoke 集群 A 工作负载 / 业务 Pod Spoke 集群 B 工作负载 / 业务 Pod Spoke 集群 C 工作负载 / 业务 Pod 说明:Hub 通过 API 聚合或推送方式向 Spoke 分发资源; 回滚时只需在 Hub 上调整版本,Spoke 自动同步。

Hub-Spoke 回滚特点

  • 中心化回滚: 在 Hub 集群上修改资源版本或 Operator 配置,通过同步机制(如 GitOps 或 Work API)下发到所有 Spoke。
  • 灰度回滚: 可对单个 Spoke 集群执行回滚,不影响其他集群。
  • 依赖: 需要 Hub 集群高可用,否则回滚指令无法下发。

2.2 Federation 模型(KubeFed)

Federation 模型通过一个联邦控制面将多个集群抽象为统一资源池。KubeFed(Kubernetes Federation)是典型实现,它使用 FederatedResource 和 PlacementPolicy 控制资源在成员集群间的分布。

适用场景: 需要跨集群统一管理 Deployment、Service、ConfigMap 等资源,且希望保持成员集群自治性。
Federation(KubeFed)多集群模型 联邦控制面(KubeFed) FederatedResource / PlacementPolicy 成员集群 1 自治 K8s 集群 成员集群 2 自治 K8s 集群 成员集群 3 自治 K8s 集群 说明:联邦控制面通过 FederatedResource 模板 + PlacementPolicy 决定资源分发; 回滚时需更新联邦资源版本,并确保所有成员集群同步。

Federation 回滚特点

  • 模板驱动回滚: 修改 FederatedResource 模板中的版本号,联邦控制器自动协调所有成员集群。
  • 策略约束: 回滚范围受 PlacementPolicy 限制,可指定只回滚部分集群。
  • 状态回传: 成员集群回滚状态通过 FederatedResourceStatus 回传,便于流水线判断。

2.3 Cluster API 模型

Cluster API 是 Kubernetes 官方项目,用于声明式管理集群的创建、升级、扩缩容和销毁。它通过 Cluster、Machine、MachineDeployment 等 CRD 将基础设施抽象为 Kubernetes 资源。

注意: Cluster API 管理的是集群本身的生命周期,而非集群内的应用。Operator 发布流水线通常运行在 Cluster API 创建的集群之上。
Cluster API 多集群管理模型 管理集群(Management Cluster) Cluster API Controller / Provider 工作负载集群 1 Machine / Cluster 资源 工作负载集群 2 Machine / Cluster 资源 工作负载集群 3 Machine / Cluster 资源 说明:Cluster API 管理集群的创建/升级/销毁;Operator 发布流水线 可结合 ClusterClass 实现集群级回滚(如回退 MachineDeployment 版本)。

Cluster API 回滚特点

  • 集群级回滚: 通过回退 MachineDeployment 的版本或镜像,可实现集群节点级别的回滚。
  • 与 Operator 流水线解耦: Cluster API 不管理应用,Operator 回滚需在应用层独立实现。
  • 基础设施一致性: 回滚集群版本时,需确保与 Operator 兼容,否则可能导致控制面不匹配。

2.4 三种模型对比总结

维度 Hub-Spoke Federation (KubeFed) Cluster API
管理对象 应用资源 / Operator 应用资源 集群基础设施
控制面位置 Hub 集群 联邦控制面(独立或托管) 管理集群
资源分发方式 推送 / 拉取(GitOps) 模板 + PlacementPolicy 声明式 Machine/Cluster
回滚粒度 单集群 / 全局 按 PlacementPolicy 范围 集群版本 / MachineDeployment
回滚触发 Hub 资源版本变更 FederatedResource 更新 MachineDeployment spec 回退
Operator 回滚支持 原生支持(Operator 在 Hub 上) 需额外编排 不直接支持(需应用层处理)
生产成熟度 高(广泛使用) 中(社区活跃度下降) 高(CNCF 孵化项目)

2.5 模型选择建议

  • 优先选择 Hub-Spoke:如果你的 Operator 发布流水线需要中心化控制、灰度回滚和 GitOps 集成,Hub-Spoke 是最成熟的选择。
  • Federation 适用于存量多集群统一管理:当已有多个自治集群且需要统一资源模板时,KubeFed 可减少重复配置,但回滚复杂度较高。
  • Cluster API 用于集群生命周期管理:当需要自动化创建/升级/回滚集群本身时使用,Operator 发布流水线应在其之上独立构建。