2. Kubernetes 多集群基础概念：集群联邦、Hub-Spoke、Cluster API 简介

在生产环境中，单一 Kubernetes 集群无法满足跨区域容灾、环境隔离（开发/测试/生产）、以及多云/混合云战略的需求。多集群管理成为云原生架构的必备能力。本章将介绍三种主流的多集群管理范式：集群联邦（Federation）、Hub-Spoke（中心辐射） 以及 Cluster API（声明式集群生命周期管理）。

2.1 集群联邦（KubeFed / Federation v2）

集群联邦的核心思想是“一次编排，多集群生效”。它通过一个 Host Cluster 上的联邦控制面，将资源（如 Deployment、Service、Ingress）同步到多个 Member Cluster 中。

关键组件：
  • Federation API：定义 FederatedDeployment、FederatedService 等 CRD。
  • Propagation Policy：控制资源分发到哪些集群，支持按标签、名称匹配。
  • Override Policy：允许针对不同集群覆盖资源字段（如不同集群的副本数、镜像版本）。
  • DNS Endpoint Controller：自动将多集群 Service 的 Endpoint 注册到外部 DNS，实现全局负载均衡。
适用场景： 需要跨集群统一部署应用、统一配置管理，且集群数量较少（通常 3-10 个）的场景。联邦控制面本身存在单点风险，且同步延迟在集群数量增多时会显著增加。

2.2 Hub-Spoke 架构

Hub-Spoke 是目前最广泛采用的多集群管理模式。一个 Hub Cluster（管理集群）负责策略下发、状态收集和资源调度，多个 Spoke Cluster（工作集群）只运行用户负载，不直接暴露 API Server 给外部。

维度 Hub Cluster Spoke Cluster
角色 管理控制面 工作负载执行
API Server 暴露 对外暴露，供 CI/CD、运维平台调用 通常不暴露，仅通过 Hub 代理访问
资源规模 轻量，只存储元数据和策略 承载实际 Pod、Service、PV
典型工具 Open Cluster Management (OCM)、Rancher、Anthos 标准 K8s 集群
关键设计点： Hub 必须高可用部署，否则所有 Spoke 集群将失去管理能力。Spoke 集群的 kubelet 和 kube-proxy 需要配置正确的 DNS 解析，确保能拉取镜像和访问 API Server。
Hub-Spoke 多集群架构 Hub Cluster 管理控制面 策略 / 状态 / 调度 Spoke Cluster 1 生产环境 Spoke Cluster 2 预发布环境 Spoke Cluster 3 灾备环境 说明： Hub 通过代理（如 OCM 的 managedcluster 资源）管理 Spoke 集群。 Spoke 集群无需对外暴露 API Server，安全性更高。

2.3 Cluster API（CAPI）

Cluster API 是 Kubernetes SIG 推出的声明式集群生命周期管理项目。它使用 Kubernetes 原生 API 来创建、配置、升级和销毁集群，将基础设施（如 AWS EC2、vSphere VM）视为 Kubernetes 资源。

核心 CRD 资源

CRD 名称 作用 示例 Provider
Cluster 定义集群的拓扑、网络、控制面配置 AWSCluster, AzureCluster
Machine 代表一个节点（控制面或工作节点） AWSMachine, DockerMachine
MachineDeployment 类似 Deployment，管理一组 Machine 的滚动更新 —
KubeadmControlPlane 使用 kubeadm 初始化和管理控制面节点 —
Cluster API 工作流：
  1. 用户提交 Cluster 和 AWSCluster 等基础设施 CR 到管理集群。
  2. CAPI Controller 调用 Provider（如 CAPA）创建云资源（VPC、EC2、ELB）。
  3. 控制面节点初始化后，CAPI 自动生成 kubeconfig 并存储为 Secret。
  4. 工作节点通过 MachineDeployment 自动加入集群。
Cluster API 声明式集群生命周期 用户 / GitOps 管理集群 (CAPI) Provider (CAPA) 云资源 (EC2/VPC) 目标集群 (Workload) kubeconfig Cluster API 优势： 1. 声明式：所有集群状态通过 YAML 定义，可 GitOps 管理。 2. 一致性：控制面和工作节点使用相同的 Machine 模板，避免配置漂移。 3. 可扩展：支持 AWS、Azure、GCP、vSphere、裸金属等 20+ Provider。 4. 升级自动化：KubeadmControlPlane 支持控制面滚动升级，MachineDeployment 支持工作节点滚动升级。

2.4 三种模式对比

维度 集群联邦 (KubeFed) Hub-Spoke (OCM) Cluster API
核心目标 统一资源分发 集中管理 & 策略治理 声明式集群生命周期
资源同步 双向同步（Host → Member） 单向下发（Hub → Spoke） 不涉及运行时资源同步
集群数量 适合 3-10 个 适合 10-1000+ 个 适合任意数量（管理集群控制面需扩展）
基础设施管理 不管理 不管理（依赖外部工具） 原生管理（创建/销毁集群）
与外部 DNS 集成 内置 DNS Endpoint Controller 需配合 ServiceExport / MultiClusterService 需额外部署 DNS 控制器
选型建议： 如果你的团队需要快速创建和销毁测试集群，优先选择 Cluster API；如果已有大量固定集群需要统一策略和资源分发，Hub-Spoke 更成熟；如果追求“一次部署，到处运行”且集群数量可控，集群联邦 仍是一个轻量选择。
← 上一章 📖 返回目录 下一章 →