CN113839814A - 去中心化的Kubernetes集群联邦实现方法及系统 - Google Patents

Abstract

本发明公开了一种去中心化的Kubernetes集群联邦实现方法及系统，本发明去中心化的Kubernetes集群联邦实现方法包括待添加（Kubernetes）集群创建集群配置资源、分发给主（Kubernetes）集群，依据主集群创建的点请求资源创建广播器组件，所述广播器组件根据集群配置资源创建一广告CRD资源，广播器组件以虚拟节点的形式在待添加集群中创建一个虚拟集群，该虚拟集群的可用资源量等于接受的共享配额，以使得待添加集群作为主集群的一个节点组成集群联邦。本发明在集群联邦方案中可通过不引入中心化的管理层来控制和分发资源，同时又能够减少过多的API引入来实现集群联邦。

Description

去中心化的Kubernetes集群联邦实现方法及系统

技术领域

本发明涉及基于Kubernetes的集群联邦实现技术，具体涉及一种去中心化的Kubernetes集群联邦实现方法及系统。

背景技术

Kubernetes是一个开源的容器编排管理系统，通过使用Kubernetes技术能够简化应用部署流程、减少服务从开发到上线所花费的时间并提高运维效率。Kubernetes集群在数据中心中非常普遍，不同的区域已经成为现实。在容器化“革命”之后，Kubernetes近年来已经成为事实上的基础设施管理标准。一方面，Kubernetes的普遍性是建立在云之上的。越来越多的提供者正在构建和交付作为服务的托管集群。另一方面，Kubernetes在本地安装（on-premise）也很受欢迎，Kubernetes丰富的生态系统可以减少与公共云的“目录（catalog）”距离。此外，边缘设置也变得越来越流行。并且，单个Kubernetes集群下有许多场景是无法满足企业需求的，主要分为以下几点：1、物理隔离。尽管Kubernetes提供了命名空间（Namespace）级别的隔离，你可以设置每个Namespace各自使用的CPU内存，甚至可以使用网络策略（Network Policy）配置不同Namespace的网络连通性，但是企业仍然需要一个更加彻底的物理隔离环境，以此避免业务之间的互相影响。2、混合云。混合云场景下，企业希望可以选择多个公有云厂商和私有云解决方案，避免受限于单一云厂商，降低一定成本。3、应用异地多副本。部署业务多个副本到不同Region集群（区域集群），避免单个区域（Region）的断电造成应用不可用的情况，实现把鸡蛋放在多个篮子目的。4、开发/测试/生产环境。为了区分开发、测试、生产环境，将这些环境分别部署到不同的集群。5、可拓展性。提高集群的拓展性，突破单一集群的节点上限。因此越来越多的项目专注于将多个Kubernetes集群建立连接，构成集群联邦的形式。尽管集群联邦增加了相应的复杂性，但普遍存在的多集群拓扑引入了新的令人兴奋的潜力。这种潜力超越了目前所探索的通过多个集群进行的简单静态应用程序编排。事实上，多集群拓扑对于跨不同位置编排应用程序和统一对基础设施的访问非常有用。其中，这引入了一种令人兴奋的可能性，可以透明而快速地将应用程序从一个集群迁移到另一个集群。在处理集群灾难或关键基础设施干预、扩展或布局优化时，移动工作负载是可行的。

现有的集群联邦技术大部分引入了中心化的控制面，即在集群之上再安装一个中心管理层来管理接入的各个集群，这样增加了整个系统的复杂性和不可靠性，同时又引入过多的API，也是增加了系统的复杂性。Kubernetes官方的 Federation v1集群联邦方案，在管控的多个Kubernetes集群之外还有额外的API-Server (基于Kube-Apiserver开发)和Controller-Manager(同Kube-Controller-Manager类似) ，下面是被管控的集群，多集群的资源分发需要在上面集群创建，然后最终被分发到下面的各个集群去。在Federation v1里面创建Pod，与普通的Pod区别就是多了一些Annotation字段，里面主要存了一些分发资源的逻辑，从中我们也能看到 v1的一些缺点。引入了单独开发的API-Server，带来了额外的维护成本；在Kubernetes里一个API是通过Group/Version/Kind确定的，但是Federationv1里面对于Kubernetes原生API、Group/Version/Kind固定，导致对不同版本的集群API兼容性很差；设计之初未考虑RBAC，无法提供跨集群的权限控制；基于Annotation的资源分发让整个API过于臃肿，不够优雅。由于Federation v1的这些缺点，Kubernetes社区逐渐弃用了v1的设计思想，吸取了v1的一些教训，推出了v2版本，也就是Kubernetes官方的Kubernetes Cluster Federation（又名KubeFed）项目。KubeFed最大的特点就是基于CRD和Controller的方式替换掉了v1基于Annotation分发资源的方案，没有侵入原生的Kubernetes API，也没有引入额外的API-Server。KubeFed允许你从一个托管集群中的一组API协调多个Kubernetes集群的配置。为此，KubeFed用一种新的语义扩展了传统的Kubernetes API，该语义表示应该为特定的部署选择哪些集群（通过“覆盖”和“集群选择器”）。当然Kubefed也不是完美无瑕的，也有其一定的局限性。从前面可以看到，其API定义复杂，容易出错，也只能使用kubefedctl加入和解绑集群，没有提供单独的SDK。再就是它要求控制层集群到管控集群必须网络可达，单集群到多集群需要改造API，旧版本也不支持联邦资源的状态收集。

GitOps是一个建立良好的框架来编排CI/CD工作流程。其基本思想是使用git仓库作为应用程序部署的单一数据源，并更新集群的相应对象。面对多集群拓扑结构，GitOps可以代表一个基本的多集群控制平面。在这样的场景中，应用程序使用合适集群的正确值进行模板化，然后部署到目标集群上。这种方法结合适当的网络互连工具，允许你获得多集群编排，而无需处理额外API的复杂性。然而，GitOps方法缺乏跨多集群拓扑的动态Pod放置。它们不支持任何主动灾难恢复策略或跨集群爆发。特别是，不可能跨集群自动迁移工作负载以响应意外故障或快速处理不可阻止的负载峰值。

公开号为CN111782370A的中国专利文献公开了一种kubernetes多集群管理系统、方法、终端及存储介质，其记载了多集群管理系统为基于分布式任务调度框架和grpc协议构建的系统；系统包括客户端和服务端，客户端将kubernete集群任务分解为设定数量的任务，按照任务角色对任务及任务节点进行划分，服务端通过解析器生成由任务组成的有向无环图，调用控制器将有向无环图中的任务分发给客户端中与任务的任务角色相对应的任务节点。该现有技术实现了多个k8s集群并行的部署、删除、扩缩容等操作，提升了操作效率，且任务状态、进度随时可查；同时使用grpc取代ssh的连接方式，解决了ssh在诸多网络环境中无法使用的问题。但是，该现有技术包含了中心化的控制面服务程序，不是去中心化的方式，增加了整个系统的复杂性。

发明内容

本发明要解决的技术问题：针对现有技术的上述问题，提供一种去中心化的Kubernetes集群联邦实现方法及系统，本发明在Kubernetes集群联邦方案中可通过不引入中心化的管理层来控制和分发资源，同时又能够减少过多的API引入来实现集群联邦。

为了解决上述技术问题，本发明采用的技术方案为：

一种去中心化的Kubernetes集群联邦实现方法，包括：

1）待添加Kubernetes集群创建用于记录本集群信息的集群配置资源；

2）待添加Kubernetes集群将集群配置资源分发给主Kubernetes集群，监测主Kubernetes集群是否创建点请求资源，若主Kubernetes集群创建点请求资源则跳转执行下一步；

3）待添加Kubernetes集群依据主Kubernetes集群创建的点请求资源创建一个用于保持与主Kubernetes集群连接的广播器组件，所述广播器组件根据集群配置资源创建一广告CRD资源，所述广告CRD资源包含了主Kubernetes集群共享资源的信息，并作为广播者实施的保持通话机制的核心定期刷新共享资源的信息；在待添加Kubernetes集群接受广播器组件后，广播器组件以虚拟节点的形式在待添加Kubernetes集群中创建一个虚拟Kubernetes集群，该虚拟Kubernetes集群的可用资源量等于接受的共享配额，以使得待添加Kubernetes集群作为主Kubernetes集群的一个节点组成Kubernetes集群联邦，主Kubernetes集群中标准的Kubernetes调度器在待添加Kubernetes集群上部署Pod应用。

可选地，步骤2）中待添加Kubernetes集群将集群配置资源分发给主Kubernetes集群具体是指待添加Kubernetes集群将集群配置资源中记录的信息注册到mDNS中心，然后通过mDNS中心以mDNS协议分发给局域网中的主Kubernetes集群，所述mDNS中心是指局域网中为待添加Kubernetes集群、主Kubernetes集群两者提供mDNS协议通讯的控制节点。

可选地，步骤2）中待添加Kubernetes集群将集群配置资源分发给主Kubernetes集群之后，还包括主Kubernetes集群创建点请求资源的步骤：主Kubernetes集群基于分发的集群配置资源创建外部集群资源，基于外部集群资源为待添加Kubernetes集群创建点请求资源，并与待添加Kubernetes集群进行通信以将创建的点请求资源发送给待添加Kubernetes集群。

可选地，步骤2）中待添加Kubernetes集群将集群配置资源分发给主Kubernetes集群，以及主Kubernetes集群基于分发的集群配置资源创建外部集群资源，基于外部集群资源为待添加Kubernetes集群创建点请求资源，并与待添加Kubernetes集群进行通信以将创建的点请求资源发送给待添加Kubernetes集群，均为基于预先配置的一个用于实现发现功能的Pod应用实现的。

可选地，步骤3）中待添加Kubernetes集群依据主Kubernetes集群创建的点请求资源创建一个用于保持与主Kubernetes集群连接的广播器组件为基于预先配置的一个用于实现点请求功能的Pod应用实现的。

可选地，步骤3）中广播器组件根据集群配置资源创建一广告CRD资源为基于预先配置的一个用于实现广播功能的Pod应用实现的。

可选地，步骤3）中广播器组件以虚拟节点的形式在待添加Kubernetes集群中创建一个虚拟Kubernetes集群为基于预先配置的一个用于实现广告功能的Pod应用实现的。

可选地，步骤3）之后还包括待添加Kubernetes集群、主Kubernetes集群两者互换角色后重新执行步骤1）～步骤3）以通过原待添加Kubernetes集群中标准的Kubernetes调度器在原主Kubernetes集群上部署Pod应用。

此外，本发明还提供一种去中心化的Kubernetes集群联邦实现系统，包括通过局域网相连的多个Kubernetes集群，所述多个Kubernetes集群中至少两个Kubernetes集群分别作为待添加Kubernetes集群、主Kubernetes集群被编程或配置以执行所述去中心化的Kubernetes集群联邦实现方法的步骤。

此外，本发明还提供一种计算机可读存储介质，该计算机可读存储介质中存储有被编程或配置以执行所述去中心化的Kubernetes集群联邦实现方法的计算机程序。

和现有技术相比，本发明具有下述优点：

1、本发明方法没有引入中心化的控制器。现有Kubernetes集群联邦技术都是主集群安装控制器，然后从集群安装代理组件，从而以主集群为中心来控制从集群。

2、本发明方法实现的多集群方案而没有过多的API引入。现有Kubernetes集群联邦的主从方式，要想从主集群调度应用到从集群，必须引入分发应用到具体从集群的API，而本发明集群2作为集群1的节点，分发应用在Kubernetes看来就像是调度应用到某个节点一样，不需要额外引入API。

3、自动发现集群并添加集群。现有Kubernetes集群联邦的主从方式必须要到从集群执行命令安装agent组件（代理组件），从而组成集群联邦。而本发明通过待添加Kubernetes集群将集群配置资源分发给主Kubernetes集群，监测主Kubernetes集群是否创建点请求资源，可自动发现别的集群，因此不像其他多集群方案还需要到待添加的集群中执行添加命令。

附图说明

图1为本发明实施例方法的基本流程示意图。

图2为本发明实施例方法与现有方法构建的Kubernetes集群联邦对比示意图。

具体实施方式

本发明去中心化的Kubernetes集群联邦实现方法及系统涉及Kubernetes集群技术，为了便于下文阅读，在此先行解释下文涉及的部分术语的含义，下文涉及的主要英文术语解释如下：Kubernetes：是一个开源的容器编排管理工具。Pod：在Kubernetes中，最小的管理元素不是一个个独立的容器而是Pod，Pod是一组容器的集合。Virtual Kubelet：是一个KubernetesKubele实现，它伪装成Kubelet，将Kubernetes连接到其他API。初始的VK实现将远程服务建模为集群的节点，从而在Kubernetes集群中引入无服务器计算。LAN mDNS：即多播dns（Multicast DNS），mDNS主要实现了在没有传统DNS服务器的情况下使局域网内的主机实现相互发现和通信，使用的端口为5353，遵从dns协议，使用现有的DNS信息结构、名语法和资源记录类型。CRD：Custom Resource Definition。顾名思义，它指的就是，允许用户在Kubernetes中添加一个同Pod、Node资源类似的、新的API资源类型，即：自定义API资源。

如图1所示，本实施例去中心化的Kubernetes集群联邦实现方法包括：

1）待添加Kubernetes集群（图1中记为集群2）创建用于记录本集群信息的集群配置资源，如示例1所示；

示例1：集群配置资源示例。

apiVersion: crd.k8s.io/v1

kind: ClusterConfig

metadata:

name: kylin-configuration

spec:

apiServerConfig:

address: "192.168.84.134"

port: 6443

discoveryConfig

authService: "_kylin_auth._tcp"

autojoin: true

enableAdvertisement: true

clusterID: ca8de913-61e3-4a3b-b9f5-55c85c01ab6d

示例1中，apiVersion表示API版本，kind为资源类型，metadata为索引数据，name为集群配置资源的名称，spec表示配置字段，apiServerConfig为API服务器配置，包括API服务器地址address和端口port，discoveryConfig为发现服务配置，包括认证服务authService、自动加入选项autojoin、使能广告服务选项enableAdvertisement以及集群的ID标记clusterID。

本实施例中，集群配置资源（clusterconfigs资源）用于记录本集群信息，如集群的kube-apiserver的地址及端口，参见示例1，注册到mdns中心需要的authService名及自动发现局域网内其他集群的开关和是否开启广播器以及集群ID等配置信息等。这些信息注册到mdns中心后，局域网内的其他打开autojoin开关的集群便能够发现这些信息，然后执行添加集群的操作。

2）待添加Kubernetes集群将集群配置资源分发给主Kubernetes集群（图1中记为集群1），监测主Kubernetes集群是否创建点请求资源（peeringrequests资源），如示例2所示，若主Kubernetes集群创建点请求资源则跳转执行下一步；

示例2：点请求资源示例。

apiVersion: crd.k8s.io/v1

kind: PeeringRequest

metadata:

name: ca8de913-61e3-4a3b-b9f5-55c85c01ab6d

spec:

clusterIdentity:

clusterID: ca8de913-61e3-4a3b-b9f5-55c85c01ab6d

kubeConfigRef

apiVersion: v1

kind: Secret

name: pr-ca8de913-61e3-4a3b-b9f`5-55c85c01ab6d

namespace: kylin-cluster

Uid: f5f2fb45-3496-419c-abdb-180611759ab2

示例2中，clusterIdentity为集群身份，其中包含集群的ID标记clusterID；kubeConfigRef为Kubernetes中的secret资源（密码资源，用于保存密钥等敏感信息的资源），包括secret资源的API版本apiVersion，secret资源的类型kind，secret资源的名称name ，secret资源所属的命名空间namespace，全部ID标记Uid。该secret资源记录着待添加集群的kubeconfig文件。其余字段与示例1相同。

本实施例中，点请求资源（peeringrequests资源）用于主集群记录待添加集群的信息，如待添加集群的集群ID及Secret信息，Secret保存着用于访问待添加集群的kube-apiserver的kubeconfig信息（保存着用于和待添加集群的kube-apiserver通信的证书及密钥），有了kubeconfig信息后，主集群即可在待添加集群创建资源。

3）待添加Kubernetes集群依据主Kubernetes集群创建的点请求资源创建一个用于保持与主Kubernetes集群连接的广播器组件，广播器组件根据集群配置资源创建一广告CRD资源（advertisement资源）如示例3所示，广告CRD资源包含了主Kubernetes集群共享资源的信息，并作为广播者实施的保持通话机制的核心定期刷新共享资源的信息；在待添加Kubernetes集群接受广播器组件后，广播器组件以虚拟节点的形式在待添加Kubernetes集群中创建一个虚拟Kubernetes集群，该虚拟Kubernetes集群的可用资源量等于接受的共享配额，以使得待添加Kubernetes集群作为主Kubernetes集群的一个节点组成Kubernetes集群联邦，主Kubernetes集群中标准的Kubernetes调度器在待添加Kubernetes集群上部署Pod应用。

示例3：广告CRD资源示例。

apiVersion: crd.k8s.io/v1

kind: Advertisement

metadata:

name: advertisement-ca8de913-61e3-4a3b-b9f5-55c85c01ab6d

spec:

clusterID: ca8de913-61e3-4a3b-b9f5-55c85c01ab6d

neighbors:

cpu: 1737m

memory: 4757M

pods: "33"

status:

kCreated: true

示例3中，索引数据metadata中的name是指广告CRD资源的名称，配置字段spec中的neighbors是指主Kubernetes集群共享资源的信息，包括CPU资源cpu、内存资源memory以及Pod应用（pods），状态status中的vkCreated是指virtual-kubelet的创建状态。其余字段与示例1相同。

为了简化集群配置资源的分发，避免引入过多协议，提升系统的兼容性，如图1所示，本实施例步骤2）中待添加Kubernetes集群将集群配置资源分发给主Kubernetes集群具体是指待添加Kubernetes集群将集群配置资源中记录的信息如示例1所示，注册到mDNS中心，此时局域网中的主Kubernetes集群中的kylinCluster应用包含的discovery应用中的协程会自动发现注册到mDNS中心的数据，discovery应用中的协程自程序运行后就一直监控着mDNS中心，只要中心出现数据就会发现数据和使用数据执行下面的步骤。

参见图1，步骤2）中主Kubernetes集群获取待添加Kubernetes集群的集群配置资源之后，主Kubernetes集群会利用获取到的资源数据创建点请求资源的步骤：主Kubernetes集群基于获取到的集群配置资源创建外部集群资源（foreignclusters资源），基于外部集群资源为待添加Kubernetes集群创建点请求资源（peeringrequests资源，里面保存着待添加集群的集群id以及待添加集群的kubeconfig信息等）如示例2所示，并与待添加Kubernetes集群进行通信以将创建的点请求资源发送给待添加Kubernetes集群。

本实施例中，步骤3）中广播器组件命名为Broadcaster，广播器组件是负责保持与主Kubernetes集群的连接的组件；广播器组件根据集群配置资源创建一广告CRD资源，本实施例中该广告CRD资源命名为advertisements，如示例3所示，这个资源有两个主要功能。一方面，它包含了主集群共享资源的信息。另一方面，它代表了广播者实施的保持通话机制的核心，定期刷新共享资源的信息，类似于网络设备之间的情况。一旦待添加集群接受了advertisements，那么在待添加集群的kylinCluster应用就会以虚拟节点的形式在本集群中创建一个virtual-kubelet，virtual-kubelet创建完成的同时将advertisements资源的status中的vkCreated标志设置为true。并且待添加集群的可用资源量等于接受的共享配额。创建的virtual-kubelet这个pod挂载有主集群的kubeconfig文件，这样virtual-kubelet充当待添加集群的kubelet组件，将待添加集群模拟成主集群的一个工作节。此时，该工作节点上的virtual-kubelet便负责和主集群的kube-apiserver组件通信，一方面及时上报本节点的状态信息，另一方面，主集群创建的Pod应用调度到该节点时virtual-kubelet负责获取解析Pod应用的PodSpec内容的期望状态（运行什么容器、运行的副本数量、网络或者存储如何配置等等），并调用对应的容器平台接口达到这个状态。简单来讲就是主集群中标准的Kubernetes调度器就可以在待添加集群（此时待添加集群作为主集群的一个节点，已经组成了集群联邦）上部署Pod应用。

参见图1，本实施例方法是在传统Kubernetes集群的基础上增加了一个应用程序（本实施例中命名为kylinCluster）来实现的。为了实现待添加Kubernetes集群、主Kubernetes集群的无差异化安装，本实施例中为上述各个步骤采用了模块化的方式来实现。

参见图1，本实施例步骤2）中待添加Kubernetes集群将集群配置资源分发给主Kubernetes集群，以及主Kubernetes集群基于分发的集群配置资源创建外部集群资源，基于外部集群资源为待添加Kubernetes集群创建点请求资源，并与待添加Kubernetes集群进行通信以将创建的点请求资源发送给待添加Kubernetes集群，均为基于预先配置的一个用于实现发现功能的Pod应用实现的，本实施例中该用于实现发现功能的Pod应用记为discovery Pod，毫无疑问其实现不依赖于特定的名称。discovery这个Pod的实现思路一方面利用mDNS协议注册自身集群的信息供其他集群发现，同时也能发现其他集群的信息，另一方面利用Kubernetes的Operator 思想，编码foreignclusters这个CRD对应的controller控制器程序，控制器程序用于解析foreignclusters保存的信息来创建peeringrequests这个CRD资源。discovery这个Pod的功能：1、集群1利用mDNS协议发现局域网内的集群2的信息，然后创建一个foreignclusters资源用于保存发现的集群2的信息；2、解析foreignclusters资源并去集群2创建peeringrequests资源，用于向集群2发起创建Broadcaster的请求。

参见图1，本实施例步骤3）中待添加Kubernetes集群依据主Kubernetes集群创建的点请求资源创建一个用于保持与主Kubernetes集群连接的广播器组件为基于预先配置的一个用于实现点请求功能的Pod应用实现的，本实施例中该用于实现点请求功能的Pod应用记为peering-request Pod，毫无疑问其实现不依赖于特定的名称。peering-request这个Pod实现思路是编码点请求（peeringrequests）这个CRD对应的控制器（controller）程序，控制器程序用于解析peeringrequests保存的信息来创建broadcaster这个Pod。peering-request这个Pod的功能：解析peeringrequests资源并创建broadcaster（广播器），广播器负责保持与集群1的连接。

参见图1，本实施例步骤3）中广播器组件根据集群配置资源创建一广告CRD资源为基于预先配置的一个用于实现广播功能的Pod应用实现的，本实施例中该用于实现广播功能的Pod应用记为broadcastert Pod，毫无疑问其实现不依赖于特定的名称。broadcaster这个Pod实现思路是解析clusterconfigs保存的信息来创建advertisements这个CRD资源。broadcaster这个Pod的功能：集群2创建advertisements资源，advertisements资源包含了集群1共享资源的信息，同时也定期刷新共享资源的信息。

参见图1，本实施例步骤3）中广播器组件以虚拟节点的形式在待添加Kubernetes集群中创建一个虚拟Kubernetes集群为基于预先配置的一个用于实现广告功能的Pod应用实现的，本实施例中该用于实现广告功能的Pod应用记为advertisement Pod，毫无疑问其实现不依赖于特定的名称。advertisement这个Pod实现思路是编码advertisements这个CRD对应的controller控制器程序，控制器程序用于解析advertisements保存的信息来创建virtual-kubelet这个Pod，advertisement这个Pod的功能：根据advertisements资源，集群2创建一个virtual-kubelet，这样集群2就可以作为集群1的一个节点和集群1组成集群联邦。

本实施例步骤3）之后还包括待添加Kubernetes集群、主Kubernetes集群两者互换角色后重新执行步骤1）～步骤3）以通过原待添加Kubernetes集群中标准的Kubernetes调度器在原主Kubernetes集群上部署Pod应用。参见图1，待添加Kubernetes集群、主Kubernetes集群两者互换角色后，集群1成为新的待添加Kubernetes集群，集群2成为新的主Kubernetes集群，同样也可以重新执行步骤1）～步骤3）以通过原待添加Kubernetes集群中标准的Kubernetes调度器在原主Kubernetes集群上部署Pod应用。

本实施例去中心化的Kubernetes集群联邦实现方法利用Kubernetes的Operator思想，即CRD和控制器（Controller）的一种组合特例。在Kubernetes集群中用CRD（CustomResource Definition）扩展kube-apiserver组件（Kubernetes集群的API服务组件）的API资源，比如扩展一个保存集群信息的资源，然后编写控制器代码，利用集群信息这个资源，用于实现添加集群的功能。CRD指的就是，允许用户在Kubernetes中添加一个同Pod、Node（节点）资源类似的、新的API资源类型，即：自定义API资源。本实施例去中心化的Kubernetes集群联邦实现方法的目的是将不同的Kubernetes集群组合成集群联邦。如图2中（a）所示，传统的Kubernetes集群联邦实现方法需要一个Kubernetes集群K1作为中心节点，而Kubernetes集群K2/K3为Kubernetes集群K1的成员集群，资源下放需要经过一次中心Kubernetes集群K1的推送（push）；而本实施例方法利用Virtual Kubelet技术，VirtualKubelet可以将服务伪装成一个Kubernetes集群的节点，模拟Kubelet加入这个集群。这样就可以水平拓展Kubernetes集群。如图2中（b）所示，本实施例Kubernetes集群联邦实现方法实现的Kubernetes集群联邦中，Kubernetes集群之间不存在联邦关系，Kubernetes集群K2/K3只是Kubernetes集群K1 的一个节点，因此在部署应用的时候，完全不需要引入任何的API，Kubernetes集群K2/K3看起来就是Kubernetes集群K1的节点，这样业务就可以无感知的被部署到不同的集群上去，因此本实施例去中心化的Kubernetes集群联邦实现方法极大减少了单集群到多集群改造的复杂性。

本实施例去中心化的Kubernetes集群联邦实现方法抛开现有Kubernetes集群联邦的主从架构思想，创造性的利用mDNS协议使Kubernetes集群相互发现，并利用virtual-kubelet技术使集群2（待添加Kubernetes集群）作为集群1（主Kubernetes集群）的一个节点，从而达到实现去中心化集群联邦架构的目的。与现有Kubernetes集群联邦的主从架构思想相比，本实施例去中心化的Kubernetes集群联邦实现方法具有下述优点：（1）没有引入中心化的控制器。现有Kubernetes集群联邦技术都是主集群安装控制器，然后从集群安装代理组件，从而以主集群为中心来控制从集群；（2）实现多集群方案而没有过多的API引入。现有Kubernetes集群联邦的主从方式，要想从主集群调度应用到从集群，必须引入分发应用到具体从集群的API，而本发明集群2作为集群1的节点，分发应用在Kubernetes看来就像是调度应用到某个节点一样，不需要额外引入API；（3）自动发现集群并添加集群。现有Kubernetes集群联邦的主从方式必须要到从集群执行命令安装agent组件（代理组件），从而组成集群联邦。而本发明使用mDNS协议，自动发现别的集群，因此不像其他多集群方案还需要到待添加的集群中执行添加命令。

此外，本发明还提供一种去中心化的Kubernetes集群联邦实现系统，包括通过局域网相连的多个Kubernetes集群，所述多个Kubernetes集群中至少两个Kubernetes集群分别作为待添加Kubernetes集群、主Kubernetes集群被编程或配置以执行前述去中心化的Kubernetes集群联邦实现方法的步骤。

此外，本发明还提供一种计算机可读存储介质，该计算机可读存储介质中存储有被编程或配置以执行前述去中心化的Kubernetes集群联邦实现方法的计算机程序。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可读存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。本申请是参照根据本申请实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

以上所述仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理前提下的若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种去中心化的Kubernetes集群联邦实现方法，其特征在于，包括：

1）待添加Kubernetes集群创建用于记录本集群信息的集群配置资源；

2）待添加Kubernetes集群将集群配置资源分发给主Kubernetes集群，监测主Kubernetes集群是否创建点请求资源，若主Kubernetes集群创建点请求资源则跳转执行下一步；

3）待添加Kubernetes集群依据主Kubernetes集群创建的点请求资源创建一个用于保持与主Kubernetes集群连接的广播器组件，所述广播器组件根据集群配置资源创建一广告CRD资源，所述广告CRD资源包含了主Kubernetes集群共享资源的信息，并作为广播者实施的保持通话机制的核心定期刷新共享资源的信息；在待添加Kubernetes集群接受广播器组件后，广播器组件以虚拟节点的形式在待添加Kubernetes集群中创建一个虚拟Kubernetes集群，该虚拟Kubernetes集群的可用资源量等于接受的共享配额，以使得待添加Kubernetes集群作为主Kubernetes集群的一个节点组成Kubernetes集群联邦，主Kubernetes集群中标准的Kubernetes调度器在待添加Kubernetes集群上部署Pod应用。

2.根据权利要求1所述的去中心化的Kubernetes集群联邦实现方法，其特征在于，步骤2）中待添加Kubernetes集群将集群配置资源分发给主Kubernetes集群具体是指待添加Kubernetes集群将集群配置资源中记录的信息注册到mDNS中心，然后通过mDNS中心以mDNS协议分发给局域网中的主Kubernetes集群，所述mDNS中心是指局域网中为待添加Kubernetes集群、主Kubernetes集群两者提供mDNS协议通讯的控制节点。

3.根据权利要求2所述的去中心化的Kubernetes集群联邦实现方法，其特征在于，步骤2）中待添加Kubernetes集群将集群配置资源分发给主Kubernetes集群之后，还包括主Kubernetes集群创建点请求资源的步骤：主Kubernetes集群基于分发的集群配置资源创建外部集群资源，基于外部集群资源为待添加Kubernetes集群创建点请求资源，并与待添加Kubernetes集群进行通信以将创建的点请求资源发送给待添加Kubernetes集群。

4.根据权利要求3所述的去中心化的Kubernetes集群联邦实现方法，其特征在于，步骤2）中待添加Kubernetes集群将集群配置资源分发给主Kubernetes集群，以及主Kubernetes集群基于分发的集群配置资源创建外部集群资源，基于外部集群资源为待添加Kubernetes集群创建点请求资源，并与待添加Kubernetes集群进行通信以将创建的点请求资源发送给待添加Kubernetes集群，均为基于预先配置的一个用于实现发现功能的Pod应用实现的。

5.根据权利要求4所述的去中心化的Kubernetes集群联邦实现方法，其特征在于，步骤3）中待添加Kubernetes集群依据主Kubernetes集群创建的点请求资源创建一个用于保持与主Kubernetes集群连接的广播器组件为基于预先配置的一个用于实现点请求功能的Pod应用实现的。

6.根据权利要求5所述的去中心化的Kubernetes集群联邦实现方法，其特征在于，步骤3）中广播器组件根据集群配置资源创建一广告CRD资源为基于预先配置的一个用于实现广播功能的Pod应用实现的。

7.根据权利要求6所述的去中心化的Kubernetes集群联邦实现方法，其特征在于，步骤3）中广播器组件以虚拟节点的形式在待添加Kubernetes集群中创建一个虚拟Kubernetes集群为基于预先配置的一个用于实现广告功能的Pod应用实现的。

8.根据权利要求1所述的去中心化的Kubernetes集群联邦实现方法，其特征在于，步骤3）之后还包括待添加Kubernetes集群、主Kubernetes集群两者互换角色后重新执行步骤1）～步骤3）以通过原待添加Kubernetes集群中标准的Kubernetes调度器在原主Kubernetes集群上部署Pod应用。

9.一种去中心化的Kubernetes集群联邦实现系统，包括通过局域网相连的多个Kubernetes集群，其特征在于，所述多个Kubernetes集群中至少两个Kubernetes集群分别作为待添加Kubernetes集群、主Kubernetes集群被编程或配置以执行权利要求1～8中任意一项所述去中心化的Kubernetes集群联邦实现方法的步骤。

10.一种计算机可读存储介质，其特征在于，该计算机可读存储介质中存储有被编程或配置以执行权利要求1～8中任意一项所述去中心化的Kubernetes集群联邦实现方法的计算机程序。

Images