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

2. Kubernetes多集群架构基础：Hub-Spoke、Federation、Cluster API等主流多集群管理模式对比

在进入资源画像与成本优化之前，必须理解多集群的管理模式。不同的架构决定了控制面的耦合程度、资源同步效率以及弹性伸缩的决策路径。本章聚焦三种主流模式：Hub-Spoke（中心辐射型）、Federation（联邦） 和 Cluster API（声明式集群管理），并从资源画像视角分析其适用场景。

2.1 三种模式的核心架构对比

维度	Hub-Spoke	Federation (KubeFed)	Cluster API
控制面耦合度	松散耦合，Hub仅做调度/监控	中等耦合，通过联邦API同步资源	强耦合，管理集群控制工作负载集群
资源同步机制	Agent/Operator拉取或推送	Federation Controller 双向同步	声明式CRD + Provider 驱动
弹性伸缩路径	Hub下发策略，Spoke本地执行	联邦HPA跨集群分发	自动扩缩集群节点数
资源画像适用性	适合全局调度与成本聚合	适合跨集群Deployment统一管理	适合基础设施层成本优化
运维复杂度	低（仅需维护Hub）	中（需维护联邦控制面）	高（需管理Provider与Bootstrap）

资源画像视角提示： Hub-Spoke 模式天然适合作为成本数据采集的汇聚点，因为所有Spoke集群的Metrics可以统一上报到Hub，便于生成全局资源画像。Federation 更适合需要跨集群保持Deployment副本数一致性的场景，但成本聚合需要额外组件。

2.2 Hub-Spoke 模式

Hub-Spoke 是目前生产环境中最广泛采用的多集群管理模式。一个中心集群（Hub）负责策略下发、资源调度和监控聚合，多个工作集群（Spoke）独立运行用户负载。

  关键特征：
  单向通信为主： Hub 向 Spoke 下发配置，Spoke 上报状态和 Metrics，避免控制面雪崩。
资源画像优势： 可以在 Hub 侧部署 Prometheus + Thanos 或 VictoriaMetrics，统一存储所有 Spoke 的时序数据，生成全局资源画像。
弹性伸缩策略： 每个 Spoke 独立运行 Cluster Autoscaler 和 HPA，Hub 仅做跨集群调度建议，不直接干预。

2.3 Federation（KubeFed）模式

Kubernetes Federation (KubeFed) 通过联邦控制面将多个集群抽象为一个逻辑集群。用户向联邦 API 提交资源，Federation Controller 负责将资源分发到所有成员集群。

注意： Federation 模式在资源画像场景下存在“数据一致性延迟”问题。由于联邦控制器需要跨集群同步状态，当某个成员集群的 Pod 因资源不足被驱逐时，联邦控制面可能无法立即感知，导致画像数据失真。建议在 Federation 之上叠加独立的 Metrics 采集层。

2.4 Cluster API 模式

Cluster API 是 Kubernetes SIG 推出的声明式集群生命周期管理项目。它通过 CRD 定义集群、机器、基础设施等资源，实现集群的创建、扩缩容和升级自动化。

# Cluster API 声明式集群定义示例
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: production-cluster
spec:
  clusterNetwork:
    pods:
      cidrBlocks: ["10.96.0.0/12"]
    services:
      cidrBlocks: ["10.32.0.0/16"]
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AWSCluster
    name: production-aws-cluster
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: worker-pool
spec:
  clusterName: production-cluster
  replicas: 5
  template:
    spec:
      version: v1.28.0
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfig
          name: worker-config
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: AWSMachineTemplate
        name: worker-machine-template

  Cluster API 与资源画像的关联：
  节点级成本优化： Cluster API 可以结合 Cluster Autoscaler 自动扩缩节点池，根据资源画像的“节点利用率”指标调整节点数量。
Deployment 弹性伸缩前置条件： 在 Cluster API 管理的集群中，Pod 的弹性伸缩受限于节点池的容量。资源画像可以帮助判断是“Pod 层面扩容”还是“节点层面扩容”。
多集群一致性： Cluster API 支持通过 ClusterClass 定义集群模板，确保所有工作集群的节点规格一致，便于成本建模。

2.5 三种模式的选型建议

场景	推荐模式	理由
已有多个独立集群，需要统一监控和成本分析	Hub-Spoke	侵入性最低，仅需在Hub部署聚合层，Spoke无需改造
需要跨集群保持Deployment副本数一致	Federation	原生支持FederatedDeployment，自动同步副本数
从零构建多集群，且需要自动化节点扩缩	Cluster API	声明式管理集群生命周期，与云Provider深度集成
混合云/多云环境，网络延迟较高	Hub-Spoke	避免联邦控制面的频繁跨地域同步，降低网络依赖
需要精细化的节点级成本拆分	Cluster API + Hub-Spoke	Cluster API管理节点，Hub-Spoke聚合成本数据

课程实践建议： 本课程后续章节将以 Hub-Spoke 模式为基础展开资源画像与成本优化实践。原因在于：Hub-Spoke 架构最贴近真实生产环境，且成本数据采集链路最清晰。Federation 和 Cluster API 的相关概念会在涉及跨集群调度和节点扩缩容时作为补充知识引入。