tags: [Kubernetes, K8s系列, DevOps, 多集群, Federation, Cluster API, 服务网格]

K8s 系列 | 第 29 天：多集群管理：Federation / Cluster API / 多集群服务网格

第 29/30 天

引言

当 Kubernetes 集群从个位数增长到数十甚至上百个时——无论是出于多区域部署、环境隔离（开发/测试/生产）、租户隔离还是灾备需求——多集群管理就从一个可选方案变成了必选项。单个 K8s 集群的最佳规模建议在 5000 节点以内（Kubernetes 社区官方推荐），超越这个规模或者需要跨地域部署时，多集群架构是最佳选择。

今天我们将深入探讨主流的三种多集群管理方案：

KubeFed (Kubernetes Federation)：传统的联邦控制平面方案
Cluster API：声明式集群生命周期管理
多集群服务网格：基于 Istio / Cilium 的统一服务治理

一、为什么需要多集群管理？

1.1 单集群的局限

限制维度	说明
规模瓶颈	etcd 存储上限 ~8GB，单个集群建议 ≤5000 节点
故障域	Control Plane 故障影响所有工作负载
地域延迟	跨地域 Pod 通信延迟不可控
合规需求	数据必须留在特定国家/地区
环境隔离	开发/测试/生产完全隔离

1.2 多集群的核心价值

┌─────────────────────────────────────────┐
│           Federation Control Plane        │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  │
│  │ Cluster │  │ Cluster │  │ Cluster │  │
│  │  US-E1  │  │  EU-W1  │  │  AP-S1  │  │
│  └─────────┘  └─────────┘  └─────────┘  │
│    地区A        地区B         地区C       │
└─────────────────────────────────────────┘

二、KubeFed：传统联邦方案

2.1 架构原理

KubeFed（Kubernetes Federation v2）通过一个联邦控制平面，将多个集群的资源统一编排。核心组件：

Federation API：定义 FederatedDeployment、FederatedService 等跨集群资源
Placement 策略：控制资源分发到哪些成员集群
Override 策略：允许按集群定制资源参数

2.2 安装 KubeFed

# 使用 helm 安装 KubeFed
helm repo add kubefed https://raw.githubusercontent.com/kubernetes-sigs/kubefed/master/charts
helm repo update
kubectl create namespace kube-federation-system
helm install kubefed kubefed/kubefed 
  --namespace kube-federation-system 
  --version=0.10.0

2.3 加入成员集群

# 将集群 cluster-b 加入联邦
kubefedctl join cluster-b 
  --cluster-context cluster-b-context 
  --host-cluster-context cluster-a-context 
  --v=2

2.4 创建联邦 Deployment

apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
metadata:
  name: app-frontend
  namespace: production
spec:
  template:
    metadata:
      labels:
        app: frontend
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: frontend
      template:
        metadata:
          labels:
            app: frontend
        spec:
          containers:
          - name: nginx
            image: nginx:1.27
  placement:
    clusters:
    - name: cluster-a
    - name: cluster-b
  overrides:
  - clusterName: cluster-a
    clusterOverrides:
    - path: spec.replicas
      value: 5  # cluster-a 运行 5 副本
  - clusterName: cluster-b
    clusterOverrides:
    - path: spec.replicas
      value: 3  # cluster-b 运行 3 副本

2.5 KubeFed 的局限性

❌ 项目已进入维护模式（社区转向 Cluster API）
❌ 不支持跨集群服务发现（需要额外的 DNS 方案）
❌ 对网络策略和存储资源的联邦支持有限
❌ 配置变更传播有延迟

三、Cluster API：声明式集群生命周期管理

3.1 核心概念

Cluster API 是一个 Kubernetes 子项目，目标是用声明式 API 管理 Kubernetes 集群的完整生命周期——创建、扩缩、升级、销毁。它把集群本身当成 Kubernetes 资源来管理。

核心 CRD：

CRD	作用
`Cluster`	定义一个集群的拓扑
`Machine`	代表一个工作节点（物理机/虚拟机）
`MachineDeployment`	声明式管理 Machine（类似 Deployment 管理 Pod）
`MachineSet`	一组同质的 Machine
`Infrastructure*`	基础设施提供商的实现（AWS、Azure、vSphere 等）

3.2 架构示意

┌─────────────────── Management Cluster ──────────────────┐
│                                                          │
│  Cluster API Controller  ────  Provider (AWS/Azure/...) │
│         │                                                 │
│    ┌────┴────────────┐                                   │
│    │ Cluster (prod)  │    │ Cluster (staging) │          │
│    │ MachineDeploy   │    │ MachineDeploy     │          │
│    │    ├ Machine-1  │    │    ├ Machine-1    │          │
│    │    ├ Machine-2  │    │    └ Machine-2    │          │
│    │    └ Machine-3  │    └───────────────────│          │
│    └─────────────────┘                                   │
│                                                          │
└──────────────────────────────────────────────────────────┘
       ↓ 创建               ↓ 升级               ↓ 销毁
   ┌──────────┐      ┌──────────┐      ┌──────────┐
   │  集群 A  │      │  集群 B  │      │  集群 C  │
   └──────────┘      └──────────┘      └──────────┘

3.3 安装 Cluster API

# 使用 clusterctl CLI 安装
clusterctl init 
  --infrastructure docker 
  --addon helm

3.4 声明一个工作负载集群

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: workload-prod
  namespace: default
spec:
  clusterNetwork:
    pods:
      cidrBlocks: ["10.96.0.0/12"]
    services:
      cidrBlocks: ["10.32.0.0/12"]
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: DockerCluster
    name: workload-prod
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: KubeadmControlPlane
    name: workload-prod-control-plane
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DockerMachineTemplate
metadata:
  name: workload-prod-worker-mt
  namespace: default
spec:
  template:
    spec:
      extraMounts:
      - containerPath: "/var/run/docker.sock"
        hostPath: "/var/run/docker.sock"
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: workload-prod-worker-md
  namespace: default
spec:
  clusterName: workload-prod
  replicas: 3
  template:
    spec:
      clusterName: workload-prod
      version: v1.29.0
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfigTemplate
          name: workload-prod-worker-bootstrap
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: DockerMachineTemplate
        name: workload-prod-worker-mt

3.5 集群升级

# 升级 Control Plane 到 1.30.0
kubectl patch kubeadmcontrolplane workload-prod-control-plane 
  --type merge 
  -p '{"spec":{"version":"v1.30.0"}}'

# 升级 Worker 节点
kubectl patch machinedeployment workload-prod-worker-md 
  --type merge 
  -p '{"spec":{"template":{"spec":{"version":"v1.30.0"}}}}'

3.6 Cluster API 的优势

✅ 声明式、Kubernetes 原生体验
✅ 支持 20+ 基础设施提供商（AWS、Azure、GCP、vSphere、OpenStack）
✅ 内置滚动升级、扩缩容、健康检查
✅ 社区活跃，CNCF 孵化项目
✅ 与 ClusterClass（v1beta1+）实现模板化集群定义

四、多集群服务网格

4.1 为什么需要服务网格？

当应用分布在多个集群中，传统的 Kubernetes Service 只能在一个集群内做服务发现。多集群服务网格提供了：

跨集群透明服务发现：svc-a.cluster-b 无缝访问 svc-b.cluster-a
统一流量治理：灰度发布、故障注入跨集群统一管控
零信任安全：mTLS 加密跨越集群边界
统一观测：分布式追踪、指标聚合

4.2 Istio 多集群架构（Primary-Remote）

# 在 Cluster-A 上安装 Istio 作为 Primary
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-primary
spec:
  profile: demo
  meshConfig:
    accessLogFile: /dev/stdout
  components:
    pilot:
      k8s:
        replicaCount: 2
        env:
        - name: PILOT_ENABLE_CROSS_CLUSTER
          value: "true"

# 导出 Cluster-A 的 istio-ca-root-cert
kubectl get secret istio-ca-root-cert 
  -n istio-system -o yaml > ca-cert.yaml

# 在 Cluster-B 上应用 CA 证书
kubectl apply -f ca-cert.yaml -n istio-system

# 创建跨集群 ServiceEntry
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: cross-cluster-svc
spec:
  hosts:
  - "*.cluster-b.svc.cluster.local"
  resolution: DNS
  location: MESH_INTERNAL
  endpoints:
  - address: <cluster-b-api-server-ip>
    ports:
      http: 80
EOF

4.3 Cilium ClusterMesh

Cilium 的 ClusterMesh 方案更加轻量，基于 eBPF 实现跨集群网络：

# 安装 Cilium 并启用 ClusterMesh
helm upgrade cilium cilium/cilium 
  --namespace kube-system 
  --set cluster.name=cluster-a 
  --set cluster.id=1 
  --set clustermesh.enable=true

# 跨集群 Service 示例
apiVersion: v1
kind: Service
metadata:
  name: global-redis
  annotations:
    io.cilium/global-service: "true"
spec:
  type: ClusterIP
  selector:
    app: redis
  ports:
  - port: 6379

Cilium ClusterMesh 的优势：
– 无需 Sidecar：eBPF 内核级转发，性能优于 Istio
– 天然支持：Global Service 声明即可跨集群发现
– 加密隧道：基于 WireGuard 或 IPsec 的跨集群通信

4.4 三种方案对比

特性	KubeFed	Cluster API	服务网格 (Istio/Cilium)
核心目标	资源分发	集群生命周期	跨集群网络与治理
当前状态	维护模式	✅ 活跃开发	✅ 活跃开发
安装复杂度	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
跨集群网络	❌ 无	❌ 无	✅ 内置
集群自愈	❌	✅ 声明式自愈	❌
基础设施无关	✅	❌ (依赖 Provider)	✅
学习曲线	中等	高	高

五、生产最佳实践

5.1 推荐组合方案

Cluster API（管理集群生命周期）
        │
        ▼
多个 Workload 集群（k8s cluster-a, cluster-b, ...）
        │
        ▼
Cilium ClusterMesh（跨集群网络）
  或
Istio Multi-Cluster（跨集群服务网格 + 流量治理）

对于大多数团队，推荐路线：
1. 先用 Cluster API 管理集群生命周期（创建/升级/扩缩）
2. 网络层面使用 Cilium ClusterMesh 实现跨集群通信
3. 如果需要精细化流量治理，加上 Istio 多集群模式

5.2 多集群管理 Checklist

# 生产环境多集群必须考虑：
# 1. 证书管理 — 每个集群独立 PKI，共享信任锚点
# 2. 镜像仓库 — 每个区域部署镜像缓存/代理
# 3. DNS 策略 — 使用 ExternalDNS + 全局负载均衡
# 4. 监控聚合 — Thanos / Grafana Mimir 跨集群指标
# 5. 日志聚合 — Loki 的跨集群租户模式
# 6. 灾备策略 — 主备切换、异地多活

# 示例：跨集群镜像缓存
apiVersion: v1
kind: ConfigMap
metadata:
  name: mirror-config
  namespace: kube-system
data:
  registry-mirror: |
    mirror:
      docker.io:
        endpoints:
        - https://mirror.cluster-a.internal
        - https://docker.mirrors.example.com

5.3 常见坑点

证书同步：多集群之间 CA 证书不一致会导致 mTLS 握手失败——使用 cert-manager + Trust 管理器统一分发
IP 冲突：各集群的 Pod CIDR / Service CIDR 必须不重叠
DNS 解析：跨集群 DNS 建议使用 CoreDNS 多集群插件或 ExternalDNS
etcd 备份：管理集群的 etcd 也需备份，否则所有集群定义一起丢失

六、总结

今天我们系统学习了三种主流多集群管理方案：

方案	适用场景	一句话总结
KubeFed	遗留系统，需统一资源分发	已进入维护模式，但概念仍有参考价值
Cluster API	需要自动化集群生命周期管理	用 K8s 管理 K8s，声明式集群运维的未来
服务网格	需要跨集群通信与服务治理	eBPF 时代首选 Cilium，精细化治理选 Istio