2、多集群架构模式：Hub-Spoke（中心-叶子）架构、联邦架构、双活/主备架构、混合云架构的对比与选型
多集群落地时，架构模式的选择直接决定了运维复杂度、资源利用率、故障隔离能力和成本。本章对四种主流模式进行深度对比，帮助你在不同业务场景下做出合理选型。
2.1 Hub-Spoke（中心-叶子）架构
Hub-Spoke 是最常用的多集群管控模式，由一个中心集群（Hub）统一管理多个叶子集群（Spoke）。中心集群不运行业务负载，只负责策略下发、资源分发和状态聚合。
适用场景：企业级多环境管理（开发/测试/生产）、边缘计算场景、多区域统一管控。
2.2 联邦架构（Federation）
联邦架构通过一个联邦控制面将多个集群抽象为单一资源池，实现跨集群调度和全局负载均衡。KubeFed（Kubernetes Federation）是典型实现。
注意：联邦架构的同步延迟和资源冲突是常见痛点。建议仅在需要全局调度和跨集群服务发现的场景使用，避免过度抽象。
2.3 双活/主备架构
双活架构下，多个集群同时承载业务流量，实现负载分担和故障自动切换。主备架构则是一个集群承载流量，另一个集群冷备或温备。
| 对比维度 | 双活架构 | 主备架构 |
|---|---|---|
| 资源利用率 | 高（所有集群承载流量） | 低（备集群闲置或低负载） |
| 切换时间 | 秒级（DNS/负载均衡切换） | 分钟级（数据同步 + 启动服务） |
| 数据一致性 | 需要分布式事务或最终一致性 | 主备同步，一致性较高 |
| 运维复杂度 | 高（需处理会话保持、数据冲突） | 中（需监控同步状态） |
| 成本 | 高（双倍资源） | 中（备集群可降配） |
| 适用场景 | 高可用要求极高、可接受最终一致性 | 合规要求严格、数据强一致性需求 |
避坑指南：双活架构中，务必在应用层做好幂等设计和冲突处理。主备架构中，定期演练切换流程，避免备集群长期不启用导致配置漂移。
2.4 混合云架构
混合云架构将私有云和公有云集群统一管理，实现资源弹性伸缩和成本优化。通常结合 Hub-Spoke 或联邦模式实现管控。
2.5 四种架构对比与选型矩阵
| 选型维度 | Hub-Spoke | 联邦架构 | 双活/主备 | 混合云 |
|---|---|---|---|---|
| 管控复杂度 | 低（中心化管控） | 高（双向同步） | 中（切换策略） | 中高（多云适配） |
| 故障隔离 | 好（叶子自治） | 中（联邦控制面单点） | 好（自动切换） | 好（跨云隔离） |
| 资源利用率 | 中（叶子独立） | 高（全局调度） | 中低（备集群闲置） | 高（弹性伸缩） |
| 数据一致性 | 最终一致 | 最终一致 | 强一致（主备） | 最终一致 |
| 网络要求 | 低（Hub 到 Spoke） | 高（全互联） | 中（主备同步） | 高（跨云互通） |
| 典型工具 | Rancher、ACM、OCM | KubeFed、Karmada | Velero、KubeStash | AWS EKS Anywhere、GKE |
| 推荐场景 | 多环境管理、边缘计算 | 全局调度、跨集群服务 | 核心数据库、合规场景 | 弹性伸缩、成本优化 |
2.6 选型决策流程
- 明确业务目标：高可用？资源弹性？统一管控？合规要求？
- 评估集群数量：少于 5 个集群优先考虑 Hub-Spoke；超过 10 个集群考虑联邦或混合云。
- 分析数据一致性需求：强一致性场景优先主备架构；最终一致性场景可考虑双活或联邦。
- 评估网络条件：跨区域延迟高、带宽有限时，Hub-Spoke 更友好；全互联网络可选联邦架构。
- 考虑团队能力：运维团队规模小优先 Hub-Spoke；有平台工程团队可挑战联邦或混合云。
最佳实践：大多数企业从 Hub-Spoke 起步，随着规模增长逐步引入联邦或混合云能力。避免一开始就追求复杂架构，优先解决当前最痛的问题。