引子

随着云原生技术的遍及，越来越多的企业应用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；

Federation V2架构

在第二代架构中，利用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/v1beta1kind: FederatedSecretmetadata:  name: test-secret  namespace: test-namespacespec:  template:    data:      A: YWxhIG1hIGtvdGE=    type: Opaque  placement:    clusters:    - name: cluster2    - name: cluster1  overrides:  - clusterName: cluster2    clusterOverrides:    - path: /data      value:        A: null

上述配置中，通过template指定原生资源属性，通过placement指定资源将散发到cluster1 和 cluster2集群，最初overrides批示了散发到cluster2集群时，打消Secret的data信息。

K8s多集群现状

KubeFed的问题

Kubernetes社区以后已将Federation (v1)我的项目敞开，着重倒退Kubefed，但该我的项目尚停留在beta阶段，社区开发简直停滞，作为社区官网我的项目在该畛域中的领导位置也在逐步削弱。

Kubefed我的项目最大的问题是应用了非Kubernetes原生API来治理用户利用部署，用户必须先革新既有的工作流程才可迁徙到Kubefed提供的API，这不仅贬低了应用门槛，而且Kubefed为每种资源类型均提供了CRD API，品种繁多的API也减少了用户的学习老本。某位社区致力于多集群治理的架构师坦言：“Kubefed我的项目强制用户应用非原生API，这个谬误的决定很大水平上导致了它的倒退不如预期。”

另外，多集群治理场景中，利用的多集群散发与监控应该是最根本的诉求，而Kubefed只实现了利用散发，对于利用的运行状态不足监管。用户应用Kubefed散发利用只能看到利用是否散发胜利，对于利用运行状态，用户仍须要遍历集群别离获取。对用户应用造成了极大的不便。

K8s多集群治理标准化工作

以后Kubernetes社区针对Kubefed相干问题曾经进行了屡次探讨，目前多集群治理相干规范制订工作次要围绕在跨集群服务发现和工作负载配置管理，这两块也是实现多集群利用治理最根底的性能局部。

a.多集群Service API

在多集群利用背景下，用户曾经习惯于将利用散发到多个集群，但对于Service利用而言，集群是个硬性阻碍，运行于集群中的工作负载无奈高效地拜访其余集群中裸露的服务。多集群Service API旨在提供解决这个问题的规范，它次要包含：

1）定义一组API反对跨集群的Service服务发现和生产；

2）集群中利用跨集群拜访Service行为与本集群统一；

该Service API提供ServiceExport对象示意单个集群中须要裸露到多集群的Service：

// ServiceExport declares that the associated service should be exported to// other clusters.type ServiceExport struct {        metav1.TypeMeta `json:",inline"`        // +optional        metav1.ObjectMeta `json:"metadata,omitempty"`        // +optional        Status ServiceExportStatus `json:"status,omitempty"`}

每个须要裸露给其余集群的Service均对应一个ServiceExport对象。

此外，Service API还提供了ServiceImport对象，示意跨集群的Service定义：

// ServiceImport describes a service imported from clusters in a supercluster.type ServiceImport struct {  metav1.TypeMeta `json:",inline"`  // +optional  metav1.ObjectMeta `json:"metadata,omitempty"`  // +optional  Spec ServiceImportSpec `json:"spec,omitempty"`  // +optional  Status ServiceImportStatus `json:"status,omitempty"`}

该Service API 提案已被社区接收，该提案只定义了跨集群Service的申明形式，并没有对其实现细节进行束缚，能够想见，未来会有多种具体的解决方案被提出。

b.多集群工作负载模型

对于联邦利用如何在多集群中散发，SIG-Multicluster也在进行尝试一种与现有Kubefed不同的解决思路。Kubefed以后从一系列FederatedXXX配置中剥离出Kubernetes原生利用散发到多集群，而新的尝试是提供一个通用的ManifestWork对象封装所有的利用，如下API设计：

// ManifestWork represents a manifests workload that hub wants to deploy on the managed cluster.// A manifest workload is defined as a set of kubernetes resources.// ManifestWork must be created in the cluster namespace on the hub, so that agent on the// corresponding managed cluster can access this resource and deploy on the managed// cluster.type ManifestWork struct {   metav1.TypeMeta   `json:",inline"`   metav1.ObjectMeta `json:"metadata,omitempty"`   // Spec represents a desired configuration of work to be deployed on the managed cluster.   Spec ManifestWorkSpec `json:"spec"`   // Status represents the current status of work   // +optional   Status ManifestWorkStatus `json:"status,omitempty"`}

与Kubefed为每种利用类型均提供一个FederatedXXX 类型相比，这种新型的工作负载API则显得更加简略和通用。

将来瞻望

K8s多集群技术是容器混合云/多云解决方案的核心技术畛域，波及到资源、利用、数据、流量多个层面，以及对立配置、注册、可视化、主动弹性等多个性能畛域。目前开源业界包含K8s社区的KubeFed我的项目、以及现有市面上的各种产品与解决方案都没有可能笼罩残缺的多集群技术畛域。

华为云MCP容器多云平台在K8s多集群技术畛域属于较早也是实现较为全面的产品，而同时华为云作为KubeFed社区我的项目的发起者与领导者，将在将来致力于欠缺现有KubeFed的功能集，并且实现K8s多集群技术的标准化。下图形容了K8s多集群技术的全景，目前华为云曾经在KubeFed本身以及周边关联的多个技术畛域发展了相干工作。

点击关注，第一工夫理解华为云陈腐技术~