随着 Kubernetes 成为基础设施的标准抽象，企业开始面临多集群管理的挑战：跨地域高可用、混合云部署、环境隔离、避免厂商锁定。多集群联邦技术应运而生，将多个集群协调为一个统一的逻辑平台。
目录
- 1. 为什么需要多集群
- 2. 多集群架构模式
- 3. Karmada：多云多集群编排
- 4. Crossplane：统一控制平面
- 5. Istio 多集群服务网格
- 6. Rancher/Fleet：多集群管理
- 7. 方案对比与选型
- 8. 生产架构设计
1. 为什么需要多集群
驱动因素
| 因素 | 说明 | 场景 |
|---|---|---|
| 高可用 | 地域级容灾 | 金融核心系统 |
| 就近服务 | 用户就近访问 | 全球化应用 |
| 合规要求 | 数据不出境 | GDPR、数据主权 |
| 环境隔离 | 开发/测试/生产分离 | 安全隔离 |
| 避免锁定 | 多云策略 | 成本优化、议价能力 |
| 资源容量 | 单集群规模限制 | 超大规模部署 |
| 故障域隔离 | 控制平面隔离 | 防止单集群故障影响全局 |
单集群 vs 多集群
| 维度 | 单集群 | 多集群 |
|---|---|---|
| 复杂度 | 低 | 高 |
| 可用性 | 受限于单地域 | 地域级容灾 |
| 扩展性 | 受限于 etcd 性能 | 水平扩展 |
| 运维成本 | 低 | 高 |
| 网络延迟 | 内部高效 | 跨集群延迟 |
| 数据一致性 | 简单 | 需策略管理 |
2. 多集群架构模式
模式一：多独立集群 + 统一控制
┌─────────────────────────────────────────────┐
│ 统一管理平台 │
│ (Rancher / Karmada / ArgoCD) │
└──────┬─────────────┬─────────────┬──────────┘
│ │ │
┌───▼───┐ ┌───▼───┐ ┌───▼───┐
│Cluster│ │Cluster│ │Cluster│
│ A │ │ B │ │ C │
│(AWS) │ │(GCP) │ │(Azure)│
└───────┘ └───────┘ └───────┘
各集群独立运行，通过统一管理平台协调。故障隔离最好，但跨集群服务通信需额外配置。
模式二：控制平面联邦
┌──────────────────────────────────────────┐
│ Karmada 控制平面 │
│ API Server / Scheduler / Controller │
└──────┬────────────────────────────┬──────┘
│ join │ join
┌───▼───┐ ┌───▼───┐
│Member │ │Member │
│Cluster│ │Cluster│
│ 北京 │ │ 上海 │
└───────┘ └───────┘
Karmada 将 API 请求分发到成员集群，提供统一的资源视图。
模式三：服务网格联邦
┌──────────────┐ ┌──────────────┐
│ Cluster A │ │ Cluster B │
│ (Primary) │◄──────────►│ (Remote) │
│ │ Istio │ │
│ istiod │ Gateway │ istiod │
│ + envoy │ mTLS │ + envoy │
└──────────────┘ └──────────────┘
Istio 将多个集群连接为统一的服务网格，服务跨集群透明通信。
3. Karmada：多云多集群编排
Karmada 是 CNCF 孵化的多集群项目，提供原生 K8s API + 跨集群调度能力。
核心概念
| 对象 | 作用 |
|---|---|
| PropagationPolicy | 定义资源如何分发到成员集群 |
| OverridePolicy | 为不同集群覆盖特定配置 |
| ResourceBinding | 绑定资源与目标集群 |
| Work | 在成员集群中实际创建的资源 |
部署 Karmada
# 安装 Karmada 控制平面
git clone https://github.com/karmada-io/karmada.git
cd karmada
hack/local-up-karmada.sh
# 添加成员集群
karmadactl join member1 --cluster-kubeconfig=$HOME/.kube/member1.config
karmadactl join member2 --cluster-kubeconfig=$HOME/.kube/member2.config
分发 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
app: nginx
spec:
replicas: 6
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
---
# 分发策略
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
name: nginx-propagation
spec:
resourceSelectors:
- apiVersion: apps/v1
kind: Deployment
name: nginx
placement:
clusterAffinity:
clusterNames:
- member1
- member2
replicaScheduling:
replicaDivisionPreference: Weighted
replicaSchedulingType: Divided
weightPreference:
staticWeightList:
- targetCluster:
clusterNames:
- member1
weight: 1
- targetCluster:
clusterNames:
- member2
weight: 2
结果：member1 运行 2 个副本，member2 运行 4 个副本（按 1:2 权重分配）。
OverridePolicy：差异化配置
apiVersion: policy.karmada.io/v1alpha1
kind: OverridePolicy
metadata:
name: nginx-override
spec:
resourceSelectors:
- apiVersion: apps/v1
kind: Deployment
name: nginx
overrideRules:
- targetCluster:
clusterNames: [member1]
overriders:
plaintext:
- path: "/spec/template/spec/containers/0/image"
operator: replace
value: "nginx:beijing"
- targetCluster:
clusterNames: [member2]
overriders:
plaintext:
- path: "/spec/template/spec/containers/0/image"
operator: replace
value: "nginx:shanghai"
故障迁移
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
name: failover-policy
spec:
resourceSelectors:
- apiVersion: apps/v1
kind: Deployment
name: critical-app
placement:
clusterAffinity:
clusterNames:
- member1
- member2
failover:
application:
decisionConditions:
- type: Healthy
status: "False"
timeoutSeconds: 60
当 member1 不健康超过 60 秒，副本自动迁移到 member2。
4. Crossplane：统一控制平面
Crossplane 将云资源（数据库、存储、网络）转化为 K8s CRD，实现"基础设施即代码"。
核心概念
| 对象 | 作用 |
|---|---|
| Provider | 对接云厂商 API（AWS、GCP、Azure、阿里云） |
| Managed Resource (MR) | 云资源的 K8s 表示（如 RDSInstance、S3Bucket） |
| Composition | 将多个 MR 组合为更高层抽象 |
| Claim (XR) | 用户声明的抽象资源请求 |
Crossplane + Karmada 结合
# 通过 Crossplane 在多个云创建数据库
apiVersion: database.aws.crossplane.io/v1beta1
kind: RDSInstance
metadata:
name: prod-db
annotations:
# Karmada 分发到特定集群
karmada.io/propagation-policy: aws-region-policy
spec:
forProvider:
region: us-east-1
dbInstanceClass: db.t3.medium
engine: postgres
masterUsername: admin
5. Istio 多集群服务网格
部署模式
单控制平面（Primary-Remote）：
- 一个集群运行 istiod，其他集群的 Envoy 代理连接到它
- 简单但不具备控制平面高可用
多控制平面：
- 每个集群独立运行 istiod
- 通过 Istio Gateway 和 mTLS 建立信任
- 推荐生产使用
多控制平面配置
# Cluster A: east-west gateway + 暴露服务
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: cross-network-gateway
spec:
selector:
istio: eastwestgateway
servers:
- port:
number: 15443
name: tls
protocol: TLS
tls:
mode: AUTO_PASSTHROUGH
hosts:
- "*.local"
---
# ServiceEntry 声明远程服务
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: remote-service
spec:
hosts:
- remote-service.remote.svc.cluster.local
location: MESH_INTERNAL
ports:
- number: 8080
name: http
protocol: HTTP
resolution: DNS
endpoints:
- address: remote-cluster-gateway.example.com
ports:
http: 15443
当 Pod A 访问 remote-service 时，Istio 自动将流量路由到远程集群。
6. Rancher/Fleet：多集群管理
Rancher
Rancher 提供 UI + API 管理多集群：
- 集群导入：任意 K8s 集群（EKS/GKE/ACK/自建）
- 统一 RBAC：跨集群的用户和权限管理
- 应用市场：Helm Chart 一键部署到多集群
- Fleet：GitOps 驱动的多集群应用分发
Fleet
# GitRepo：定义要同步的 Git 仓库
apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
name: app-deploy
namespace: fleet-default
spec:
repo: https://github.com/example/app-config.git
branch: main
paths:
- /overlays/production
targets:
- clusterSelector:
matchLabels:
env: production
Fleet 自动将 Git 仓库中的配置同步到所有匹配标签的集群。
7. 方案对比与选型
| 方案 | 跨集群调度 | 服务网格 | 云资源管理 | UI | 学习曲线 |
|---|---|---|---|---|---|
| Karmada | ⭐⭐⭐ 原生 | 需配合 Istio | ❌ | CLI | 中 |
| Crossplane | ❌ | ❌ | ⭐⭐⭐ 原生 | ❌ | 高 |
| Istio | ❌ | ⭐⭐⭐ 原生 | ❌ | ❌ | 高 |
| Rancher | Fleet（GitOps） | 可集成 | ❌ | ⭐⭐⭐ | 低 |
| ArgoCD | ApplicationSet | ❌ | ❌ | ⭐⭐ | 低 |
组合方案：
- Karmada + Istio：强大的跨集群调度 + 服务网格
- Crossplane + Karmada：跨云资源管理 + 跨集群应用调度
- Rancher + Fleet：统一 UI + GitOps 多集群交付
8. 生产架构设计
典型跨国企业架构
┌───────────────────────────────────────────────────────────┐
│ Global Traffic Manager │
│ (Cloudflare / AWS Route 53) │
└───┬───────────────┬────────────────┬──────────────────────┘
│ │ │
┌───▼───┐ ┌─────▼──────┐ ┌────▼────┐
│ 美国 │ │ 欧洲 │ │ 亚太 │
│ Cluster│ │ Cluster │ │ Cluster │
│(EKS) │ │ (GKE) │ │ (ACK) │
└───┬───┘ └─────┬──────┘ └────┬────┘
│ │ │
└──────────────┼───────────────┘
│
┌─────────▼──────────┐
│ Karmada 控制平面 │
│ (部署于美国主区域) │
└────────────────────┘
│
┌─────────▼──────────┐
│ ArgoCD（GitOps） │
│ 配置仓库 + 监控 │
└────────────────────┘
关键考虑
- 控制平面部署：Karmada/Istio 控制平面的高可用
- 网络连接：集群间专线或 VPN，确保延迟和带宽
- 数据同步：跨区域数据库复制策略
- DNS 策略：GeoDNS 将用户路由到最近集群
- 灾难恢复：自动故障迁移 + 手动降级策略
总结
| 方案 | 核心价值 | 适用场景 |
|---|---|---|
| Karmada | 跨集群调度、故障迁移 | 多云应用分发 |
| Crossplane | 云资源统一抽象 | 多云基础设施管理 |
| Istio | 跨集群服务网格 | 微服务跨地域通信 |
| Rancher + Fleet | 统一 UI + GitOps | 多集群统一管理 |
多集群不是单一技术能解决的全域问题，而是需要网络 + 调度 + 服务网格 + 基础设施管理的组合方案。从单集群到多集群的演进，需要在复杂度收益和运维成本之间找到平衡点。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。