Kubernetes 中的多集群管理架构与 API 的演进

多集群（Multi-Cluster）管理是 Kubernetes 生态持续演进的核心方向。本文系统梳理了多集群架构与 API 的十年演进脉络，帮助读者理解主流治理模式与未来趋势。

Kubernetes 多集群架构的演进阶段

下图展示了 Kubernetes 多集群管理的主要演进阶段：

图 1: Kubernetes 多集群管理的演进时间线（2016–2025）

Federation 与 KubeFed：早期的联邦控制平面

Kubernetes 最早在 1.5 版本引入 Federation v1，希望通过一个上层控制平面对多个集群进行统一管理。它允许在联邦控制平面中创建 FederatedDeployment、FederatedService 等对象，从而在多个集群中自动同步资源。

然而该方案存在如下问题：

依赖集中式控制面，可扩展性与可用性有限。
网络与安全模型复杂。
生态集成度低，难以和现有工具共存。

随后社区推出了 Federation v2（KubeFed），通过 CRD + Controller 的方式重写了联邦逻辑。但依旧没有在主线 Kubernetes 中进入 GA，逐渐被更灵活的方案取代。

Multicluster Services API：跨集群服务发现的尝试

2020 年，SIG-Multicluster 提出了 KEP-1645: Multi-Cluster Services API，旨在统一跨集群的服务发现与负载均衡标准。

核心设计思路

Namespace Sameness：跨集群同名命名空间视为逻辑相同。
ServiceExport / ServiceImport：通过声明式导入导出服务。
EndpointSlice 聚合：跨集群同步服务端点，实现统一 DNS。
ClusterSet：定义一组互信的集群集合。

MCS API 经历了数年低速演进后在 2025 – 2026 年重新活跃：仓库 kubernetes-sigs/mcs-api 于 2026 年 5 月发布 v0.5.0，正式引入 multicluster.x-k8s.io/v1beta1 版本的 ServiceExport/ServiceImport，并补齐了含 IPv6/双栈在内的一致性测试套件。Cilium Cluster Mesh、Submariner、Istio、GKE Multi-Cluster Services、Karmada 等均提供了 MCS API 实现。

与此并行，SIG Multicluster 在 2024 年起推进 Cluster Inventory API（KEP-4322），其核心资源 ClusterProfile 为"有哪些集群、各自状态与能力如何"提供标准化描述，供 Karmada、OCM、Argo CD、Kueue 的 MultiKueue 等上层工具统一消费（2026 年 10 月发布 v0.2.0）。

MCS API 的边界

聚焦服务发现与 DNS，不负责集群生命周期与资源分发。
要求 ClusterSet 内满足命名空间同一性（Namespace Sameness）。
跨集群数据面（隧道、路由、mTLS）仍由具体实现（CNI、网格、Submariner）提供。

控制平面联邦化：Karmada、OCM 与 Fleet

2022 年后，社区与企业厂商转向控制平面联邦化（Control Plane Federation）模型。代表项目包括：

Karmada（华为发起）：CNCF 孵化项目（2023 年底晋级），兼容原生 Kubernetes API，支持 Push/Pull 注册模式，最新稳定版 v1.19（2026 年 10 月）。
Open Cluster Management (OCM)（Red Hat）：聚焦策略治理与 Observability。
Rancher Fleet：以 GitOps 为核心的多集群声明式交付。
Anthos / Azure Arc / Alibaba ACK One：云厂商的托管式方案。

图 2: 控制平面联邦化的代表项目：Karmada、OCM 与 Rancher Fleet

这些项目普遍采用以下核心理念：

统一控制面：一个全局控制平面注册与管理多个成员集群。
声明式同步：资源同步基于 CRD 与 Controller。
策略驱动调度：ClusterPlacement、PropagationPolicy 等统一调度。
混合云兼容：支持云上与边缘、私有集群混合接入。
服务网格兼容：支持 Istio、Cilium 等服务网格的跨集群部署。
GitOps 融合：支持 Argo CD / Flux 等 GitOps 工具的集成。
流量管理：支持流量分发、负载均衡、故障转移等。

这些方案在生产实践中逐步取代了早期 Federation 的概念。

Gateway API 时代：跨集群流量与服务治理的新标准

Kubernetes 官方的 SIG-Network 在 2024 年提出 Multi-Cluster Gateway API，这是目前社区公认的新一代跨集群服务发现与流量治理标准。

其核心思想为：

不再定义“跨集群服务”，而是以 Gateway + Route 的方式实现跨集群访问控制与流量转发。

优势

完全兼容 Gateway API 标准。
支持跨集群 Service、Failover、Route。
适配 Service Mesh、Cilium、Istio 等实现。
更易于与云厂商 Ingress / LB 融合。

官方规范

当前主流方向（2026）

Kubernetes 多集群管理已进入“生态整合阶段”，目前主流方向包括：

表格说明：下表对比了当前主流多集群治理方向及其代表项目。

类别	核心代表	特点
API 标准化	MCS API（v1beta1）、ClusterProfile、Multi-Cluster Gateway API	SIG Multicluster/SIG Network 官方演进路线，服务发现、集群清单与流量治理一体化
控制面治理	Karmada / OCM / Fleet	策略控制、调度与统一 API
Service Mesh 跨集群	Istio / Cilium / Linkerd	基于 L7 服务发现、零信任流量
GitOps 联邦	Argo CD / Flux	无集中控制面，靠 Git 声明式同步
AI/Edge 融合架构	KubeEdge / HAMi / Volcano	为 AI 原生工作负载扩展调度与算力联邦

表 1: 主流多集群治理方向与代表项目

下图展示了多集群治理的主要技术方向：

图 3: 多集群治理的五个主要技术方向

这些模式正在融合形成新的趋势：

「Policy 中心化 + Data Plane 去中心化」的多集群治理架构。

小结：从 Federation 到 Gateway 的十年演进

多集群技术的演进，是 Kubernetes 社区从“集中控制”走向“分布式自治”的过程。

下表梳理了多集群架构的主要阶段、代表项目与现状。

阶段	代表项目	核心理念	现状
Federation	Federation v1/v2	集中式控制面	已废弃
标准化探索	MCS API	服务层统一标准	已冻结
控制平面治理	Karmada / OCM / Fleet	策略统一、调度中心	主流实践
网络层融合	Multi-Cluster Gateway API	Gateway + Route 跨集群流量	官方推荐方向

表 2: Kubernetes 多集群架构演进阶段对比

思考与展望

随着 AI 原生（AI-Native）工作负载兴起，多集群架构正从“资源调度”扩展到“算力编排”与“智能代理自治”层面。

未来可能出现的趋势包括：

与 AI Gateway / Model Control Plane (MCP) 融合的跨集群推理调度。
面向边缘 AI 与 GPU 集群的多租户算力虚拟化。
使用开放策略代理（OPA）+ Policy Engine 实现全局治理。

多集群管理，不再只是控制 Kubernetes 的集群，而是在控制整个分布式智能计算平面。

总结

Kubernetes 多集群管理架构与 API 的演进，体现了社区从集中式联邦到分布式自治的技术路线转变。当前，Gateway API、控制面联邦化、Service Mesh 跨集群、GitOps 联邦与 AI-Native 架构等多种模式正在融合，推动云原生基础设施向更高层次的智能化和自治演进。

参考文献

创建于 2022/05/21 更新于 2026/11/01 2480 字阅读约 5 分钟