2. 跨集群调度基础：Kubernetes多集群架构模式
在云原生环境中，单一Kubernetes集群已无法满足大规模、高可用、多区域部署的需求。跨集群调度依赖底层多集群架构的设计，不同的架构模式决定了调度策略的复杂度、控制面开销以及故障隔离边界。本节深入剖析三种主流多集群架构模式：Hub-Spoke、Federation 与 Cluster API，并对比其适用场景与调度特性。
2.1 Hub-Spoke 架构：中心辐射模式
Hub-Spoke 是目前生产环境中最广泛采用的多集群架构。一个中心集群（Hub）作为控制与调度入口，多个工作集群（Spoke）承载实际业务负载。Hub 集群不运行用户工作负载，仅负责策略下发、资源分发与状态聚合。
核心特征： Hub 集群持有所有 Spoke 集群的 kubeconfig 凭证，通过
work 或 manifest 对象将资源推送到远端集群；Spoke 集群仅需运行一个轻量级 Agent（如 klusterlet）即可接收指令。
生产建议： Hub-Spoke 架构天然适合变更门禁场景。可以在 Hub 侧集中配置 Admission Webhook，对所有发往 Spoke 的资源进行合规校验、金丝雀比例控制与 Helm Chart 渲染验证，避免在每个 Spoke 集群重复部署门禁组件。
2.2 Federation 架构：联邦控制平面
Kubernetes Federation（KubeFed）通过引入一个独立的联邦控制平面，将多个集群抽象为一个统一的资源池。用户向联邦 API 提交资源，联邦控制器负责将资源同步到所有成员集群，并支持跨集群副本分布与覆盖策略。
| 维度 | Hub-Spoke | Federation (KubeFed) |
|---|---|---|
| 控制面位置 | Hub 集群内 | 独立联邦控制平面 |
| 资源分发方式 | Push 模式（Hub 主动推送） | Pull 模式（成员集群主动拉取） |
| 调度粒度 | 按集群标签/污点调度 | 按 ReplicaSchedulingPreference 分布 |
| 故障隔离 | Spoke 故障不影响 Hub | 联邦控制平面故障影响全局 |
| 变更门禁集成 | Hub 侧集中式 Webhook | 联邦 API 层 Webhook + 成员集群本地 Webhook |
| 生产成熟度 | 高（OpenShift ACM、Karmada） | 中（社区版已停止演进） |
注意： 社区 KubeFed 项目已进入维护模式，不再新增特性。生产环境建议优先考虑基于 Hub-Spoke 的成熟实现（如 Karmada、OpenShift ACM、华为 KubeEdge），或直接使用 Cluster API 进行集群生命周期管理。
2.3 Cluster API：声明式集群生命周期
Cluster API（CAPI）是 CNCF 孵化的项目，旨在通过 Kubernetes 原生 API 声明式地管理集群的创建、升级、扩缩容与销毁。它不直接解决跨集群调度问题，而是为调度提供动态集群池——调度器可以根据负载需求，通过 CAPI 自动创建或回收集群。
调度集成方式： 跨集群调度器通过 CAPI 的
Cluster 资源自动发现可用集群及其版本、节点规格、区域标签。当调度器检测到现有集群资源不足时，可触发 CAPI 创建新集群；当集群利用率低于阈值时，可缩容或回收集群，实现调度驱动的弹性集群池。
2.4 架构模式对比与选型
| 评估维度 | Hub-Spoke | Federation | Cluster API |
|---|---|---|---|
| 调度控制力 | 强（集中策略） | 中（联邦策略） | 弱（仅提供集群清单） |
| 集群生命周期 | 手动管理 | 手动管理 | 声明式自动管理 |
| 变更门禁集成 | ⭐ 最佳（单点控制） | ⭐ 良好（双层校验） | ⭐ 需额外组件 |
| 故障半径 | 小（Spoke 独立） | 大（联邦平面单点） | 小（管理集群可重建） |
| 学习成本 | 低 | 中 | 高 |
| 推荐场景 | 生产多区域部署、变更门禁 | 历史遗留联邦迁移 | 动态集群池、CI/CD 环境 |
选型建议： 对于本课程关注的变更门禁故障排查场景，Hub-Spoke 架构是最佳基础。它允许在 Hub 侧集中部署 Admission Webhook、Helm 渲染校验、金丝雀发布策略，故障排查时只需定位 Hub 控制面日志与 Spoke Agent 状态，链路清晰。后续章节的故障排查案例均基于 Hub-Spoke 架构展开。