核心概念：集群联邦、控制平面高可用、工作负载分布、资源抽象与模型、跨集群服务发现
在构建 Multi-Cluster 环境时，理解其核心概念是设计高可用资源模型的前提。本章将逐一剖析五个关键支柱：集群联邦、控制平面高可用、工作负载分布、资源抽象与模型以及跨集群服务发现。这些概念共同构成了 Multi-Cluster 架构的理论基础。
1. 集群联邦 (Cluster Federation)
集群联邦是 Multi-Cluster 管理的“大脑”。它允许用户将多个独立的 Kubernetes 集群视为一个逻辑实体进行统一管理。联邦控制平面负责同步资源、分发配置，并确保跨集群的一致性。
核心价值： 联邦不是简单的集群聚合，而是提供了一种声明式策略，让用户定义“资源应该分布在哪些集群”，而非手动操作每个集群。
联邦架构层级
| 层级 | 组件 | 职责 |
|---|---|---|
| 控制层 | Federation API Server / Karmada API | 接收用户定义的联邦资源（如 FederatedDeployment），维护资源模板与调度策略。 |
| 调度层 | Scheduler / Policy Engine | 根据资源分布策略（如：集群标签、资源配额、地域亲和性）决定将资源分发到哪些成员集群。 |
| 执行层 | Cluster Agent / Push Mode | 将联邦资源“推”或“拉”到成员集群，并在成员集群中创建对应的原生 Kubernetes 资源。 |
2. 控制平面高可用 (Control Plane HA)
控制平面是集群的“心脏”。在 Multi-Cluster 环境中，不仅单个集群的控制平面需要高可用，联邦控制平面本身也必须具备高可用能力。任何单点故障都可能导致全局调度失效。
- 单集群控制平面 HA： 采用 etcd 集群 + API Server 多副本 + Leader Election 模式，确保 kube-apiserver、controller-manager、scheduler 无单点。
- 联邦控制平面 HA： 联邦 API Server 同样需要多副本部署，并依赖 etcd 集群。调度器组件应支持 Active-Standby 或 Active-Active 模式。
- 跨集群控制面仲裁： 在极端场景下（如网络分区），需要设计“仲裁集群”或“监督者”角色，防止出现脑裂导致资源调度冲突。
常见陷阱： 很多团队只关注工作负载的 HA，却忽略了联邦控制平面的 HA。一旦联邦 API Server 宕机，所有跨集群的扩缩容、滚动更新、策略变更都将停滞。
3. 工作负载分布 (Workload Distribution)
工作负载分布决定了 Pod、Deployment、StatefulSet 等资源如何被分配到不同的成员集群。分布策略直接影响应用的可用性、延迟和成本。
常见分布策略对比
| 策略 | 描述 | 适用场景 |
|---|---|---|
| 复制 (Replication) | 将完整的工作负载副本分发到所有目标集群。 | 需要低延迟的全局服务、静态内容分发。 |
| 分片 (Sharding) | 将工作负载按比例或按规则拆分到不同集群。 | 大数据处理、租户隔离、区域性数据合规。 |
| 故障转移 (Failover) | 主集群承载流量，备集群保持最小副本，仅在故障时接管。 | 主备灾备、成本敏感的生产环境。 |
| 地理分布 (Geo-distribution) | 根据用户地理位置将流量路由到最近的集群。 | 全球 SaaS 服务、边缘计算。 |
4. 资源抽象与模型 (Resource Abstraction & Model)
为了屏蔽底层集群的差异，Multi-Cluster 架构引入了资源抽象层。用户不再直接操作原生 Kubernetes 资源，而是操作更高阶的“联邦资源模型”。
- 资源模板 (Resource Template)： 定义工作负载的通用规格，如镜像、端口、环境变量。例如一个 FederatedDeployment 的模板部分。
- 分布策略 (Placement Policy)： 描述资源应该被调度到哪些集群，以及如何调度（如：副本数、权重、集群亲和性）。
- 覆盖策略 (Overrides)： 允许针对特定集群修改模板中的参数，例如为边缘集群设置更小的资源限制，或为生产集群设置不同的镜像标签。
设计建议： 资源模型应遵循“模板 + 策略”分离原则。模板保持通用，策略负责差异化。这能极大提升模型的可复用性和可维护性。
5. 跨集群服务发现 (Cross-Cluster Service Discovery)
当工作负载分布在多个集群后，服务之间如何互相发现和调用成为关键挑战。跨集群服务发现需要解决 DNS 解析、负载均衡和网络连通性问题。
主流实现方式
- Global DNS / 联邦 DNS： 使用 CoreDNS 的 Federation 插件或 ExternalDNS，将跨集群 Service 的 DNS 记录同步到一个全局 DNS 视图。例如：
service-a.global.svc.cluster.local可以解析到多个集群的 Pod IP。 - Service Mesh 多集群模式： 如 Istio 的 Multi-Primary 或 Primary-Remote 架构。通过 Mesh 网关或东西向网关，实现跨集群的流量路由和 mTLS 加密。
- 专用服务注册中心： 使用 Consul、Nacos 等工具，将各集群的服务实例注册到统一注册中心，客户端通过注册中心获取端点列表。
关键指标： 跨集群服务发现的成功标准是 P99 延迟 和 DNS 传播时间。对于 Global DNS，需要关注 TTL 设置与缓存一致性；对于 Service Mesh，需要关注东西向网关的吞吐量。