关于云原生-cloud-native:k8s极简史K8s多集群技术发展的历史现状与未来

3次阅读

共计 4612 个字符，预计需要花费 12 分钟才能阅读完成。

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

Kubernetes 社区早在 2015 年便公布了集群联邦技术白皮书，并成立了“SIG-Federation”（后更名为 SIG-Multicluster）特地兴趣小组致力于多集群畛域的钻研，该兴趣小组由华为领衔，同时也吸引了包含 Google、Redhat 在内的一线大厂。

SIG-Federation 于 2016 年正式推出官网我的项目 Federation，并在此基础上倒退出了 Kubefed 我的项目，而且技术架构也产生了较大的变动，因而 Federation 我的项目经常被称为 Federation V1，而 Kubefed 则被称为 Federation V2。

第一代架构中，引入了 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

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

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

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

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

以后 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 本身以及周边关联的多个技术畛域发展了相干工作。

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

正文完