随着云原生技术的普及，越来越多的企业使用Kubernetes来管理应用，并且集群规模也呈爆发式增长，企业也亟需应对随集群规模增长而带来的各种挑战。同时，为了更好地提供高可用、弹性伸缩的应用，企业也对容器混合云解决方案产生了极大的兴趣。
纵观容器混合云市场，主要的云服务提供商纷纷推出了自家的解决方案，例如华为云的MCP、Google的Anthos、Vmware的 Tanzu、IBM的 Cloud Pak、Red Hat的ACM for K8s等等。可以说，当前容器混合云市场纷繁嘈杂、百家争鸣，尽管各厂商不遗余力地鼓吹自家解决方案，但有个不争的事实是在容器混合云领域暂未出现领军产品。
混合云市场的乱象源于两点，一是各厂商均嗅到了商机，发现了这一广阔的蓝海市场，急于在这场竞争中抢占先机C位出道；二是开源界暂无统一的事实标准。根据历史规律，后者是解决这一乱象的关键所在，正像Kubernetes终结容器编排领域的纷争一模一样。
在开源领域，致力于混合云领域的项目数量与广阔的市场相比，显得极不相称。目前只有Rancher的Fleet、SAP公司力推的Gardener、以及Kubernetes社区的Kubefed。Fleet和Gardener要么缺乏创新，要么格局较低，难成大气，最有可能形成标准的便是被寄予厚望的、也是当前Kubernetes社区唯一的官方项目Kubefed。
K8s多集群历史Kubernetes社区早在2015年便发布了集群联邦技术白皮书，并成立了“SIG-Federation”（后更名为SIG-Multicluster）特别兴趣小组致力于多集群领域的研究，该兴趣小组由华为领衔，同时也吸引了包括Google、Redhat在内的一线大厂。
SIG-Federation于2016年正式推出官方项目Federation，并在此基础上发展出了Kubefed项目，而且技术架构也发生了较大的变化，因此Federation项目常常被称为Federation V1，而Kubefed则被称为Federation V2。
Federation V1架构第一代架构中，引入了Federated API Server，用于增加集群相关API，屏蔽集群差异，统一请求入口，同时提供一个Cluster Controller用于管理多个集群状态、集群级别对象创建，并且Service Controller用来实现跨集群服务发现。整体架构如下图所示：
V1架构兼容K8S原生API，从单集群到多集群演进可以变得很自然，但它也有几个不得不面对的缺陷。
• 集群信息嵌入原生API的Annotation中（如下图所示），会导致原生API体积膨胀而丑陋；
• 没有集群生命周期管理特有API，导致其生命周期管理能力无法扩展；
• 无法提供API对象版本控制，比如Deployment在K8S为GA，但在Federation中可能仍是Beta；
在第二代架构中，利用CRD来提供独立的API对象，新的API来封装K8S原生对象，同时也可以方便的对新增API提供版本管理。
整体架构如下图所示：
随架构升级，Federation项目也更名为Kubefed。在新的架构中，Kubefed提供两种配置类型：
• Type configuration（类型配置）： 定义Kubefed接管的K8S的资源类型
• Cluster configuration（集群配置）： 定义Kubefed接管的K8S集群
在类型配置中有三个关键的概念，用于控制资源向拖管集群分发策略：
• Templates（模版）：定义一个原生的K8S资源类型；
• Placement（安置）：定义资源将分发的集群；
• Overrides（修正）：针对集群自由修正资源；
一个典型的Secret配置如下图所示：
apiVersion: types.kubefed.io/v1beta1 kind: FederatedSecret metadata: name: test-secret namespace: test-namespace spec: template: data: A: YWxhIG1hIGtvdGE= type: Opaque placement: clusters: - name: cluster2 - name: cluster1 overrides: - clusterName: cluster2 clusterOverrides: - path: /data value: A: null