2. Kubernetes多集群基础：多集群的定义、常见多集群拓扑与工具概览
在进入具体的Deployment升级策略与准入控制联动之前，必须先建立对多集群环境的统一认知。多集群架构并非简单的“多套Kubernetes集群”，而是涉及网络拓扑、资源调度、策略治理和故障隔离的系统性设计。本章将定义多集群的核心概念，梳理三种主流拓扑模式，并对比当前社区最活跃的三款多集群管理工具。
2.1 多集群的定义与核心价值
多集群架构是指组织同时管理两个或两个以上Kubernetes集群，并通过某种控制面或编排层实现资源调度、应用分发、策略治理和故障隔离的架构模式。其核心驱动力包括：
- 地理分布与延迟优化：将工作负载部署到靠近用户的区域集群，降低网络延迟。
- 高可用与故障隔离：避免单集群故障导致全局服务中断，实现跨AZ/Region的容灾。
- 环境隔离与合规：开发、测试、生产集群物理或逻辑隔离，满足安全审计与数据主权要求。
- 资源弹性与成本控制：利用不同云厂商或本地IDC的差异化成本，实现混合云/多云调度。
2.2 常见多集群拓扑模式
根据控制面的位置、集群间的关系以及资源调度方式，多集群拓扑主要分为三种模式。下表从控制面位置、调度粒度、典型场景三个维度进行对比：
| 拓扑模式 | 控制面位置 | 调度粒度 | 典型场景 | 运维复杂度 |
|---|---|---|---|---|
| Hub-Spoke（中心辐射） | 中心Hub集群 | 应用/Deployment级别 | 边缘计算、多云分发、统一策略管控 | 中 |
| Federation（联邦） | 逻辑联邦控制面 | 资源模板级别 | 跨集群资源同步、统一服务发现 | 高 |
| 独立集群（Standalone） | 每个集群独立 | 无统一调度 | 开发/测试隔离、完全自治 | 低 |
2.2.1 Hub-Spoke 拓扑
Hub-Spoke是目前生产环境中最广泛采用的多集群模式。一个中心集群（Hub）作为控制面，负责策略下发、资源分发和状态收集；多个成员集群（Spoke）仅运行工作负载，不参与全局决策。这种模式天然适合“一次部署，多地运行”的场景，也是Karmada、Clusternet等工具的核心架构基础。
2.2.2 Federation 拓扑
Federation（联邦）模式通过一个逻辑联邦控制面，将多个集群的资源“同步”到统一视图。Kubernetes社区早期的kubefed项目即采用此模式。联邦控制面不直接调度Pod，而是将资源模板（如Deployment、Service）分发到所有成员集群，由各集群的调度器自行处理。这种模式适合需要跨集群服务发现和统一DNS的场景，但控制面复杂度较高，且对网络延迟敏感。
2.2.3 独立集群拓扑
独立集群模式是最简单的多集群形态：每个集群完全自治，没有统一的控制面。团队通常通过CI/CD流水线或手动方式分别部署应用。这种模式运维成本最低，但缺乏全局资源视图和统一策略治理，适用于开发/测试环境或完全隔离的业务线。
2.3 多集群管理工具概览
当前社区最活跃的三款多集群管理工具分别是Karmada、Clusternet和OCM（Open Cluster Management）。它们都采用Hub-Spoke架构，但在资源模型、调度策略和扩展性上存在显著差异。下表从关键维度进行对比：
| 维度 | Karmada | Clusternet | OCM |
|---|---|---|---|
| 发起方 | 华为云（CNCF孵化项目） | 腾讯云（CNCF沙箱项目） | Red Hat / IBM（CNCF孵化项目） |
| 核心资源模型 | ResourceTemplate + PropagationPolicy | Subscription + FeedInventory | ManifestWork + Placement |
| 调度策略 | 静态调度 + 动态权重 + 差异化 | 基于拓扑的调度 + 优先级 | 基于标签的Placement + 滚动更新 |
| 集群接入方式 | Push模式（Hub主动下发） | Pull模式（Spoke主动注册） | Push + Pull 双模式 |
| 对原生API兼容性 | 高（兼容标准Kubernetes API） | 中（扩展CRD较多） | 高（通过ManifestWork封装） |
| 典型优势 | 策略灵活、社区活跃、文档完善 | 边缘友好、网络穿透能力强 | 与OpenShift深度集成、生态丰富 |
2.3.1 Karmada
Karmada（Kubernetes Armada）是华为云开源的CNCF孵化项目，其设计哲学是“Kubernetes原生多集群”。它通过PropagationPolicy和OverridePolicy实现精细化的资源分发与差异化配置。Karmada的调度器支持静态调度、动态权重和故障转移，非常适合需要精细化策略控制的生产环境。
# Karmada PropagationPolicy 示例：将Deployment分发到两个生产集群
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
name: nginx-deploy-policy
spec:
resourceSelectors:
- apiVersion: apps/v1
kind: Deployment
name: nginx
placement:
clusterAffinity:
clusterNames:
- prod-cluster-east
- prod-cluster-west
replicaScheduling:
replicaDivisionPreference: Weighted
replicaScheduling:
weightPreference:
staticWeightList:
- targetCluster: prod-cluster-east
weight: 2
- targetCluster: prod-cluster-west
weight: 12.3.2 Clusternet
Clusternet由腾讯云开源，CNCF沙箱项目。其最大特点是“边缘友好”：Spoke集群通过反向连接（Pull模式）主动注册到Hub，即使Spoke集群位于NAT或防火墙之后也能被管理。Clusternet的Subscription模型支持基于拓扑的调度，适合边缘计算和IoT场景。
2.3.3 OCM（Open Cluster Management）
OCM由Red Hat/IBM主导，CNCF孵化项目，与OpenShift深度集成。OCM的核心抽象是ManifestWork（将一组Kubernetes资源打包分发）和Placement（基于标签选择目标集群）。OCM支持Push和Pull双模式，且提供了丰富的可观测性插件，适合企业级混合云场景。
- 如果你需要最灵活的调度策略和社区活跃度，优先选择 Karmada。
- 如果你的Spoke集群大量位于边缘/私有网络，且需要反向注册，优先选择 Clusternet。
- 如果你已经使用OpenShift或需要企业级可观测性，优先选择 OCM。
2.4 多集群拓扑与工具选择对Deployment升级的影响
不同的拓扑和工具会直接影响Deployment升级策略的设计：
- Hub-Spoke + Karmada：可以在Hub侧定义全局升级策略（如金丝雀比例、暂停条件），通过
PropagationPolicy控制升级流量到不同Spoke集群的顺序。 - Hub-Spoke + Clusternet：升级策略更多依赖Spoke集群自身的RollingUpdate，Hub主要负责分发，适合边缘场景下的“先升级中心，再分批推送到边缘”。
- 独立集群：升级策略完全由各集群独立控制，需要通过外部CI/CD编排升级顺序，无法实现全局一致性。