2. 多集群架构基础：Hub-Spoke架构、联邦集群、集群注册与发现机制
在多集群管理体系中，架构设计决定了控制面的耦合程度、数据面的流量路径以及运维的扩展边界。本章聚焦三种核心架构模式：Hub-Spoke（中心辐射）、联邦集群（Federation）以及支撑集群动态接入的注册与发现机制。理解这些架构是后续版本漂移检测与API废弃清单验收的前提。
2.1 Hub-Spoke 架构
Hub-Spoke 是目前生产环境中最广泛采用的多集群控制模型。一个中心集群（Hub）作为控制平面，负责策略下发、资源分发和状态聚合；多个工作集群（Spoke）仅运行用户负载，不直接暴露控制面 API 给外部。
核心特征：
- 控制面集中： Hub 集群承载所有多集群调度、策略引擎和审计日志。
- 数据面隔离： Spoke 集群之间网络不互通，仅通过 Hub 进行间接通信。
- 单向管控： Hub 向 Spoke 推送配置，Spoke 向 Hub 上报状态，反向流量受限。
生产建议： Hub 集群应部署在具备跨区域高可用能力的云区域或 IDC 核心节点。建议为 Hub 单独配备 etcd 集群，避免与 Spoke 工作负载争抢 I/O 资源。Hub 故障不应影响 Spoke 上已有应用的运行，但新策略下发会中断。
2.2 联邦集群（Federation）
联邦集群通过一个逻辑控制面将多个物理集群抽象为单一资源池。Kubernetes 社区主推的 KubeFed（Kubernetes Federation v2）是典型实现。联邦层负责将资源模板（Template）与放置策略（Placement Policy）同步到成员集群。
| 维度 | Hub-Spoke | 联邦集群（Federation） |
|---|---|---|
| 控制面位置 | 单一 Hub 集群 | 逻辑联邦控制面（可跨集群部署） |
| 资源同步 | Hub 主动推送 | 联邦控制器双向同步 |
| 策略粒度 | 集群级策略 | 支持命名空间级、标签选择器级 |
| 故障隔离 | Spoke 故障不影响 Hub | 联邦控制面故障影响所有成员 |
| 典型场景 | 边缘计算、多区域部署 | 多云统一调度、跨集群服务发现 |
版本漂移风险： 联邦集群在同步资源时，如果成员集群的 Kubernetes API 版本不一致，联邦控制器可能下发目标集群不支持的 API 资源（如
apps/v1beta1 在 v1.22+ 中已废弃）。这是交付前 API 废弃清单验收必须覆盖的检查点。
2.3 集群注册与发现机制
无论采用 Hub-Spoke 还是联邦架构，集群的动态注册与服务发现都是多集群管理的基础设施能力。注册机制决定了新集群如何加入管控范围；发现机制决定了控制面如何获取集群的实时端点与健康状态。
2.3.1 注册流程
- Agent 部署： 在目标集群中安装注册 Agent（如
cluster-register或klusterlet），Agent 生成集群唯一标识（Cluster ID）。 - 证书交换： Agent 向 Hub/联邦控制面发起 mTLS 握手，交换客户端证书，建立双向信任。
- 元数据上报： 集群名称、Kubernetes 版本、节点数量、可用区标签、API 资源列表等元数据写入控制面的集群注册表（Cluster Registry）。
- 心跳保活： Agent 定期发送心跳（默认 30s），控制面标记失联集群为
Unknown状态。
关键元数据字段示例：
apiVersion: clusterregistry.k8s.io/v1alpha1
kind: Cluster
metadata:
name: spoke-cluster-b
spec:
kubernetesVersion: "v1.26.3"
capacity:
nodes: "12"
totalCPU: "48"
totalMemory: "256Gi"
authInfo:
controller: "hub-controller"
certificateExpiry: "2026-06-30T00:00:00Z"2.3.2 发现机制对比
| 机制 | 实现方式 | 延迟 | 适用架构 |
|---|---|---|---|
| Push 模式 | Agent 主动上报端点变更 | < 1s | Hub-Spoke |
| Pull 模式 | 控制面定期轮询 Agent 健康接口 | 10s ~ 60s | 联邦集群 |
| DNS 发现 | 基于 CoreDNS 的 SRV 记录查询 | 取决于 TTL | 跨集群服务网格 |
| API 聚合层 | 扩展 API Server 代理到成员集群 | 实时 | Hub-Spoke（高级） |
验收关注点： 在交付前，必须验证集群注册表中的
kubernetesVersion 字段是否与实际集群版本一致。版本漂移往往源于注册时写入的版本信息未随集群升级而更新，导致后续 API 废弃检测基于错误版本进行。
2.4 架构选择与版本漂移的关系
三种架构对版本漂移的容忍度和检测路径不同：
- Hub-Spoke： Hub 集中维护所有 Spoke 的版本清单，适合做全局 API 废弃扫描。但 Spoke 版本差异过大时，Hub 下发的资源可能被 Spoke 拒绝。
- 联邦集群： 联邦控制面同步资源时不感知成员集群的 API 版本差异，容易产生“静默失败”——资源同步成功但成员集群无法解析。
- 注册与发现： 如果注册信息中的版本号与实际运行版本脱节，所有基于注册表的自动化验收工具都会产生误报或漏报。
交付前必查项： 无论采用哪种架构，都应在交付验收阶段执行一次“注册版本 vs 实际版本”的交叉校验。使用
kubectl version --short 在成员集群本地执行，并与控制面注册表中的版本字段比对。差异超过一个次要版本（如 v1.25 vs v1.27）时，应标记为版本漂移风险。