多集群架构概述

在云原生环境下，单一 Kubernetes 集群已难以满足大规模、跨地域、高可用的业务需求。多集群架构通过将工作负载分布到多个集群中，实现资源隔离、故障域分离和就近接入。本章从部署模式、联邦机制、Hub-Spoke 拓扑及管理挑战四个维度，系统梳理多集群架构的核心概念。

2.1 多集群部署模式

根据集群间的关系与通信方式，多集群部署通常分为以下三种模式：

2.2 联邦集群

Kubernetes 联邦（KubeFed / Karmada / Clusternet）通过一个逻辑控制面将多个集群抽象为统一资源池。联邦控制面负责将模板化资源（如 Deployment、Service）同步到目标集群，并支持差异化覆盖（Overrides）。

• 资源模板：定义跨集群通用的资源规格。
• 调度策略：指定资源应分发到哪些集群，以及副本分布权重。
• 覆盖策略：允许针对特定集群调整镜像版本、副本数、标签等字段。
• 状态收集：聚合各成员集群的资源状态，反馈到联邦控制面。

2.3 Hub-Spoke 架构

Hub-Spoke 是目前生产环境中最主流的多集群管理模式。Hub 集群作为管理枢纽，不运行业务 Pod，仅承载控制面组件（如策略引擎、监控聚合、GitOps 控制器）；Spoke 集群运行实际业务负载，通过 Agent 与 Hub 通信。

2.4 多集群管理挑战

多集群架构在带来弹性和容灾能力的同时，也引入了以下核心挑战：

1. 网络连通性与延迟：跨集群通信依赖稳定网络，VPN 或专线成本高，延迟波动影响联邦同步效率。
2. 资源同步一致性：联邦控制面与成员集群之间的资源状态可能因网络分区或版本差异产生偏差，需要定期 Reconcilation。
3. 安全与权限隔离：每个集群的 RBAC、ServiceAccount、证书需要独立管理，Hub 对 Spoke 的访问需最小权限原则。
4. 可观测性碎片化：各集群的监控指标、日志、事件分散存储，需要统一聚合层（如 Thanos / Grafana Mimir）才能获得全局视图。
5. SLO 运营复杂度：跨集群的 SLO 定义、指标采集、燃烧速率计算需要标准化模板，否则难以对齐业务目标。

2.5 架构选型对照

下表从运维复杂度、一致性要求、规模上限三个维度对比三种多集群模式，帮助你在实际项目中快速决策：