CN113849266A - 多Kubernetes集群的业务部署方法及装置 - Google Patents

Abstract

本申请实施例提供了一种多Kubernetes集群的业务部署方法及装置，通过获取业务部署的配置信息，根据配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes集群，在目标Kubernetes集群为多个的情况下，在多个目标Kubernetes集群中同时进行业务部署，业务部署包括部署至少一种资源，业务部署的配置信息包括至少一种资源的配置信息。因此，通过配置信息确定出需要进行业务部署的目标Kubernetes集群之后，能同时进行业务部署，避免了分别在多个Kubernetes集群上逐一进行业务部署，而产生大量的重复工作的问题，提高业务部署的效率。

Description

多Kubernetes集群的业务部署方法及装置

技术领域

本发明涉及容器集群技术领域，尤其涉及一种多Kubernetes集群的业务部署方法及装置。

背景技术

Kubernetes作为一个容器编排引擎，具有支持自动化部署、大规模可伸缩、应用容器化管理的特点。在生产环境中部署一个业务时，往往一个业务需要部署路由(Ingress)、服务(Service)、部署(Deployment)等资源。

在多Kubernetes集群的环境下，一个业务需要部署Ingress、Service、Deployment等资源到多个不同的Kubernetes集群上，也就是说，需要逐一在多个Kubernetes集群上分别进行Ingress、Service、Deployment等资源的创建部署，如此会产生大量的重复工作，业务部署的效率过低。

发明内容

本申请实施例的目的是提供一种多Kubernetes集群的业务部署方法及装置，以解决业务部署的效率过低的问题。

为了解决上述技术问题，本申请实施例是这样实现的：

第一方面，本申请实施例提供了一种多Kubernetes集群的业务部署方法，所述方法包括：

获取业务部署的配置信息；根据所述配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes集群；在所述目标Kubernetes集群为多个的情况下，在所述多个目标Kubernetes集群中同时进行业务部署，所述业务部署包括部署至少一种资源，所述业务部署的配置信息包括部署所述至少一种资源的配置信息。

第二方面，本申请实施例提供了一种多Kubernetes集群的业务部署装置，所述装置包括：

获取模块，用于获取业务部署的配置信息；确定模块，用于根据所述配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes集群；部署模块，用于在所述目标Kubernetes集群为多个的情况下，在所述多个目标 Kubernetes集群中同时进行业务部署，所述业务部署包括部署至少一种资源，所述业务部署的配置信息包括部署所述至少一种资源的配置信息。

第三方面，本申请实施例提供了一种电子设备，包括处理器、通信接口、存储器和通信总线；其中，所述处理器、所述通信接口以及所述存储器通过总线完成相互间的通信；所述存储器，用于存放计算机程序；所述处理器，用于执行所述存储器上所存放的程序，实现如第一方面所述的多Kubernetes集群的业务部署方法步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时，实现如第一方面所述的多Kubernetes集群的业务部署方法步骤。

第五方面，本申请实施例提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现如第一方面所述的多Kubernetes集群的业务部署方法。

由以上本申请实施例提供的技术方案可见，通过获取业务部署的配置信息，根据配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes 集群，在所述目标Kubernetes集群为多个的情况下，在多个目标Kubernetes集群中同时进行业务部署，业务部署包括部署至少一种资源，业务部署的配置信息包括至少一种资源的配置信息。因此，通过配置信息确定出需要进行业务部署的目标Kubernetes集群之后，能在多个目标Kubernetes集群同时进行业务部署，避免了分别在多个Kubernetes集群上逐一进行业务部署，而产生大量的重复工作的问题，提高业务部署的效率。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供一种多Kubernetes集群的业务部署方法的第一种流程示意图；

图2为本申请实施例提供一种多Kubernetes集群的业务部署方法的第二种流程示意图；

图3为本申请实施例提供一种多Kubernetes集群的业务部署方法的第三种流程示意图；

图4为本申请实施例提供一种多Kubernetes集群的业务部署方法的第四种流程示意图；

图5为本申请实施例提供一种多Kubernetes集群的业务部署方法的第五种流程示意图；

图6为本申请实施例提供一种多Kubernetes集群的业务部署的功能模块示意图；

图7为本申请实施例提供的多Kubernetes集群的业务部署装置的模块组成示意图；

图8为本申请实施例提供的电子设备的结构示意图。

具体实施方式

本申请实施例提供了一种多Kubernetes集群的业务部署方法及装置，提高了业务部署的效率。

为了使本技术领域的人员更好地理解本发明中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

一些场景下，在Kubernetes中，路由(Ingress)、服务(Service)、部署(Deployment)、存储(Storage)、容器(Pod)、角色(Role)、账户(Accoutn)、配置(ConfigMap)等都可以作为Kubernetes的对象，通过管理这些对象来管理整个 kubernetes集群。

在多Kubernetes集群的应用环境下，往往一个业务需要部署路由(Ingress)、服务(Service)、部署(Deployment)等资源到多个不同的Kubernetes集群上，需要分别在多个Kubernetes集群上进行路由(Ingress)、服务(Service)、部署(Deployment)等资源的创建，产生大量的重复工作，业务的部署的效率过低。

进一步，在多Kubernetes集群上部署的路由(Ingress)、服务(Service)、部署(Deployment)等资源，无法保证多Kubernetes集群上资源的一致性，无法对多 Kubernetes集群进行统一管理及修改，不能自动协调，管理效率低且后期维护性差。

为了解决以上技术问题，本申请实施例提供了一种多Kubernetes集群的业务部署方法，下面结合附图进行详细说明。

如图1所示，本申请实施例提供一种多Kubernetes集群的业务部署方法，该方法的执行主体可以为服务器，其中，该服务器可以是独立的服务器，也可以是由多个服务器组成的服务器集群。该多Kubernetes集群的业务部署方法具体可以包括以下步骤S101-S103：

在S101中，获取业务部署的配置信息。

具体来讲，业务部署的配置信息可以是用户通过万维网(WorldWideWeb)，Web前端进行自定义设置的。用户可以通过Web前端调用Kubernetes集群的操作接口，用户可以通过该操作接口查看、操作和管理Kubernetes集群。

在一种可能的实现方式中，配置信息中的自定义资源包括自定义资源的数据结构、多集群部署自定义资源和自定义资源的状态数据结构。

自定义资源的数据结构包括但不限于：命名空间(Namespace)的配置信息，用于定义业务需要部署的命名空间。与容器相关的容器说明(PodSpec)，用于说明容器(Pod)的相关配置，包括镜像地址、环境变量、挂载卷以及端口等相关配置说明。与服务相关的服务说明(ServiceSpec)，用于说明服务的相关配置，包括服务端口、服务名、服务协议等相关配置说明。与Kubernetes 集群相关的标识信息(ClusterSpec)，包括部署策略、需要进行业务部署的 Kubernetes集群的集群名称和集群身份标识号(Identitydocument，ID)以及副本数等相关配置。与路由相关的路由说明(IngressSpec)，用于说明路由的相关配置，包括域名、注解等相关配置。级联删除的配置信息，用于标识是否在多Kubernetes集群资源删除时，删除目标Kubernetes集群上已经创建的 Deployment、Service、Ingress资源。重写说明的配置信息(Override)，用于表示Kubernetes集群上的路由配置信息需要重写，保证Kubernetes集群之间部分配置可以存在差异性。

自定义资源的状态数据结构包括但不限于：最后扩缩容时间 (LastScaleTime)，用于表示多Kubernetes集群部署业务时最后一次扩缩容的时间。期望的副本数(DesiredReplicas)，用于表示多Kubernetes集群部署中每个Kubernetes集群的副本数总和。更新的副本数(UpdatedReplicas)，用于表示多Kubernetes集群部署中每个Kubernetes集群的Deployment在发生更新后，已经完成更新的副本数总和。就绪的副本数(ReadyReplicas)，用于表示多 Kubernetes集群部署中每个Kubernetes集群的Deployment在发生更新后，已经就绪的副本数总和。可用的副本数(AvailableReplicas)，用于表示多Kubernetes 集群部署中每个Kubernetes集群的Deployment在发生更新后，已经可用的副本数总和。不可用的副本数(UnavailableReplicas)，用于表示多Kubernetes集群部署中每个Kubernetes集群的Deployment在发生更新后，不可用的副本数总和。条件(Conditions)，用于表示具体不可用的原因，以Kubernetes集群维度显示对应Kubernetes集群下面对应的资源的状态，包括Deployment、Service、 Ingress等资源的状态及原因信息。

多集群部署自定义资源，用于定义多Kubernetes集群的资源的配置信息。如定义需要在哪些Kubernetes集群上进行业务部署、定义业务部署在哪个命名空间、定义业务的域名以及定义如何展示多集群部署状态等。

进一步，在一种可能的实现方式中，可以选择任意一个Kubernetes集群进行多集群部署自定义资源的部署，用户可以通过web前端在该Kubernetes集群自定义设置配置信息。在部署时，需要对该Kubernetes集群进行基于角色的访问控制(Role-BasedAccessControl，RBAC)认证。

具体是：创建集群账户(ServiceAcount)、集群角色(ClusterRole)、集群角色绑定(ClusterRoleBinding)

其中，ServiceAccount为Pod中的进程和外部用户提供身份信息。RBAC 是Kubernetes集群基于角色的访问控制，实现授权决策，允许通过Kubernetes 集群的应用程序接口(ApplicationProgramInterface，API)动态配置策略，Role 是一组权限的集合，例如Role可以包含列出Pod权限及列出Deployment权限， Role用于给某个NameSpace中的资源进行鉴权。ClusterRole是一组权限的集合，ClusterRole可以在包括所有NameSpce和Kubernetes集群级别的资源或非资源类型进行鉴权。

在完成身份验证后，用户可以通过该Kubernetes集群自定义配置信息。

在S102中，根据配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes集群。

具体来讲，配置信息中已经配置了进行业务部署的Kubernetes集群的信息，从而可以根据该配置信息从多个Kubernetes集群中查找到与该配置信息对应的 Kubernetes集群作为目标Kubernetes集群。该目标Kubernetes集群可以至少为两个。

例如，配置信息中定义了kubernetes-cluster-a(KubernetesClusterA)和kubernetes-cluster-b(KubernetesClusterB)，则KubernetesClusterA和KubernetesClusterB作为目标kubernetes集群进行业务部署。

在S103中，在所述目标Kubernetes集群为多个的情况下，在多个目标 Kubernetes集群中同时进行业务部署，业务部署部署至少一种资源，业务部署的配置信息包括部署所述至少一种资源的配置信息。

具体来讲，配置信息中定义的资源包括但不限于Deployment、Service、 Ingress。

例如，定义KubernetesClusterA上的资源Deployment的副本数为2，镜像为nginx和定义KubernetesClusterB上的资源Deployment的副本数为1，镜像为nginx。定义KubernetesClusterA和KubernetesClusterB上的资源Service的端口为80，协议为TCP。定义KubernetesClusterA和KubernetesClusterB上的资源Ingress的域名为“www.a01.com”，路径为：/v1。

在KubernetesClusterA和KubernetesClusterB上进行业务部署时，按照上述自定义的资源同时进行业务部署。也就是说，在执行一次业务部署的操作时，可以同时在KubernetesClusterA和KubernetesClusterB(目标Kubernetes集群)同步进行业务部署，避免产生大量的重复工作，提高了部署效率。

在一种可能的实现方式中，可以在多个目标Kubernetes集群中同时部署多个业务，不同的业务部署在不同的命名空间。

具体来讲，可以在每个目标Kubernetes集群上均可以同时部署多个业务，对于每个目标Kubernetes集群而言，由于各业务都已提前配置好配置信息，只需在部署一次的情况下，就可以将多个业务同时部署在目标Kubernetes集群，将不同的业务放到不同的命名空间，可以达到业务隔离性的要求，提高业务的安全性。

在另一种可能的实现方式中，S103包括：

在目标Kubernetes集群同时部署多种资源，不同的目标Kubernetes集群上部署的同一业务的至少部分资源的配置信息不同。

具体来讲，由于各资源都已提前配置好配置信息，只需在部署一次的情况下，就可以将多个资源同时部署在至少一个目标Kubernetes集群上。也就是说，每个目标Kubernetes集群都可以同时部署多种资源。

在定义配置信息时，可以区别化部署的部分资源的配置信息。例如，以KubernetesClusterA和KubernetesClusterB作为目标Kubernetes集群，在该两个目标Kubernetes集群上同时部署同一业务的Deployment、Service、Ingress资源，在部署时，可以区别化部署Ingress资源，也就是说，KubernetesClusterA 上的Ingress资源的配置信息和KubernetesClusterB上的Ingress资源的配置信息可以不一致。

进一步，可以通过定义Override，可以在Override中重写Ingress资源的配置信息，从而将KubernetesClusterA和KubernetesClusterB中的配置信息协调为 Override中定义的配置信息。

由以上本申请实施例提供的技术方案可见，通过配置信息确定出需要进行业务部署的目标Kubernetes集群之后，能同时进行业务部署，避免了分别在多个Kubernetes集群上逐一进行业务部署，而产生大量的重复工作的问题，提高业务部署的效率。此外，多种资源也可以一次性在目标Kubernetes集群上完成部署，进一步提高了业务部署的效率。

如图2所示，本申请实施例提供一种多Kubernetes集群的业务部署方法，该方法的执行主体可以为服务器，其中，该服务器可以是独立的服务器，也可以是由多个服务器组成的服务器集群。该多Kubernetes集群的业务部署方法具体可以包括以下步骤S201-S204：

在S201中，获取业务部署的配置信息。

在S202中，根据配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes集群。

在S203中，在所述目标Kubernetes集群为多个的情况下，在多个目标 Kubernetes集群中同时进行业务部署，业务部署部署至少一种资源，业务部署的配置信息包括部署所述至少一种资源的配置信息。

值得注意的是，S201至S203具有与S101至S103相同或类似的实现方式，其可以互相参照，本申请实施例在此不再赘述。

在S204中，将在多个目标Kubernetes集群中进行业务部署后生成的资源部署信息存储至数据库，在多个目标Kubernetes集群中的资源部署信息失效的情况下，从数据库中读取资源部署信息并在多个目标Kubernetes集群中重新进行业务部署。

具体来讲，在多个目标Kubernetes集群上成功部署业务后，将各个目标Kubernetes集群上进行业务部署生成的资源部署信息写到数据库作为数据备份。如果目标Kubernetes集群上的信息失效不可用时，可以从数据库中读取资源部署信息，重新把资源部署信息部署到目标Kubernetes集群上即可实现目标 Kubernetes集群的信息的恢复。

其中，资源部署信息包括但不限于上述实施例提到的配置信息，还可以包括目标Kubernetes集群的基本信息，如目标Kubernetes集群的标签、目标 Kubernetes集群所属的运营商、目标Kubernetes集群的网络质量、目标 Kubernetes集群上的业务部署情况、Kubernetes集群的剩余资源、Kubernetes 集群的所属区域、Kubernetes集群的镜像预热等。

由以上本申请实施例提供的技术方案可见，通过配置信息确定出需要进行业务部署的目标Kubernetes集群之后，能同时进行业务部署，避免了分别在多个Kubernetes集群上逐一进行业务部署，而产生大量的重复工作的问题，提高业务部署的效率。

此外，在目标Kubernetes集群上成功部署业务后，将目标Kubernetes集群上进行部署的信息写到数据库作为数据备份。如果目标Kubernetes集群上的信息失效不可用时，可以从数据库中读取资源部署信息，重新把资源部署信息部署到目标Kubernetes集群上即可实现目标Kubernetes集群的信息的恢复。进一步提高了部署效率。

如图3所示，本申请实施例提供一种多Kubernetes集群的业务部署方法，该方法的执行主体可以为服务器，其中，该服务器可以是独立的服务器，也可以是由多个服务器组成的服务器集群。该多Kubernetes集群的业务部署方法具体可以包括以下步骤S301-S304：

在S301中，获取业务部署的配置信息。

在S302中，根据配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes集群。

在S303中，在所述目标Kubernetes集群为多个的情况下，在多个目标 Kubernetes集群中同时进行业务部署，业务部署包括部署至少一种资源，所述业务部署的配置信息包括部署所述至少一种资源的配置信息。

值得注意的是，S301至S303具有与S101至S103相同或类似的实现方式，其可以互相参照，本申请实施例在此不再赘述。

在S304中，监控各目标Kubernetes集群上部署的资源，在多个目标 Kubernetes集群部署的资源与配置信息中定义的资源不一致的情况下，修改多个目标Kubernetes集群部署的资源。或者，在多个目标Kubernetes集群中部署的资源与配置信息中定义的资源不一致的情况下，删除多个目标Kubernetes集群中部署的资源，并根据配置信息中定义的资源在多个目标Kubernetes集群中重新进行业务部署。

具体来讲，部署在多个目标Kubernetes集群上的资源有可能会发生变化，其可能是人为操作的，也有可能是Kubernetes集群本身的协调机制所引起的变化。因此，需要实时监控多个目标Kubernetes集群上部署的资源，在多个目标 Kubernetes集群上部署的资源与配置信息中定义的资源不一致的情况下，对各目标Kubernetes集群上部署的资源进行调整，调整的方式包括但不限于：增加、修改、删除并重建(重新部署)，从而保证各个目标Kubernetes集群上部署的资源的一致性。

在一种可能的实现方式中，可以仅对部署的资源与配置信息中定义的资源不一致的目标Kubernetes集群进行资源修改和重新进行业务部署，例如，在 KubernetesClusterB上部署的Ingress资源，人为的修改了KubernetesClusterB 上Ingress资源的域名信息后，其与定义的配置信息中的Ingress资源的域名信息并不一致，需要对KubernetesClusterB上部署的Ingress资源进行调整。

在一种可能的实现方式中，调整的方式包括：根据配置信息中定义的 Ingress资源的域名信息，对KubernetesClusterB上部署的Ingress资源的域名信息进行修改。

在另一种可能的实现方式中，调整的方式包括：对KubernetesClusterB上部署的Ingress资源的域名信息进行删除，然后根据配置信息中定义的Ingress 资源的域名信息，在目标Kubernetes集群重新部署Ingress资源的域名信息。

通过上述方式，保证修改后的Ingress资源的域名信息与定义的配置信息中的Ingress资源的域名信息一致。进一步保证与KubernetesClusterA上部署的Ingress资源的一致性。

在一种可能的实现方式中，在目标Kubernetes集群上部署的资源与配置信息中定义的资源不一致的情况下，在修改目标Kubernetes集群部署的资源，或者，在删除目标Kubernetes集群部署的资源，并根据配置信息中配置的资源在目标Kubernetes集群重新部署之前，还包括：触发产生消息事件，加入消息事件至限速队列，在限速队列中上一个消息事件完成协调后，处理消息事件，处理消息事件指示对目标Kubernetes集群上部署的资源进行调整。避免上次协调没有完成就开始下次协调，而带来数据不一致的问题。

因此，通过限速队列对协调做一定的限速，避免频繁协调资源而带来数据负载过重和数据不一致的问题。

在一种可能的实现方式中，创建分布式资源锁，以目标对象对同一目标Kubernetes集群上部署的资源和配置信息进行一致性协调。也就是说，针对同一个目标Kubernetes集群，只能由一个协调器(目标对象)运行并协调。协调器在运行的时候，会通过目标Kubernetes集群的ConfigMap组件，创建 ConfigMap，ConfigMap是为了让镜像和配置文件解耦，以便实现镜像的可移植性和可复用性，此ConfigMap用来创建分布式资源锁，保证同一个目标 Kubernetes集群，只能由一个协调器(目标对象)运行。激活的协调器会不断修改ConfigMap，与ConfigMap保持心跳，其它的协调器则不能对ConfigMap 进行修改，处于非激活状态，一旦激活的协调器故障不能与ConfigMap进行心跳，则其他协调器将抢占目标Kubernetes集群的ConfigMap资源，能成功与 ConfigMap建立心跳的将成为新的激活的协调器运行在目标Kubernetes集群。

一致性协调指的是上述“在目标Kubernetes集群部署的资源与配置信息中定义的资源不一致的情况下，修改目标Kubernetes集群部署的资源。或者，删除目标Kubernetes集群部署的资源，并根据配置信息中配置的资源在目标 Kubernetes集群重新部署。”的技术内容，其可以互相参照，本申请实施例在此不再赘述。

通过本申请实施例公开的技术方案，通过配置信息确定出需要进行业务部署的目标Kubernetes集群之后，能同时进行业务部署，避免了分别在多个 Kubernetes集群上逐一进行业务部署，而产生大量的重复工作的问题，提高业务部署的效率。

此外，在目标Kubernetes集群上部署的资源与配置信息中定义的资源不一致的情况下，对目标Kubernetes集群上部署的资源进行调整，也就是说，对目标Kubernetes集群上部署的资源与配置信息进行一致性协调，保证集群之间业务的一致性。

如图4所示，本申请实施例提供一种多Kubernetes集群的业务部署方法，该方法的执行主体可以为服务器，其中，该服务器可以是独立的服务器，也可以是由多个服务器组成的服务器集群。该多Kubernetes集群的业务部署方法具体可以包括以下步骤S401-S404：

在S401中，获取业务部署的配置信息。

在S402中，根据配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes集群。

在S403中，在所述目标Kubernetes集群为多个的情况下，在多个目标 Kubernetes集群中同时进行业务部署，业务部署包括部署至少一种资源，业务部署的配置信息包括部署所述至少一种资源的配置信息。

值得注意的是，S401至S403具有与S101至S103相同或类似的实现方式，其可以互相参照，本申请实施例在此不再赘述。

在S404中，监控配置信息，在配置信息重新配置的情况下，根据重新配置后的配置信息修改多个目标Kubernetes集群部署的资源，或者，在配置信息重新配置的情况下，删除多个目标Kubernetes集群中部署的资源，并根据重新配置后的配置信息在多个目标Kubernetes集群重新进行业务部署。

具体来讲，在用户修改自定义的配置信息的情况下，会与目标Kubernetes 集群上已经部署的资源产生差异，因此，需要实时监控配置信息，在配置信息被修改(重新调整)的情况下，对各目标Kubernetes集群上已经部署的资源进行调整，调整的方式包括但不限于：增加、修改、删除并重建(重新部署)，从而保证目标Kubernetes集群上部署的资源与配置信息的一致性。

例如，在KubernetesClusterB上部署的Ingress资源，人为修改了配置信息中的Ingress资源的域名信息后，其与KubernetesClusterB上Ingress资源的域名信息并不一致，需要对KubernetesClusterB上部署的Ingress资源进行调整。

在一种可能的实现方式中，调整的方式包括：根据修改后的配置信息中定义的Ingress资源的域名信息，对KubernetesClusterB上已经部署的Ingress资源的域名信息进行修改从而保证一致性。

在另一种可能的实现方式中，调整的方式包括：对KubernetesClusterB上已经部署的Ingress资源的域名信息进行删除，然后根据修改后的配置信息中定义的Ingress资源的域名信息，在目标Kubernetes集群重新部署Ingress资源的域名信息。

在一种可能的实现方式中，在根据重新配置后的配置信息修改多个目标Kubernetes集群部署的资源，或者，删除多个目标Kubernetes集群中部署的资源，并根据重新配置后的配置信息在多个目标Kubernetes集群重新部署资源之前，还包括：对配置信息重新配置时，触发产生消息事件，加入消息事件至限速队列，在限速队列中上一个消息事件完成协调后，处理消息事件，处理消息事件指示对目标Kubernetes集群上已经部署的资源进行调整。避免上次协调没有完成就开始下次协调，而带来数据不一致的问题。对目标Kubernetes集群上已经部署的资源进行调整可以参见上述实施例的描述，本申请实施例在此不再赘述。

因此，通过限速队列对协调做一定的限速，避免频繁协调资源而带来数据负载过重和数据不一致的问题。

在一种可能的实现方式中，创建分布式资源锁，以目标对象对同一目标Kubernetes集群上部署的资源和配置信息进行一致性协调。也就是说，针对同一个目标Kubernetes集群，只能由一个协调器(目标对象)运行并协调。协调器在运行的时候，会通过目标Kubernetes集群的ConfigMap组件，创建 ConfigMap，ConfigMap是为了让镜像和配置文件解耦，以便实现镜像的可移植性和可复用性，此ConfigMap用来创建分布式资源锁，保证同一个目标 Kubernetes集群，只能由一个协调器(目标对象)运行。激活的协调器会不断修改ConfigMap，与ConfigMap保持心跳，其它的协调器则不能对ConfigMap 进行修改，处于非激活状态，一旦激活的协调器故障不能与ConfigMap进行心跳，则其他协调器将抢占目标Kubernetes集群的ConfigMap资源，能成功与 ConfigMap建立心跳的将成为新的激活的协调器运行在目标Kubernetes集群。

一致性协调指的是上述“在配置信息重新配置的情况下，根据重新配置后的配置信息修改目标Kubernetes集群部署的资源，或者，删除目标Kubernetes 集群部署的资源，并根据重新配置后的配置信息在目标Kubernetes集群重新部署资源。”的技术内容，其可以互相参照，本申请实施例在此不再赘述。

通过本申请实施例公开的技术方案，通过配置信息确定出需要进行业务部署的目标Kubernetes集群之后，能同时进行业务部署，避免了分别在多个 Kubernetes集群上逐一进行业务部署，而产生大量的重复工作的问题，提高业务部署的效率。

此外，在配置信息重新配置后，对目标Kubernetes集群上部署的资源进行调整，也就是说，对目标Kubernetes集群上部署的资源与重新配置的配置信息进行一致性协调，保证集群之间业务的一致性。

如图5所示，本申请实施例提供一种多Kubernetes集群的业务部署方法，该方法的执行主体可以为服务器，其中，该服务器可以是独立的服务器，也可以是由多个服务器组成的服务器集群。该多Kubernetes集群的业务部署方法具体可以包括以下步骤S501-S504：

在S501中，获取业务部署的配置信息。

在S502中，根据配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes集群。

在S503中，在所述目标Kubernetes集群为多个的情况下，在目标Kubernetes 集群同时进行业务部署，业务部署包括在目标Kubernetes集群部署至少一种资源，业务部署的配置信息包括部署所述至少一种资源的配置信息。

值得注意的是，S501至S503具有与S101至S103相同或类似的实现方式，其可以互相参照，本申请实施例在此不再赘述。

在S504中，如果在多个目标Kubernetes集群中进行业务部署后部署的第一目标资源被删除，则同时删除在多个目标Kubernetes集群中进行业务部署后部署的与第一目标资源相关联的第二目标资源。

具体来讲，可以对多个目标Kubernetes集群上部署的部分资源或全部资源进行删除，其中，第一目标资源可以包括部分资源或全部资源。在删除目标 Kubernetes集群上部署的第一目标资源的同时，对所协调的相关资源(第二目标资源)也同时进行删除。

在一种可能的实现方式中，删除配置信息，对在目标Kubernetes集群上部署的与配置信息相关的第三目标资源进行删除。也就是说，在配置信息删除后，对目标Kubernetes集群上，根据配置信息进行业务部署的相关资源也全部进行删除。

在一种可能的实现方式中，如果配置信息中定义了级联删除的配置信息，在删除目标Kubernetes集群上部署的第一目标资源的同时，会把所协调的与第一目标资源相关的第二目标资源全部删除，或者，在删除配置信息的同时，会把第三目标资源全部进行删除。，如果配置信息中没有定义级联删除的配置信息，在删除多个目标Kubernetes集群上部署的第一目标资源时，会把所协调的与第一目标资源相关的第二目标资源进行保留，或者，在删除配置信息的同时，第三目标资源进行保留。

通过本申请实施例提供的一种技术方案，通过配置信息确定出需要进行业务部署的目标Kubernetes集群之后，能同时进行业务部署，避免了分别在多个 Kubernetes集群上逐一进行业务部署，而产生大量的重复工作的问题，提高业务部署的效率。

此外，在删除第一目标信息的同时，会将与第一目标信息相关联的第二目标信息也进行删除，不需要逐一删除与业务部署相关的目标资源，提高了处理效率，同时避免过度占用存储资源。

下面结合图6对本申请实施例提供的一种多Kubernetes集群的业务部署方法进行进一步的说明：

如图6所示，用户端601通过Web前端602访问Kubernetes集群管理模块603，Kubernetes集群管理模块603通过API服务器606和API服务器614 (APIServer)提供多种操作目标Kubernetes集群(如KubernetesClusterA、 KubernetesClusterB、KubernetesClusterC、KubernetesClusterD)的接口给Web 前端602进行调用。APIServer由Kubernetes集群提供，用于Kubernetes集群内部和外部服务操作Kubernetes集群的唯一入口。

集群管理模块604为Web前端602提供操作，查看集群管理的接口，通过此模块，用户端601可以管理Kubernetes集群，例如：增加一个Kubernetes集群，提供Kubernetes集群访问配置文件管理，生成唯一的集群ID等。

多集群部署自定义资源621需要部署到任意一个集群上(如KubernetesClusterA)，部署自定义的配置信息以及运行协调器612需要对 Kubernetes集群进行RBAC认证。

多集群部署自定义资源621需要创建ServiceAcount、ClusterRole和ClusterRoleBinding。ServiceAcount、ClusterRole和ClusterRoleBinding统一采用619表示。

多集群部署自定义资源621部署完成后，需要使用代码生成器620 (code-generator)生成多集群部署的客户端的操作方法，并增加到API服务器 606中，供Kubernetes集群管理模块603调用。

第一事件收集器608，负责监控部署了多集群部署多集群部署自定义资源 621的资源。

第二事件收集器610，负责监听多个Kubernetes集群615 (KubernetesClusterA、KubernetesClusterB、KubernetesClusterC、KubernetesClusterD)中的Deployment、Service、Ingres(616)和Namespace (617)资源的变化。

协调器612用于协调多集群部署自定义资源621，根据多集群部署自定义资源621的定义，协调每个Kubernetes集群创建、修改、删除Deployment、Service、 Ingress等资源，达到最终的一致定。根据Deployment、Service、Ingress的状态信息，返回并汇总成多集群部署的状态信息。

消息队列中间件618用于整个消息队列服务，主要是为了在Kubernetes集群信息发生变化后，集群管理模块604会产生消息，此消息需要通过此组件进行消息存储和传递，协调器612会消费消息队列里面的事件，并对不同的事件做出不同的操作。如：新增加Kubernetes集群进来后，协调器612为了重写加载配置信息，需要重启，集群管理模块604会产生一个重启服务的事件，协调器612消费此消息后，会重启自身的服务。

数据库605存储Kubernetes集群相关信息，包括Kubernetes集群访问配置文件，集群名称、集群ID等信息。以及存储多集群部署自定义资源621定义的配置信息。

限速队列609和限速队列611，用于接收第一事件收集器608和第二事件收集器610产生的消息事件，再由协调器612进行统一消费。此队列做了一定的限速，用于保护协调器612，避免频繁协调资源。

ConfigMap623(Kubernetes集群组件623)，用于实现一个分布式资源锁。

终结器613，在多集群部署自定义资源621定义的配置信息删除之前，对多所协调的相关资源全部进行删除。

值得注意的是，图6实施例中与上述图1至图5实施例中相同或类似的实现方式可以互相参照，本申请实施例在此不再赘述。

对应上述实施例提供的多Kubernetes集群的业务部署方法，基于相同的技术构思，本申请实施例还提供了多Kubernetes集群的业务部署装置，图7为本申请实施例提供的多Kubernetes集群的业务部署装置的模块组成示意图，该多 Kubernetes集群的业务部署装置用于执行图1和图5描述的多Kubernetes集群的业务部署方法，如图7所示，该多Kubernetes集群的业务部署装置包括：获取模块701，确定模块702和部署模块703。

获取模块701，用于获取业务部署的配置信息。确定模块702，用于根据配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes集群。部署模块703，用于在所述目标Kubernetes集群为多个的情况下，在多个目标 Kubernetes集群中同时进行业务部署，业务部署包括部署至少一种资源，业务部署的配置信息包括部署至少一种资源的配置信息。

通过本申请实施例提供的技术方案，通过配置信息确定出需要进行业务部署的目标Kubernetes集群之后，能同时进行业务部署，避免了分别在多个 Kubernetes集群上逐一进行业务部署，而产生大量的重复工作的问题，提高业务部署的效率。

在一种可能的实现方式中，还包括：

存储模块(图中未示出)，用于将在所述多个目标Kubernetes集群中进行业务部署后生成的资源部署信息存储至数据库。部署模块二(图中未示出)，用于在多个目标Kubernetes集群中的资源部署信息失效的情况下，从数据库中读取资源部署信息并在多个目标Kubernetes集群重新进行业务部署。

在一种可能的实现方式中，还包括：

监控模块一(图中未示出)，用于监控各目标Kubernetes集群上部署的资源。修改模块一(图中未示出)，用于在所述多个目标Kubernetes集群中部署的资源与所述配置信息中定义的资源不一致的情况下，修改所述多个目标 Kubernetes集群中部署的资源。删除模块一(图中未示出)，用于在所述多个目标Kubernetes集群中部署的资源与所述配置信息中定义的资源不一致的情况下，删除所述多个目标Kubernetes集群中部署的资源，并根据所述配置信息中定义的资源在所述多个目标Kubernetes集群中重新进行业务部署。

在一种可能的实现方式中，还包括：

监控模块二(图中未示出)，用于监控配置信息。修改模块二(图中未示出)，用于在所述配置信息重新配置的情况下，根据重新配置后的配置信息修改所述多个目标Kubernetes集群中部署的资源。删除模块二(图中未示出)，用于在所述配置信息重新配置的情况下，删除所述多个目标Kubernetes集群中部署的资源，并根据所述重新配置后的配置信息在所述多个目标Kubernetes集群中重新进行业务部署。

在一种可能的实现方式中，还包括：

删除模块三(图中未示出)，用于如果在所述多个目标Kubernetes集群中进行业务部署后部署的第一目标资源被删除，则同时删除在所述多个目标 Kubernetes集群中进行业务部署后部署的与所述第一目标资源相关联的第二目标资源。

在一种可能的实现方式中，部署模块703还用于，在多个目标Kubernetes 集群中同时部署多个业务，不同的业务部署在不同的命名空间。

在一种可能的实现方式中，部署模块703还用于，在各目标Kubernetes集群上同时部署多种资源，不同的目标Kubernetes集群上部署的同一业务的至少部分资源的配置信息不同。

本申请实施例提供的多Kubernetes集群的业务部署装置能够实现上述多Kubernetes集群的业务部署方法对应的实施例中的各个过程，为避免重复，这里不再赘述。

需要说明的是，本申请实施例提供的多Kubernetes集群的业务部署装置与本申请实施例提供的多Kubernetes集群的业务部署方法基于同一发明构思，因此该实施例的具体实施可以参见前述多Kubernetes集群的业务部署方法的实施，重复之处不再赘述。

对应上述实施例提供的多Kubernetes集群的业务部署方法，基于相同的技术构思，本申请实施例还提供了一种电子设备，该电子设备用于执行上述的多 Kubernetes集群的业务部署方法，图8为实现本发明各个实施例的一种电子设备的结构示意图，如图8所示。电子设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上的处理器801和存储器802，存储器802中可以存储有一个或一个以上存储应用程序或数据。其中，存储器802可以是短暂存储或持久存储。存储在存储器802的应用程序可以包括一个或一个以上模块 (图示未示出)，每个模块可以包括对电子设备中的一系列计算机可执行指令。更进一步地，处理器801可以设置为与存储器802通信，在电子设备上执行存储器802中的一系列计算机可执行指令。电子设备还可以包括一个或一个以上电源803，一个或一个以上有线或无线网络接口804，一个或一个以上输入输出接口805，一个或一个以上键盘806。

在本实施例中，电子设备包括有处理器、通信接口、存储器和通信总线；其中，处理器、通信接口以及存储器通过总线完成相互间的通信；存储器，用于存放计算机程序；处理器，用于执行存储器上所存放的程序，实现以下方法步骤：

获取业务部署的配置信息。根据配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes集群。在所述目标Kubernetes集群为多个的情况下，在多个目标Kubernetes集群同时进行业务部署，业务部署包括部署至少一种资源，所述业务部署的配置信息包括部署所述至少一种资源的配置信息。

通过本申请提供的一种技术方案，通过配置信息确定出需要进行业务部署的目标Kubernetes集群之后，能同时进行业务部署，避免了分别在多个 Kubernetes集群上逐一进行业务部署，而产生大量的重复工作的问题，提高业务部署的效率。

具体实施例中，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时，实现如以下步骤：

获取业务部署的配置信息。根据配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes集群。在所述目标Kubernetes集群为多个的情况下，在多个目标Kubernetes集群中同时进行业务部署，业务部署包括部署至少一种资源，所述业务部署的配置信息包括部署所述至少一种资源的配置信息。

通过本申请提供的一种技术方案，通过配置信息确定出需要进行业务部署的目标Kubernetes集群之后，能同时进行业务部署，避免了分别在多个 Kubernetes集群上逐一进行业务部署，而产生大量的重复工作的问题，提高业务部署的效率。

具体实施例中，本申请实施例提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现如以下步骤：

获取业务部署的配置信息。根据配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes集群。在目标Kubernetes集群为多个的情况下，在多个目标Kubernetes集群中同时进行业务部署，业务部署包括部署至少一种资源，所述业务部署的配置信息包括部署所述至少一种资源的配置信息。

本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、 CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/ 或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，电子设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器 (RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存 (PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器 (CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、装置或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种多Kubernetes集群的业务部署方法，其特征在于，所述方法包括：

获取业务部署的配置信息；

根据所述配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes集群；

在所述目标Kubernetes集群为多个的情况下，在所述多个目标Kubernetes集群中同时进行业务部署，所述业务部署包括部署至少一种资源，所述业务部署的配置信息包括部署所述至少一种资源的配置信息。

2.根据权利要求1所述的方法，其特征在于，在所述多个目标Kubernetes集群中同时进行业务部署之后，所述方法还包括：

将在所述多个目标Kubernetes集群中进行业务部署后生成的资源部署信息存储至数据库；

在所述多个目标Kubernetes集群中的资源部署信息失效的情况下，从所述数据库中读取所述资源部署信息并在所述多个目标Kubernetes集群中重新进行业务部署。

3.根据权利要求1所述的方法，其特征在于，在所述多个目标Kubernetes集群中同时进行业务部署之后，所述方法还包括：

监控各所述目标Kubernetes集群上部署的资源；

在所述多个目标Kubernetes集群中部署的资源与所述配置信息中定义的资源不一致的情况下，修改所述多个目标Kubernetes集群中部署的资源；或者，

在所述多个目标Kubernetes集群中部署的资源与所述配置信息中定义的资源不一致的情况下，删除所述多个目标Kubernetes集群中部署的资源，并根据所述配置信息中定义的资源在所述多个目标Kubernetes集群中重新进行业务部署。

4.根据权利要求1所述的方法，其特征在于，在所述多个目标Kubernetes集群中同时进行业务部署之后，所述方法还包括：

监控所述配置信息；

在所述配置信息重新配置的情况下，根据重新配置后的配置信息修改所述多个目标Kubernetes集群中部署的资源；或者，

在所述配置信息重新配置的情况下，删除所述多个目标Kubernetes集群中部署的资源，并根据所述重新配置后的配置信息在所述多个目标Kubernetes集群中重新进行业务部署。

5.根据权利要求1所述的方法，其特征在于，在所述多个目标Kubernetes集群中同时进行业务部署之后，所述方法还包括：

如果在所述多个目标Kubernetes集群中进行业务部署后部署的第一目标资源被删除，则同时删除在所述多个目标Kubernetes集群中进行业务部署后部署的与所述第一目标资源相关联的第二目标资源。

6.根据权利要求1所述的方法，其特征在于，所述业务部署的配置信息包括业务部署的命名空间、与服务相关的配置信息、目标Kubernetes集群的标识信息、与路由相关的配置信息、与容器相关的配置信息中的至少一种。

7.根据权利要求6所述的方法，其特征在于，所述在所述多个目标Kubernetes集群中同时进行业务部署包括：

在所述多个目标Kubernetes集群中同时部署多个业务，不同的业务部署在不同的命名空间。

8.根据权利要求1所述的方法，其特征在于，所述在所述多个目标Kubernetes集群中同时进行业务部署包括：

在各所述目标Kubernetes集群上同时部署多种资源；

不同的目标Kubernetes集群上部署的同一业务的至少部分资源的配置信息不同。

9.一种多Kubernetes集群的业务部署装置，其特征在于，所述装置包括：

获取模块，用于获取业务部署的配置信息；

确定模块，用于根据所述配置信息，从多个Kubernetes集群中确定进行业务部署的目标Kubernetes集群；

部署模块，用于在所述目标Kubernetes集群为多个的情况下，在所述多个目标Kubernetes集群中同时进行业务部署，所述业务部署包括部署至少一种资源，所述业务部署的配置信息包括部署所述至少一种资源的配置信息。

10.一种电子设备，包括处理器、通信接口、存储器和通信总线；其中，所述处理器、所述通信接口以及所述存储器通过总线完成相互间的通信；所述存储器，用于存放计算机程序；所述处理器，用于执行所述存储器上所存放的程序，实现如权利要求1-8任意一项所述的多Kubernetes集群的业务部署方法步骤。

Images