2、Multi-Cluster基础概念：集群联邦、Hub-Spoke架构、Global Control Plane、Cluster Registry
在深入资源模型驱动的控制平面高可用之前，必须先建立对 Multi-Cluster 基础架构的共识。本章将拆解四个核心概念：集群联邦（Cluster Federation）、Hub-Spoke 架构、Global Control Plane 和 Cluster Registry。它们是构建任何多集群系统的理论基石，也是后续章节讨论资源模型与高可用设计的共同语言。
2.1 集群联邦（Cluster Federation）
集群联邦是 Multi-Cluster 领域最早被广泛提出的抽象模式。其核心思想是：将多个物理或逻辑上独立的 Kubernetes 集群，通过一个统一的控制面进行编排，对外表现为一个“逻辑大集群”。
联邦模式通常分为两个层次：
- 资源联邦： 将 Kubernetes 原生资源（Deployment、ConfigMap、Secret）从联邦控制面分发到成员集群。典型实现为 KubeFed（Kubernetes Cluster Federation）。
- 服务联邦： 在资源联邦之上，解决跨集群的服务发现与负载均衡。例如，通过 DNS 或 Service Mesh 将流量路由到不同集群的后端 Pod。
| 维度 | 单集群 | 集群联邦（KubeFed） |
|---|---|---|
| 控制面数量 | 1 个 API Server | 1 个联邦 API Server + N 个成员集群 API Server |
| 资源作用域 | Namespace / Cluster | FederatedNamespace / FederatedDeployment |
| 调度决策 | 调度器绑定到 Node | 调度策略决定分发到哪些集群 |
| 故障隔离 | 控制面故障导致集群不可用 | 联邦控制面故障不影响已分发资源的运行 |
2.2 Hub-Spoke 架构
Hub-Spoke 是目前生产环境中最主流的 Multi-Cluster 架构模式。它引入一个中心化的 Hub 集群（又称管理集群），负责策略下发、资源调度和状态聚合；而 Spoke 集群（又称工作集群）只运行实际业务负载，与 Hub 保持控制面通信。
Hub-Spoke 架构的核心组件包括：
- Hub 集群： 运行 Multi-Cluster 控制面组件（如 Cluster Manager、Scheduler、Policy Engine）。
- Spoke 集群： 运行业务负载，通过 Agent 或反向连接与 Hub 通信。
- 控制面通道： 通常使用 VPN、Direct Connect 或公网 TLS 隧道，确保 Hub 到 Spoke 的 API 请求安全可达。
- 状态回传： Spoke 集群定期将资源状态、事件、Metrics 上报到 Hub，用于全局监控与调度。
2.3 Global Control Plane
Global Control Plane（全局控制面）是 Hub-Spoke 架构在逻辑上的进一步抽象。它不再局限于一个物理的 Hub 集群，而是一个由多个组件构成的、跨可用区部署的 逻辑控制面，负责管理所有成员集群的生命周期与资源调度。
Global Control Plane 通常包含以下关键服务：
- Global API Server： 统一入口，接收用户对多集群资源的操作请求。
- Global Scheduler： 根据资源需求、集群负载、地理位置、成本等因素，决定将工作负载调度到哪个成员集群。
- Global Controller Manager： 运行各类控制器，如 Cluster Lifecycle Controller、Resource Template Controller、Policy Controller。
- Cluster Registry： 维护所有成员集群的元数据、连接信息、健康状态（详见 2.4 节）。
2.4 Cluster Registry
Cluster Registry 是 Multi-Cluster 架构的“通讯录”与“健康档案”。它集中存储所有成员集群的注册信息、连接凭证、资源容量、健康状态和标签元数据。无论是 Hub-Spoke 还是 Global Control Plane，Cluster Registry 都是控制面做出调度和运维决策的基础数据源。
一个典型的 Cluster Registry 记录包含以下字段：
| 字段 | 类型 | 说明 |
|---|---|---|
| ClusterName | string | 集群唯一标识，如 prod-az1-cluster |
| APIEndpoint | string | 集群 API Server 的访问地址 |
| Credentials | secretRef | 连接集群所需的 或 Kubeconfig 引用 |
| Capacity | map[string]Quantity | 集群总资源量（CPU、Memory、GPU） |
| Allocatable | map[string]Quantity | 集群当前可分配资源量 |
| Labels | map[string]string | 自定义标签，用于调度选择（如 region=us-east, env=prod） |
| HealthStatus | enum | Healthy / Degraded / Unreachable |
| LastHeartbeat | timestamp | 最近一次心跳上报时间，用于判断集群是否失联 |
在资源模型驱动的 Multi-Cluster 架构中，Cluster Registry 不仅是静态的元数据存储，更是动态的“资源视图”。每个成员集群定期上报自身的资源水位、Pod 分布、节点状态，Registry 将这些信息聚合后提供给 Global Scheduler，用于做出最优的调度决策。