2. 多集群架构基础：主流多集群管理模型对比
在进入多集群弹性伸缩运营之前，必须先理解多集群架构的几种主流管理模型。不同的模型决定了控制面部署位置、资源同步方式、故障隔离边界以及运维复杂度。本章从架构原理、适用场景、关键差异三个维度，对比 Hub-Spoke、Federation 和 Cluster API 三种模型。
2.1 Hub-Spoke 模型：中心辐射式管理
Hub-Spoke 是最广泛采用的多集群管理模型，核心思想是：一个中心集群（Hub）作为控制面，多个工作集群（Spoke）作为数据面。Hub 集群不运行业务负载，只负责策略下发、资源分发、状态收集和运维调度。
核心特征：
- 控制面与数据面分离：Hub 仅承载管理组件，Spoke 运行实际业务。
- 单向或双向注册：Spoke 集群通过 Agent 向 Hub 注册，Hub 通过 API 代理访问 Spoke。
- 资源分发：Hub 将 Workload、ConfigMap、Secret 等资源推送到指定 Spoke。
- 状态聚合：Spoke 将节点、Pod、事件等状态上报至 Hub。
典型实现：Open Cluster Management (OCM)、Karmada、Rancher、Anthos Config Management 均采用或兼容 Hub-Spoke 模型。
2.2 Federation 模型：联邦控制面
Federation（联邦）模型通过一个独立的联邦控制面，将多个 Kubernetes 集群抽象为一个逻辑集群。用户向联邦 API 提交资源，联邦控制面负责将资源同步到所有成员集群。Kubernetes 社区早期的 KubeFed（Kubernetes Federation v2）是此模型的代表实现。
| 维度 | Hub-Spoke | Federation (KubeFed) |
|---|---|---|
| 控制面位置 | Hub 集群内 | 独立联邦控制面（可部署在任意集群） |
| 资源同步 | 推模式（Hub → Spoke） | 拉模式或推模式（联邦控制面 → 成员集群） |
| 策略粒度 | 按集群、按命名空间、按标签 | 按集群、按集群区域、按集群提供方 |
| 状态反馈 | Spoke 主动上报 | 联邦控制面轮询成员集群 |
| 典型规模 | 数百集群 | 数十集群（性能瓶颈在联邦 API） |
| 社区活跃度 | 高（OCM、Karmada 持续迭代） | 低（KubeFed 已进入维护模式） |
注意：KubeFed 在 Kubernetes 1.20 之后进入维护状态，不再增加新特性。新项目建议优先评估 Hub-Spoke 模型或 Cluster API 模型。
2.3 Cluster API 模型：声明式集群生命周期管理
Cluster API（CAPI）是 Kubernetes SIG Cluster-Lifecycle 主导的官方项目，核心目标是用 Kubernetes 风格的声明式 API 管理集群的创建、扩缩容、升级、销毁全生命周期。Cluster API 本身不直接管理多集群资源分发，而是专注于集群基础设施的自动化。
Cluster API 核心资源对象：
- Cluster：声明一个集群的期望状态（包括控制面、工作节点、网络等）。
- Machine：对应一个节点（物理机或虚拟机），由 Infrastructure Provider 实现。
- MachineDeployment：类似 Deployment，管理一组 Machine 的滚动更新和扩缩容。
- MachineSet：类似 ReplicaSet，提供副本管理。
- Infrastructure Provider：对接 AWS、Azure、GCP、vSphere 等具体基础设施。
2.4 三种模型对比总结
| 对比维度 | Hub-Spoke | Federation (KubeFed) | Cluster API |
|---|---|---|---|
| 核心目标 | 多集群资源分发与策略管理 | 多集群资源同步与联邦抽象 | 集群生命周期自动化 |
| 控制面位置 | Hub 集群 | 独立联邦控制面 | 管理集群 |
| 资源分发 | 原生支持（推模式） | 原生支持（推/拉模式） | 不涉及（需配合其他工具） |
| 集群创建/扩缩 | 需外部工具 | 需外部工具 | 原生支持（声明式） |
| 故障隔离 | 强（Spoke 独立） | 中（联邦控制面单点） | 强（每个集群独立） |
| 运维复杂度 | 中 | 高 | 中高（需管理 Infrastructure Provider） |
| 推荐场景 | 生产多集群策略管理、弹性伸缩 | 历史遗留联邦需求 | 集群自服务、混合云集群生命周期 |
2.5 模型选型建议
在实际的多集群弹性伸缩运营中，三种模型并非互斥，而是可以组合使用：
- Cluster API + Hub-Spoke：使用 Cluster API 自动化创建和扩缩 Spoke 集群，使用 Hub-Spoke 模型管理资源分发和策略下发。这是当前社区推荐的主流组合。
- Federation 迁移路径：如果已有 KubeFed 部署，建议逐步迁移到 Karmada（Hub-Spoke 变体）或 OCM，以获得更好的性能和社区支持。
- 纯 Cluster API 场景：如果只需要集群生命周期管理，不需要跨集群资源分发，可以单独使用 Cluster API。