2. Kubernetes 多集群基础：多集群管理工具与集群生命周期
在进入版本漂移校准与跨集群调度测试之前，必须先建立多集群基础设施的管理认知。多集群不是简单地将多个 Kubernetes 集群拼在一起，而是需要一套标准化的工具来统一管理集群的注册、配置、升级与销毁。本章聚焦两大主流管理工具——KubeFed 与 Cluster API，并深入集群注册与生命周期管理的核心流程。
2.1 多集群管理工具对比
当前社区最成熟的多集群管理方案分为两类：控制面联邦（KubeFed） 与 声明式集群生命周期（Cluster API）。两者解决不同层次的问题，在实际生产环境中常组合使用。
| 维度 | KubeFed（Kubernetes Federation） | Cluster API |
|---|---|---|
| 核心目标 | 跨集群资源分发与调度策略统一 | 集群的创建、扩缩、升级、销毁自动化 |
| 管理对象 | Deployment、Service、ConfigMap 等工作负载资源 | Cluster、Machine、MachineDeployment 等基础设施资源 |
| 架构模式 | Host Cluster + Member Cluster 联邦控制面 | Management Cluster + Workload Cluster 声明式控制器 |
| 版本漂移处理 | 通过 Override 策略和版本策略控制分发版本 | 通过 MachineDeployment 滚动更新管理节点版本 |
| 适用场景 | 多集群应用部署、跨集群服务发现、策略治理 | 集群生命周期自动化、混合云/边缘集群自运维 |
| 成熟度 | v2 稳定，社区维护模式 | v1beta1，CNCF 孵化项目，社区活跃 |
选型建议： 如果你的首要痛点是“多个集群上的应用版本不一致”，优先引入 KubeFed 的版本策略与调度策略；如果你的首要痛点是“集群创建慢、版本升级靠手工”，优先落地 Cluster API。两者互补，不存在二选一的排他关系。
2.2 KubeFed：联邦控制面与资源分发
KubeFed 的核心思想是：通过一个 Host Cluster 作为联邦控制面，将资源模板（FederatedDeployment、FederatedService 等）分发到多个 Member Cluster。每个 Member Cluster 只需运行一个 KubeFed 代理组件，无需修改原生 API。
KubeFed 关键资源对象
- FederatedDeployment / FederatedService：联邦资源模板，定义跨集群分发的应用规格。
- ClusterSelector：基于标签选择目标集群，支持按 region、env、version 等维度过滤。
- OverridePolicy：允许为不同集群设置差异化参数（如副本数、镜像版本、环境变量），是版本漂移校准的核心策略点。
- ReplicaSchedulingPreference：跨集群副本分布策略，支持权重、最小/最大副本数、再平衡。
版本漂移校准切入点： 在 KubeFed 中，通过 OverridePolicy 可以为不同集群指定不同的镜像版本。例如：集群 A 运行 v1.0，集群 B 运行 v1.1，联邦控制面负责记录并管理这种差异，而不是强制统一。这为“校准”提供了可观测性与策略控制基础。
2.3 Cluster API：声明式集群生命周期
Cluster API 将集群视为声明式资源，通过 Management Cluster 中的 CRD 定义 Workload Cluster 的期望状态。当需要创建、升级或销毁集群时，只需修改 CR 对象，控制器会自动协调基础设施（如 AWS EC2、vSphere VM、OpenStack 实例）与 Kubernetes 组件。
Cluster API 核心 CRD 与生命周期阶段
| CRD 名称 | 职责 | 生命周期阶段 |
|---|---|---|
| Cluster | 定义集群的全局元数据、网络、控制面端点 | 创建 → 运行 → 删除 |
| Machine | 代表一个具体的节点（物理机/虚拟机） | Provisioning → Running → Deleting |
| MachineDeployment | 声明式管理一组 Machine，支持滚动更新与扩缩容 | ScalingUp → RollingUpdate → ScalingDown |
| MachineSet | MachineDeployment 的下层副本集，类似 ReplicaSet | 与 MachineDeployment 联动 |
| KubeadmControlPlane | 管理控制面节点的版本、配置与高可用 | 初始化 → 升级 → 替换 |
版本漂移风险点： Cluster API 的 MachineDeployment 滚动更新默认按“先创建新节点，再销毁旧节点”策略执行。如果新旧节点上的 kubelet 版本差异过大（例如 v1.27 → v1.29），可能导致调度器版本兼容性问题。建议在 MachineDeployment 的
spec.template.spec.version 中严格控制版本跳跃不超过一个次要版本。
2.4 集群注册与生命周期管理流程
无论使用 KubeFed 还是 Cluster API，集群注册与生命周期管理都遵循一套标准化的步骤。下面以 KubeFed 的集群注册流程为例，展示从加入联邦到开始调度的完整链路。
- 准备 Host Cluster：部署 KubeFed 控制面组件（helm install kubefed），确保 API 可用。
- 注册 Member Cluster：在 Host Cluster 中创建
KubeFedCluster资源，提供 Member Cluster 的 API Server 地址与凭据（kubeconfig）。 - 验证连通性：KubeFed 控制器定期向 Member Cluster 发送健康检查，确认 API Server 可达、节点状态正常。
- 启用联邦资源类型：通过
FederatedTypeConfig启用需要跨集群分发的资源类型（如 Deployment、Service）。 - 创建联邦资源：在 Host Cluster 中创建 FederatedDeployment，指定分发策略与覆盖策略。
- 监控与再平衡：KubeFed Scheduler 根据 ReplicaSchedulingPreference 自动调整各集群的副本分布。
- 注销集群：删除 KubeFedCluster 资源，KubeFed 自动清理该集群上的联邦资源。
生产实践： 在注册 Member Cluster 时，建议使用独立的 ServiceAccount 而非 admin kubeconfig，并限制其命名空间范围。同时，在 Host Cluster 中为每个 Member Cluster 维护一个 ClusterRole 用于联邦资源同步，避免权限扩散。
2.5 版本漂移校准在集群管理层面的映射
多集群管理工具为版本漂移校准提供了两个关键能力：可观测性 与 策略执行。下表总结了不同工具在版本漂移校准中的角色：
| 能力维度 | KubeFed 实现 | Cluster API 实现 |
|---|---|---|
| 版本差异发现 | 通过 FederatedDeployment 的 status 字段查看各集群实际运行的镜像版本 | 通过 MachineDeployment status 查看节点 kubelet 版本与 OS 镜像版本 |
| 版本策略定义 | OverridePolicy 中指定不同集群的镜像版本，支持 per-cluster 覆盖 | MachineDeployment.spec.template.spec.version 定义节点版本 |
| 版本升级触发 | 修改 FederatedDeployment 的模板版本，KubeFed 自动分发到各集群 | 修改 MachineDeployment 的版本字段，触发滚动更新 |
| 版本回滚 | 回退 FederatedDeployment 的模板版本，KubeFed 重新分发 | 回退 MachineDeployment 的版本字段，或使用 kubectl rollout undo |
| 版本合规审计 | 通过联邦资源的状态聚合，生成跨集群版本报告 | 通过 Cluster API 的 Machine 对象状态，审计节点版本一致性 |