3. 多集群架构基础：集群联邦、Hub-Spoke架构、管理集群与工作集群
在进入 GitOps 多集群配置一致性方案之前，必须先理解支撑多集群管理的几种核心架构模式。不同的架构决定了控制流、数据流以及故障隔离的边界。本章将系统梳理集群联邦、Hub-Spoke 架构、管理集群与工作集群的概念、适用场景及关键差异。
3.1 多集群管理的核心挑战
当组织从单集群演进到多集群时，面临以下共性难题：
- 控制面分散：每个集群独立运维，缺乏统一的策略下发入口。
- 配置漂移：手动维护多个集群的配置，极易出现版本不一致。
- 网络与拓扑异构：跨区域、跨云集群的网络延迟与安全策略不同。
- 资源视图割裂：无法在一个地方查看所有集群的运行状态。
为了解决这些问题，业界演化出两种主流架构：集群联邦（Federation） 与 Hub-Spoke（中心辐射） 架构。理解它们的区别是设计多集群 GitOps 流水线的前提。
3.2 集群联邦架构（Federation）
集群联邦通过一个联邦控制面将多个 Kubernetes 集群抽象为一个逻辑集群。用户向联邦 API 提交资源，联邦控制器负责将资源分发到成员集群。
核心特征： 联邦层提供统一的 API 入口，支持跨集群服务发现与资源调度。典型实现包括 KubeFed（Kubernetes Federation v2）。
适用场景： 需要跨集群服务发现（如跨集群 DNS）、统一 RBAC 策略、以及资源在多个集群间按权重调度的场景。但联邦控制面本身存在单点风险，且对网络延迟敏感。
3.3 Hub-Spoke 架构
Hub-Spoke 架构是目前生产环境中最主流的多集群管理模式。一个中心集群（Hub） 作为控制枢纽，管理多个工作集群（Spoke）。Hub 集群不运行业务负载，只负责策略下发、配置分发与状态收集。
核心特征： 控制流与数据流分离。Hub 集群承载控制面，工作集群承载业务负载。典型实现包括 Open Cluster Management（OCM）、Rancher、Karmada。
适用场景： 大规模生产环境（50+ 集群）、跨云/混合云管理、需要严格租户隔离的场景。Hub-Spoke 架构天然支持 GitOps 的“声明式配置从 Hub 推送到 Spoke”模式。
3.4 管理集群与工作集群的职责划分
在 Hub-Spoke 架构中，管理集群 与 工作集群 的职责有严格边界。下表列出关键差异：
| 维度 | 管理集群（Hub） | 工作集群（Spoke） |
|---|---|---|
| 核心职责 | 策略下发、配置分发、状态聚合、审计日志 | 运行业务容器、处理用户请求、存储数据 |
| 运行组件 | GitOps Controller、Policy Engine、Metrics Server | 业务 Deployment、DaemonSet、CSI 驱动 |
| 网络暴露 | 通常不对外暴露，仅内部 API Server | 对外暴露 Ingress/LB，接收用户流量 |
| 故障影响 | 管理集群故障不影响已有业务运行 | 工作集群故障仅影响本集群业务 |
| 扩缩容 | 按管理规模水平扩展 | 按业务负载弹性伸缩 |
3.5 架构选型对比
以下表格帮助你在实际项目中快速决策：
| 评估维度 | 集群联邦 | Hub-Spoke |
|---|---|---|
| 控制面复杂度 | 高（联邦 API 层抽象） | 中（Hub 集群独立部署） |
| 网络要求 | 成员集群间需互通 | Spoke 可单向访问 Hub |
| 配置一致性 | 强（联邦层保证） | 最终一致（GitOps 驱动） |
| 故障隔离 | 联邦控制面单点 | Hub 故障不影响 Spoke 运行 |
| GitOps 集成 | 需额外适配 | 天然支持（Hub 运行 GitOps Operator） |
| 生产案例 | 较少（多用于跨集群调度） | 主流（OCM、Rancher、Karmada） |
避坑提示： 不要将管理集群与工作集群混部。混部会导致控制面资源被业务 Pod 抢占，在业务高峰期可能引发管理组件 OOM，进而导致整个多集群管理面瘫痪。始终为管理集群预留独立的节点池或专用集群。
3.6 本章小结
- 集群联邦 提供统一的 API 抽象，适合需要跨集群服务发现与资源调度的场景，但控制面复杂度高。
- Hub-Spoke 架构 是生产环境多集群管理的事实标准，控制流与数据流分离，故障隔离性好。
- 管理集群 只运行管理组件，工作集群 只运行业务负载，职责边界清晰。
- 在后续章节中，我们将基于 Hub-Spoke 架构设计 GitOps 配置一致性基线核验方案。