1. 多集群架构概述
1.1 多集群的定义
多集群（Multi-Cluster）是指组织同时管理两个或两个以上 Kubernetes 集群的架构模式。这些集群可以部署在相同或不同的云提供商、本地数据中心或边缘环境中，并通过统一的控制平面或工具链进行协调与管理。
多集群的核心特征包括：
- 独立控制面：每个集群拥有独立的 API Server、etcd 和控制器管理器。
- 网络隔离：集群间默认不共享 Pod/Service 网络，需通过 CNI 插件或服务网格打通。
- 统一管理：通过上层调度器或联邦控制面实现跨集群的资源分发与策略治理。
- 版本异构：不同集群可运行不同 Kubernetes 版本、节点操作系统或容器运行时。
关键认知：多集群 ≠ 多租户。多租户是单个集群内的资源隔离，多集群是多个独立集群的协同编排。
1.2 为什么需要多集群
单一集群在规模、可用性、合规性和业务隔离方面存在天然上限。以下是推动多集群架构落地的核心驱动力：
| 驱动因素 | 单集群瓶颈 | 多集群优势 |
|---|---|---|
| 故障域隔离 | etcd 或控制面故障导致全局不可用 | 单个集群故障不影响其他集群，爆炸半径可控 |
| 地理分布 | 跨地域延迟高，无法满足就近接入 | 按区域部署集群，用户流量就近路由，降低延迟 |
| 合规与数据主权 | 数据存储位置无法按法规限定 | 集群绑定特定区域，数据不出域，满足 GDPR 等要求 |
| 规模上限 | 单集群节点数超过 5000 时控制面压力剧增 | 水平拆分，每个集群保持在推荐规模内 |
| 环境隔离 | 开发/测试/生产混部，风险不可控 | 独立集群承载不同环境，互不干扰 |
| 版本演进 | 升级失败导致全集群回滚 | 灰度升级，部分集群先行验证，降低升级风险 |
版本漂移场景：在多集群环境中，不同集群可能运行 v1.20、v1.24、v1.28 等不同 Kubernetes 版本。当工作负载在集群间迁移时，API 资源的弃用、CRD 版本差异、调度器行为变化都会导致"版本漂移"问题，这正是本课程要校准验证的核心课题。
1.3 多集群的典型拓扑
当前业界主流的多集群拓扑有三种模式：Hub-Spoke（中心辐射型）、Federation（联邦型） 和 独立集群型。三种模式在控制面耦合度、调度灵活性和运维复杂度上各有取舍。
1.3.1 Hub-Spoke 拓扑
Hub-Spoke 是最广泛采用的多集群模式。一个中心集群（Hub）作为管理入口，多个工作集群（Spoke）注册到 Hub，由 Hub 统一分发资源、监控状态和执行策略。
Hub-Spoke 的典型特征：
- 控制面集中：Hub 集群运行 Karmada、Clusternet 或 OCM 等多集群管理组件。
- 工作负载分散：Spoke 集群只运行业务 Pod，不承担跨集群调度逻辑。
- 网络可选打通：Spoke 间可通过 Submariner 或 Cilium ClusterMesh 实现东西向通信。
- 版本漂移敏感：Hub 下发的资源模板需兼容所有 Spoke 集群的 Kubernetes 版本。
1.3.2 Federation 拓扑
Federation（联邦）通过一个联邦控制面将多个集群抽象为单一资源池，用户向联邦 API 提交资源，联邦控制器负责将资源同步到成员集群。KubeFed（Kubernetes Federation v2）是此模式的典型实现。
Federation 与 Hub-Spoke 的关键区别：
| 对比维度 | Hub-Spoke | Federation |
|---|---|---|
| 控制面位置 | Hub 集群内 | 独立联邦控制面（可部署在任意集群） |
| 资源同步方向 | Hub → Spoke（单向推送） | 联邦 ↔ 成员（双向同步） |
| 调度粒度 | 支持按集群权重、实例数分发 | 支持按标签、区域、Provider 调度 |
| 版本漂移处理 | Hub 需感知 Spoke 版本，做模板转换 | 联邦控制面内置版本映射表，自动转换 |
| 典型项目 | Karmada, OCM, Clusternet | KubeFed, Admiralty |
1.3.3 独立集群拓扑
独立集群拓扑是最简单的多集群形态：每个集群完全自治，没有统一控制面。集群间通过 CI/CD 流水线、GitOps 工具（ArgoCD、Flux）或手动操作分别部署。这种模式适合开发/测试环境、完全隔离的生产环境或跨组织协作场景。
版本漂移风险最高：独立集群缺乏中央版本校验机制。运维人员需自行维护各集群的版本清单，并在跨集群迁移工作负载时手动校准 API 版本兼容性。本课程后续章节将重点解决此场景下的自动化校准方案。
三种拓扑的选型建议：
- 选择 Hub-Spoke：需要集中策略管控、统一监控告警，且集群数量在 10~100 之间。
- 选择 Federation：需要跨集群资源调度、版本自动转换，且团队有较强的控制面运维能力。
- 选择独立集群：集群数量少（<5）、环境隔离要求严格、或已有成熟的 GitOps 工具链。
1.4 版本漂移在多集群中的表现形式
在多集群环境中，版本漂移（Version Drift）主要表现为以下三种形态：
| 漂移类型 | 描述 | 典型影响 |
|---|---|---|
| API 版本漂移 | 不同集群对同一资源支持的 apiVersion 不同（如 apps/v1 vs extensions/v1beta1） | 资源提交失败、静默使用旧版本行为 |
| 调度器行为漂移 | 不同 K8s 版本的调度器在 Pod 优先级、污点容忍、拓扑分布策略上存在差异 | 跨集群调度结果不一致，Pod 分布不符合预期 |
| CRD 版本漂移 | 自定义资源定义（CRD）在集群间版本不同，或存储版本与 serving 版本不匹配 | CR 对象无法被正确解析，控制器崩溃 |