📚 课程目录第2章多集群管理基础

2. 多集群管理基础：Kubernetes多集群架构模式对比与选型

在etcd压测沙盘与Cilium性能调优的实战场景中，多集群管理是基础设施的顶层设计。不同的多集群架构模式直接影响etcd的跨集群一致性、Cilium的网络策略同步效率以及整体运维复杂度。本节从Hub-Spoke、Federation v2、Cluster API三种主流模式出发，进行结构化对比与选型分析。

2.1 三种核心架构模式概述

架构模式	核心思想	控制面位置	etcd一致性模型	典型场景
Hub-Spoke	中心集群（Hub）统一管理多个边缘集群（Spoke），通过API聚合实现控制	中心化	最终一致性（通过同步控制器）	边缘计算、多云统一视图、灾备
Federation v2	通过Federation控制平面将资源模板同步到多个成员集群	逻辑中心化	强一致性（依赖etcd租约与分布式锁）	跨集群服务发现、统一调度
Cluster API	声明式管理集群生命周期，通过Provider驱动基础设施创建/销毁集群	去中心化（管理集群+工作负载集群）	最终一致性（基于Reconcile循环）	集群快速创建、版本升级、弹性扩缩

选型提示： 在etcd压测沙盘中，若需要模拟跨集群etcd成员变更与Raft一致性测试，Federation v2的强一致性模型更贴近真实生产；若侧重Cilium网络策略的跨集群同步延迟分析，Hub-Spoke模式更易构建隔离的测试边界。

2.2 Hub-Spoke 架构详解

Hub-Spoke是最广泛使用的多集群管理模式，其核心是中心集群（Hub）作为控制面入口，边缘集群（Spoke）承载实际工作负载。Hub集群不直接运行用户业务，而是负责策略下发、资源聚合与监控数据收集。

  性能调优关注点： Hub-Spoke模式下，Hub集群的etcd承载所有Spoke集群的资源元数据与策略对象。当Spoke数量超过50个时，etcd的watch机制与list请求会成为瓶颈。建议在Hub侧启用etcd的--experimental-compact-hash-check-enabled并合理设置--auto-compaction-retention。

2.3 Federation v2 架构详解

Federation v2（KubeFed）通过联邦控制平面将资源模板（Template）与放置策略（Placement）同步到多个成员集群。其核心组件包括：

Federation API Server：管理联邦资源定义（FTD）与集群注册信息。
Federation Controller：负责将资源模板分发到目标集群，并监控同步状态。
etcd（联邦层）：存储联邦资源状态，要求强一致性。

性能瓶颈预警： Federation v2 的联邦层 etcd 需要处理所有成员集群的资源变更事件。在压测沙盘中，若成员集群超过 10 个且每个集群频繁更新资源，联邦 etcd 的写入 QPS 可能超过 5000/s，此时需启用 etcd 的 --max-request-bytes=1572864 并监控 etcd_server_leader_changes_seen_total 指标。

2.4 Cluster API 架构详解

Cluster API 是 Kubernetes 社区主推的声明式集群生命周期管理方案。它通过管理集群（Management Cluster）中的 CRD 定义工作负载集群的期望状态，由 Provider 负责调用云平台或裸金属 API 完成集群创建、扩缩与升级。

组件	作用	etcd 关联
Cluster	定义集群的全局元数据（名称、区域、网络）	管理集群 etcd 存储 Cluster 对象
Machine	代表集群中的一个节点（物理机/虚拟机）	管理集群 etcd 存储 Machine 状态
MachineDeployment	类似 Deployment，管理一组 Machine 的滚动更新	管理集群 etcd 存储期望副本数
ClusterResourceSet	在集群创建后自动应用附加资源（如 Cilium DaemonSet）	管理集群 etcd 存储资源模板

  沙盘应用场景： 在 etcd 压测沙盘中，Cluster API 可用于快速创建/销毁多个测试集群，模拟 etcd 成员加入与退出的极端场景。通过调整 MachineDeployment 的 replicas 字段，可以触发 etcd 集群的 rebalance 与 leader 选举，验证 Raft 协议在高负载下的稳定性。

2.5 架构选型决策矩阵

以下矩阵帮助你在 etcd 压测沙盘与 Cilium 性能调优场景中快速选择合适模式：

评估维度	Hub-Spoke	Federation v2	Cluster API
etcd 跨集群一致性要求	低（最终一致）	高（强一致）	低（最终一致）
Cilium 网络策略同步延迟	中等（依赖 Hub 转发）	低（直接同步到成员集群）	高（需等待集群就绪）
集群生命周期管理	手动或借助工具	手动	声明式自动化
运维复杂度	低	高	中
压测沙盘推荐度	★★★★☆	★★★☆☆	★★★★★

选型建议： 若你的压测目标聚焦于 etcd Raft 一致性 与 Cilium 跨集群网络策略 的联合调优，推荐以 Hub-Spoke 为基础架构，搭配 Cluster API 管理测试集群的生命周期。Federation v2 更适合生产环境中的多集群服务网格场景，但在沙盘中其强一致性模型可能引入不必要的复杂性。

2.6 实战：在沙盘中部署多集群架构

以下是一个基于 Cluster API 的快速部署示例，用于在沙盘中创建两个测试集群：

# 1. 安装 Cluster API 核心组件
clusterctl init --infrastructure docker

# 2. 创建管理集群（kind）
kind create cluster --name capi-management

# 3. 定义工作负载集群
cat <<EOF | kubectl apply -f -
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: test-cluster-1
spec:
  clusterNetwork:
    pods:
      cidrBlocks: ["10.244.0.0/16"]
    services:
      cidrBlocks: ["10.96.0.0/12"]
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: DockerCluster
    name: test-cluster-1
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: test-cluster-1-md-0
spec:
  clusterName: test-cluster-1
  replicas: 3
  template:
    spec:
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfigTemplate
          name: test-cluster-1-md-0
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: DockerMachineTemplate
        name: test-cluster-1-md-0
EOF

# 4. 等待集群就绪
clusterctl get kubeconfig test-cluster-1 > test-cluster-1.kubeconfig

# 5. 部署 Cilium 到测试集群
cilium install --context test-cluster-1 --cluster-id 1 --cluster-name test-cluster-1

注意： 在沙盘中，每个工作负载集群的 etcd 成员数量建议控制在 3~5 个，避免因资源不足导致 etcd 频繁 OOM。使用 kubectl --context test-cluster-1 get pods -n kube-system -l component=etcd 确认 etcd Pod 状态。