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

2. Kubernetes 多集群基础：多集群概念、集群联邦（KubeFed）原理、多集群服务网格概述

2.1 多集群架构的核心概念与驱动因素

在单集群无法满足业务对高可用、地理分布、资源隔离、合规要求时，多集群架构成为云原生基础设施的必然选择。多集群并非简单地将多个 Kubernetes 集群拼凑在一起，而是需要一套统一的控制平面与数据平面协同机制。

驱动因素	说明	典型场景
高可用与容灾	避免单集群故障导致全局服务中断	跨可用区（AZ）或跨地域（Region）主备切换
数据主权与合规	数据必须存储在特定国家或地区	GDPR、PIPL 等法规要求数据本地化
租户隔离与爆炸半径	不同业务线或环境（开发/测试/生产）使用独立集群	金融行业多租户、SaaS 平台环境隔离
延迟与性能优化	将工作负载部署到离用户最近的集群	边缘计算、CDN 节点、游戏加速
避免供应商锁定	混合云或多云策略，分散风险	同时使用 AWS EKS、Azure AKS、自建集群

实践建议：在规划多集群架构时，建议先明确“为什么要多集群”，而不是“为了多集群而多集群”。对于大多数中小规模业务，单集群配合命名空间隔离已经足够；多集群会引入额外的网络、管理和运维复杂度。

2.2 多集群管理模型对比

当前主流的多集群管理模型分为三种：中心化控制平面、对等联邦、松散耦合。下表从控制方式、同步粒度、故障隔离三个维度进行对比。

模型	控制方式	同步粒度	故障隔离	代表技术
中心化控制平面	一个控制面管理多个成员集群	API 对象级（Deployment、Service 等）	控制面故障影响所有集群	KubeFed、Rancher
对等联邦	集群间平等协商，无中心	服务发现与流量路由	单个集群故障不影响其他集群	Istio Multi-Cluster、Cilium ClusterMesh
松散耦合	通过 GitOps 或 CI/CD 工具分别部署	应用发布单元	完全隔离，无跨集群依赖	ArgoCD、Flux + 多目标集群

注意：中心化控制平面模型（如 KubeFed）虽然管理方便，但控制面本身会成为单点瓶颈和故障域。在生产环境中，建议对控制面组件进行高可用部署，并配合监控告警。

2.3 集群联邦（KubeFed）原理与架构

KubeFed（Kubernetes Federation）是 CNCF 孵化的官方多集群管理项目，核心思想是通过联邦控制平面将多个 Kubernetes 集群抽象为一个逻辑集群。其架构分为三层：联邦 API、同步控制器、调度控制器。

  核心组件：
  Federation API：定义 FederatedDeployment、FederatedService 等联邦资源类型。
Sync Controller：将联邦资源同步到所有成员集群，并保持状态一致。
Replica Scheduler：根据策略（如地域、集群负载）决定每个集群的副本数。
DNS Controller：跨集群服务发现，自动生成全局 DNS 记录。

2.4 KubeFed 工作流程与资源同步

KubeFed 的核心工作流程遵循“模板-放置-覆盖”模式。用户定义联邦资源后，控制器会将其分发到指定集群。

定义联邦资源模板（Template）：编写 FederatedDeployment，包含 Deployment 的通用定义。
配置放置策略（Placement）：指定资源需要分发到哪些成员集群（通过集群标签选择）。
配置覆盖策略（Overrides）：针对不同集群，覆盖模板中的特定字段（如镜像版本、副本数、环境变量）。
同步与状态回写：Sync Controller 将最终资源推送到成员集群，并持续监控成员集群中资源的状态，回写到联邦资源 Status 中。

关键代码示例：FederatedDeployment 定义

apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
metadata:
  name: my-app
  namespace: production
spec:
  template:
    metadata:
      labels:
        app: my-app
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: my-app
      template:
        metadata:
          labels:
            app: my-app
        spec:
          containers:
          - name: my-app
            image: myregistry/my-app:v1.0.0
  placement:
    clusters:
    - name: cluster-us-east
    - name: cluster-eu-west
  overrides:
  - clusterName: cluster-eu-west
    clusterOverrides:
    - path: /spec/replicas
      value: 5
    - path: /spec/template/spec/containers/0/image
      value: myregistry/my-app:v1.0.0-eu

2.5 多集群服务网格概述

多集群服务网格解决了跨集群的服务发现、流量管理、安全通信问题。与 KubeFed 的 API 对象同步不同，服务网格更关注数据平面的连通性。主流方案包括 Istio Multi-Cluster、Cilium ClusterMesh、Linkerd Multi-Cluster。

方案	网络模型	跨集群通信方式	安全特性	适用场景
Istio Multi-Cluster	扁平网络或 VPN	东西向网关（E/W Gateway）	mTLS、SPIFFE 身份	需要精细流量路由、灰度发布
Cilium ClusterMesh	原生 eBPF 隧道	直接 Pod IP 路由	eBPF 加密、网络策略	高性能、低延迟、大规模集群
Linkerd Multi-Cluster	镜像服务 + 网关	Service Mirroring	mTLS（透明）	轻量级、运维简单

2.6 多集群方案选型建议

在实际项目中，KubeFed 与多集群服务网格并非互斥关系，而是互补的。KubeFed 负责应用编排与资源分发，服务网格负责运行时流量与安全。以下选型建议供参考：

场景一：统一应用部署与版本管理 → 优先选择 KubeFed + GitOps（ArgoCD 多集群模式）。
场景二：跨集群流量调度与灰度发布 → 优先选择 Istio Multi-Cluster 或 Cilium ClusterMesh。
场景三：边缘计算与大规模集群 → 优先选择 Cilium ClusterMesh（eBPF 性能优势）或 Linkerd（轻量级）。
场景四：混合云/多云统一管理 → 组合使用 KubeFed（资源分发）+ Istio（流量管理）。

课程关联：本章后续的 Operator 发布流水线将基于 KubeFed 实现跨集群资源分发，而自动化回滚机制将结合服务网格的流量切换能力，实现更精细的回滚策略（金丝雀回滚、流量镜像回滚等）。