📚 课程目录第3章多集群架构基础

3. 多集群架构基础：Hub-Spoke、Federation、Cluster API、多集群网络与DNS

在云原生可观测性场景中，单一集群往往无法满足大规模租户隔离、地理冗余或环境隔离（开发/预发/生产）的需求。多集群架构是构建统一可观测性面板的底层基础设施。本章将系统梳理四种主流多集群管理模型及其网络与DNS基础。

3.1 四种多集群管理模型对比

模型	控制模式	工作负载分布	典型场景	可观测性适配
Hub-Spoke	中心化控制	Spoke 自治	管理平面 + 租户集群	Hub 聚合 SLO/错误预算
Federation	对等联邦	跨集群同步	跨区域服务高可用	联邦指标聚合
Cluster API	声明式生命周期	自动扩缩	基础设施即代码	集群状态自动上报
多集群网络	网络互联	服务发现	跨集群通信	拓扑感知指标路由

3.2 Hub-Spoke 架构

Hub-Spoke 是最广泛使用的多集群管理模式。一个中心 Hub 集群负责策略下发、监控聚合和租户管理；多个 Spoke 集群运行实际工作负载，各自保留控制面自治权。

  关键特征： Hub 不运行用户工作负载，仅作为控制与观测的汇聚点；Spoke 通过 Agent 或 Operator 与 Hub 通信。

3.3 Federation（联邦）架构

Federation 通过 KubeFed（Kubernetes Federation v2）实现跨集群资源同步。与 Hub-Spoke 不同，联邦集群之间是对等关系，资源通过 ClusterSelector 和 OverridePolicy 分发。

适用场景： 需要跨区域部署同一套服务（如多活架构），且希望保持各集群独立控制面。联邦控制面仅同步资源模板，不直接管理 Pod。

Federation 核心组件

Federation Control Plane — 运行在宿主集群，管理 FederatedTypeConfig
ClusterRegistry — 注册所有成员集群的 kubeconfig 与状态
PropagationPolicy — 定义资源分发到哪些集群
OverridePolicy — 按集群定制副本数、镜像版本等

3.4 Cluster API（CAPI）

Cluster API 将 Kubernetes 集群的生命周期管理声明式化。通过 Cluster、Machine、MachineDeployment 等 CRD，实现集群的创建、扩缩、升级和销毁。

注意： Cluster API 管理的是集群本身，而非集群内的工作负载。在多集群可观测性中，CAPI 可用于自动注册新集群到监控系统。

# Cluster API 示例：声明一个工作负载集群
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: prod-cluster-01
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AWSCluster
    name: prod-cluster-01
  controlPlaneRef:
    kind: KubeadmControlPlane
    name: prod-cluster-01-cp
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: prod-cluster-01-md-0
spec:
  clusterName: prod-cluster-01
  replicas: 3
  template:
    spec:
      version: v1.28.0

3.5 多集群网络与DNS

多集群网络解决跨集群 Pod/Service 连通性问题，DNS 则提供全局服务发现。以下是三种主流方案对比：

方案	网络模型	DNS 解析	延迟	可观测性影响
Cilium ClusterMesh	Overlay + eBPF	CoreDNS + 全局 ServiceExport	低	支持 Hubble 跨集群流表
Submariner	Gateway + IPsec	Lighthouse 服务发现	中	提供跨集群网络指标
Istio Multi-Cluster	Mesh 联邦	Istio DNS 代理	中	统一遥测与拓扑

多集群 DNS 解析流程

客户端 Pod 发起 DNS 查询 service-a.namespace.svc.clusterset.local
本地 CoreDNS 检查 ServiceImport 资源，判断目标是否跨集群
若跨集群，返回远端集群 Service IP 或 Endpoint IP
流量通过隧道或直接路由到达目标 Pod

3.6 多集群可观测性架构选型建议

  推荐组合： Hub-Spoke + Cilium ClusterMesh。Hub 作为全局 SLO/错误预算聚合层，ClusterMesh 提供低延迟跨集群网络与统一 DNS，CAPI 用于自动化集群生命周期管理。

租户边界清晰 — 每个 Spoke 集群承载单一租户，便于 SLO 隔离
指标聚合高效 — Hub 侧 Thanos Query 跨集群查询，无需穿透每个 Spoke 的 API Server
错误预算全局视图 — 通过 ServiceImport 的跨集群流量比例，计算全局错误预算消耗