CN114840223A

CN114840223A - 资源处理方法及装置

Info

Publication number: CN114840223A
Application number: CN202210551528.2A
Authority: CN
Inventors: 殷达; 孙健波; 宋阳; 李健; 董天欣
Original assignee: Alibaba China Co Ltd
Current assignee: Alibaba China Co Ltd
Priority date: 2022-05-18
Filing date: 2022-05-18
Publication date: 2022-08-02

Abstract

本申请实施例提供一种资源处理方法及装置，该方法包括：获取第一应用的配置信息。根据配置信息，在多个子集群中确定部署第一应用的至少一个目标子集群，以及确定各目标子集群各自对应的目标资源。将各目标资源，分别配置给各自对应的目标子集群。通过根据第一应用的配置信息，确定部署第一应用的目标子集群，以及各个目标子集群各自对应的目标资源，之后第一集群可以针对各个目标子集群，分别进行各自的目标资源的配置，进而可以有效实现对在多集群上进行应用的部署。

Description

资源处理方法及装置

技术领域

本申请实施例涉及计算机技术，尤其涉及一种资源处理方法及装置。

背景技术

在云原生时代，越来越多的用户选择将应用部署在Kubernetes上，Kubernetes是一个开源的容器编排系统，用于自动部署、扩展和管理容器化应用程序。

随着计算机技术的不断发展，考虑到应用的高可用性、系统容灾、地域等等原因，目前的用户在进行应用部署的时候，通常会将应用部署在多集群上。然而，Kubernetes的原生系统是针对单集群的，因此Kubernetes的原生资源体系并未提供多集群场景下的解决方案。

因此，现有技术中Kubernetes针对单集群的原生系统，会导致多集群的应用无法实现有效部署。

发明内容

本申请实施例提供一种资源处理方法及装置，以克服多集群的应用无法实现有效部署的问题。

第一方面，本申请实施例提供一种资源处理方法，应用于第一集群，所述第一集群用于控制多个子集群，所述方法包括：

获取第一应用的配置信息；

根据所述配置信息，在所述多个子集群中确定部署所述第一应用的至少一个目标子集群，以及确定各所述目标子集群各自对应的目标资源；

将各所述目标资源，分别配置给各自对应的目标子集群。

第二方面，本申请实施例提供一种资源处理装置，应用于第一集群，所述第一集群用于控制多个子集群，所述装置包括：

获取模块，用于获取第一应用的配置信息；

确定模块，用于根据所述配置信息，在所述多个子集群中确定部署所述第一应用的至少一个目标子集群，以及确定各所述目标子集群各自对应的目标资源；

处理模块，用于将各所述目标资源，分别配置给各自对应的目标子集群。

第三方面，本申请实施例提供一种资源处理设备，包括：

存储器，用于存储程序；

处理器，用于执行所述存储器存储的所述程序，当所述程序被执行时，所述处理器用于执行如上第一方面以及第一方面各种可能的设计中任一所述的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如上第一方面以及第一方面各种可能的设计中任一所述的方法。

第五方面，本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上第一方面以及第一方面各种可能的设计中任一所述的方法。

附图说明

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

图1为本申请实施例提供的Kubernetes的集群架构的示意图；

图2为本申请实施例提供的资源处理系统的实现示意图；

图3为本申请实施例提供的资源管理方法的流程图；

图4为本申请实施例提供的资源处理方法的流程图二；

图5为本申请实施例提供的确定目标子集群的实现示意图；

图6为本申请实施例提供的确定目标子集群的目标资源的实现示意图一；

图7为本申请实施例提供的确定目标子集群的目标资源的实现示意图二；

图8为本申请实施例提供的确定目标子集群的目标资源的实现示意图三；

图9为本申请实施例提供的资源处理方法的架构示意图；

图10为本申请实施例提供的资源处理装置的结构示意图；

图11为本申请实施例提供的资源处理设备设备的硬件结构示意图。

具体实施方式

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

为了更好的理解本申请的技术方案，下面对本申请所涉及的相关技术进行进一步的详细介绍。

云原生是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。其中，DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称。云原生(CloudNative)是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性以及分布式优势。

以及，Kubernetes，通常称为K8S，是开源容器集群管理系统，用于自动部署、扩展和管理容器化的应用程序。

在云原生时代，越来越多的用户选择将自己的应用部署在Kubernetes上。然而，Kubernetes原生提供的只是底层基础设施的能力，这与用户希望将完整的应用进行打包部署依然存在一定的差距。本申请中所提及的应用可以理解为由多种Kubernetes资源所构成的集合。

以及，随着Helm,Kustomize等工具的盛行，为开发者在Kubernetes上组装复杂的应用结构提供了便利的方法，但这些工具只能提供帮助用户打包、渲染应用所需的资源，随着用户使用场景的更加多样和复杂化，它们的局限性也越发明显。其中的一个便是多集群应用管理的场景。

目前，Kubernetes的原生系统是针对单集群的，然而由于对于节点之间通信时间、频率存在较高的要求，这样的单集群存在机器节点数量的上限，同时要求这些节点都排部在连通性强的网络环境下。

因为上述限制的存在，这就使得高可用系统以及容灾系统，天然需要考虑使用不同网络环境下的多个集群。除此之外，随着云服务厂商的繁荣，也使得用户对集群的选择更加多样化，很多用户开始选择在不同云服务厂商提供的集群上，搭建自己的服务，这也对中心化管控多集群中的应用有了更高的要求。

除了在多集群环境下部署资源外，另一个亟待解决的问题是如何在多集群环境下维护应用的生命周期。对于一个完整的应用服务而言，不仅需要对应用的各种资源进行分发，而且还需要追踪它们的状态、在需要的时候进行升级变配以及在删除的时候回收所有资源。

因此基于上述介绍可以确定的是，现有技术中的Kubernetes原生的资源管理体系并不考虑多集群场景下的解决方案，从而会导致多集群的应用无法实现有效部署。

基于现有技术中的问题，本申请提出了如下技术构思：中心化管控的多集群应用，需要构建相应的体系来去维护应用的生命周期，因此本申请提供了一种资源管理方法，提供一种支持多集群的应用部署的Kubernetes体系，进而克服多集群应用无法实现有效部署的弊端。

其中，Kubernetes在具体实现的时候，通常是以集群的形式实现的。在上述介绍内容的基础上，下面结合图1对Kubernetes的集群架构进行介绍，图1为本申请实施例提供的Kubernetes的集群架构的示意图。

Kubernetes集群架构以及相关的核心组件如图1所示：一个Kubernetes集群一般包含一个主控(Master)节点和多个工作(Node)节点，其中，一个节点可以看成是一台物理机或虚拟机。

其中，Master节点是K8S集群的控制节点，每个K8S集群里都需要有一个Master节点来负责整个集群的管理和控制，基本上K8S集群所有的控制命令都是发给它，它来负责具体的执行过程。Master节点通常会占据一个独立的服务器。

以及，除了Master节点，K8S集群中的其它机器被称为Node节点，Node节点是K8S集群中的工作负载节点，每个Node节点都会被Master节点分配一些工作负载，当某个Node节点宕机时，其上的工作负载会被Master节点自动转移到其它节点上去。

下面再对Kubernetes集群架构中的一些核心概念进行介绍。

1、Pod

Pod是K8S中最重要也是最基本的概念，可以结合图1进行理解，Pod是最小的部署单元，是一组容器的集合。每个Pod都由一个特殊的根容器Pause容器，以及一个或多个紧密相关的用户业务容器组成。

Pause容器作为Pod的根容器，以它的状态代表整个容器组的状态。K8S为每个Pod都分配了唯一的互联网协议(Internet Protocol，IP)地址，称之为Pod IP。Pod里的多个业务容器共享Pause容器的IP。

2、Label

标签，附加到某个资源上，用于关联对象、查询和筛选。一个abel是一个key＝value的键值对，key与value由用户自己指定。Label可以附加到各种资源上，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源上。

可以通过给指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能，以便于灵活、方便地进行资源分配、调度、配置、部署等工作。

K8S可以通过Label Selector(标签选择器)来查询和筛选拥有某些Label的资源对象。

3、ReplicaSet(RC)

ReplicaSet(副本集)，用来确保预期的Pod副本数量，如果有过多的Pod副本在运行，系统就会停掉一些Pod，否则系统就会再自动创建一些Pod。ReplicaSet主要被Deployment(部署)这个更高层的资源对象使用，从而形成一整套Pod创建、删除、更新的编排机制。

4、Deployment

Deployment用于部署无状态应用，Deployment为Pod和ReplicaSet提供声明式更新，只需要在Deployment描述想要的目标状态，Deployment就会将Pod和ReplicaSet的实际状态改变到目标状态。

5、Service

Service(服务)定义了一个服务的访问入口，通过Label Selector与Pod副本集群之间“无缝对接”，定义了一组Pod的访问策略，防止Pod失联。创建Service时，K8S会自动为它分配一个全局唯一的虚拟IP地址，即Cluster IP。

6、Namespace

命名空间，Namespace多用于实现多租户的资源隔离。Namespace通过将集群内部的资源对象“分配”到不同的Namespace中，形成逻辑上分组的不同项目、小组或用户组。K8S集群在启动后，会创建一个名为default的Namespace，如果不特别指明Namespace，创建的Pod、RC、Service都将被创建到default下。

在上述介绍内容的基础上，下面结合具体的实施例对本申请提供的资源处理方法进行介绍。首先结合图2对本申请中的资源处理方法对应的系统架构进行介绍，图2为本申请实施例提供的资源处理系统的实现示意图。

如图2所示，本申请中的资源处理系统中包括第一集群，以及多个子集群。其中，第一集群可以理解为管控集群，用于对多个子集群进行管理，子集群用于进行应用的部署。

其中，无论是第一集群还是子集群，都可以理解为是上述介绍的Kubernetes集群，本申请中的多集群也就是多个Kubernetes集群所构成的集合。

在一种可能的实现方式中，在第一集群中可以部署有控制器，其中控制器是用来调度、处理Kubernetes集群上资源的组件。

以及在实际实现过程中，可以存在多个Kubernetes集群，可以在多个Kubernetes集群中选择一个部署控制器，其中用于部署控制器的集群即是第一集群，在可选的实现方式中，第一集群可以是Kubernetes集群，也可以是单台服务器，本实施例对此不做限制。只要在第一集群上部署有上述介绍的控制器，并且第一集群可以进行数据处理即可。相应的，子集群就是被第一集群管控的Kubernetes集群。

本申请中各实实施例的执行主体即为上述介绍的第一集群，在上述介绍内容的基础上，下面首先结合图3对本申请提供的资源管理方法进行说明，图3为本申请实施例提供的资源管理方法的流程图。

如图3所示，该方法包括：

S301、获取第一应用的配置信息。

在本实施例中，第一应用即为需要进行多集群部署的应用，可以获取第一应用的配置信息。其中，第一应用的配置信息例如可以指示第一应用的待部署集群，以及还可以指示第一应用对应的待部署资源。以及在实际实现过程中，第一应用的配置信息还可以根据实际需求进行选择和设置，凡是可以指示第一应用的部署相关的信息，均可以作为本实施例中的配置信息。

在一种可能的实现方式中，第一应用的配置信息比如说可以是用户编写，并上传至第一集群上的，之后就可以在第一集群上获取到第一应用的配置信息，其中配置信息比如说可以是以代码的形式上传的，或者配置信息还可以是以文档的形式上传的，本实施例对此不做限制，只要在配置信息中包括第一应用的具体部署指示信息即可。

S302、根据配置信息，在多个子集群中确定部署第一应用的至少一个目标子集群，以及确定各目标子集群各自对应的目标资源。

本实施例中的第一集群用于控制多个子集群，或者也可以理解为第一集群用于管理多个子集群。以及，用户在部署第一应用的时候，会选择某几个子集群进行部署。

则在获取配置信息之后，可以对配置信息进行解析，从而在第一集群控制的多个子集群中，确定用于部署第一用于的至少一个目标子集群。

以及通过对配置信息进行解析，还可以确定各个目标子集群所各自对应的目标资源。

此处的目标资源例如可以包括原生的Kubernetes资源对象，如内置的Deployment、Service、Ingress，其中Deployment资源和Service资源在上述实施例中已经进行了介绍，此处不再赘述。以及Ingress(入口)是K8S资源对象，用于对外暴露服务，该资源对象定义了不同主机名(域名)及统一资源定位器(Uniform Resource Locator，URL)和对应后端Service(k8s Service)的绑定。

或者，目标资源还可以包括通过外部插件提供的资源对象，如来自于开源项目OpenKruise的CloneSet。

或者，目标资源还可以包括现成的资源组合包，如Helm Chart。

或者，目标资源还可以包括来自各个云服务厂商的各类云资源类型对象。

或者，目标资源还可以包括外部系统已有的资源声明，如来自互联网上的资源文件或是数据库中存储的资源对象

本实施例对具体的目标资源不做限制，其可以根据用户的实际需求进行选择和设置，凡是部署第一应用所需的资源均可以作为本实施例中的目标资源，以及用户可以在配置信息中声明该目标资源。

S303、将各目标资源，分别配置给各自对应的目标子集群。

在确定目标子集群，以及各个目标子集群各自对应的目标资源时候，就可以将各目标资源分别配置给各自对应的目标子集群了，从而可以完成第一应用的部署。

本申请实施例提供的资源处理方法，包括：获取第一应用的配置信息。根据配置信息，在多个子集群中确定部署第一应用的至少一个目标子集群，以及确定各目标子集群各自对应的目标资源。将各目标资源，分别配置给各自对应的目标子集群。通过根据第一应用的配置信息，确定部署第一应用的目标子集群，以及各个目标子集群各自对应的目标资源，之后第一集群可以针对各个目标子集群，分别进行各自的目标资源的配置，进而可以有效实现对在多集群上进行应用的部署。

在上述介绍内容的基础上，下面结合图4至图8对本申请提供的资源处理方法进行进一步的详细介绍。图4为本申请实施例提供的资源处理方法的流程图二，图5为本申请实施例提供的确定目标子集群的实现示意图，图6为本申请实施例提供的确定目标子集群的目标资源的实现示意图一，图7为本申请实施例提供的确定目标子集群的目标资源的实现示意图二，图8为本申请实施例提供的确定目标子集群的目标资源的实现示意图三。

如图4所示，该方法包括：

S401、获取第一应用的配置信息。

其中，S401的实现方式与上述介绍的S301的实现方式类似。

进一步的，本实施例中的配置信息例如可以包括集群筛选条件、资源配置信息。其中，集群筛选条件用于指示在多个子集群中筛选目标子集群的条件，以及资源配置信息例如可以包括：第一资源类型、第一资源数量。也就是说资源配置信息可以指示需要什么类型的资源，各种类型的资源都需要多少。

还需要说明，在实际实现过程中，配置信息并不限于本实施例中介绍的内容，本实施例中只是对配置信息的可能的实现方式进行介绍，其具体的实现方式可以根据实际需求进行选和扩展。

S402、对第一集群访问子集群的权限进行校验。

在获取到上述介绍的配置信息之后，第一集群例如可以根据配置信息中的集群筛选条件确定目标子集群。但是在第一集群确定目标子集群之前，首先要对第一集群访问子集群的权限进行校验，也就是针对第一集群的鉴权。

例如可以校验第一集群是否有访问各个子集群的集群接口的权限，或者还可以校验第一集群是否有访问各个子集群的集群资源接口的权限，等等。其中权限校验的具体实现可以根据实际需求进行选择和设置，本实施例对此不做限定。

S403、若权限校验通过，则通过第一集群中的查询引擎，调用多个子集群各自的集群接口，以得到各子集群各自的集群信息，集群信息包括如下中的至少一种：集群名称、集群标签、集群属性信息。

在第一集群的权限校验通过之后，第一集群就可以根据集群筛选条件确定目标子集群了。在针对第一集群进行权限校验，在权限校验通过之后，第一集群再对子集群的集群信息进行查询，从而可以有效的保证数据处理的安全性。

在一种可能的实现方式中，第一集群中可以包括查询引擎，以及各个子集群对应有各自的集群接口，则可以通过第一集群中的查询引擎，调用多个子集群各自的集群接口，从而得到各个子集群各自的集群信息。其中，集群信息比如说可以包括如下中的至少一种：集群名称、集群标签、集群属性信息。其中，集群属性信息比如说可以包括集群内的节点数量、包括的资源类型、各类型资源的数量、处理数据的能力等等，凡是可以反映集群特征的信息，均可以作为本实施例中的集群属性信息。

S404、根据集群信息和集群筛选条件进行匹配，将集群信息满足集群筛选条件的子集群，确定为目标子集群。

在一种可能的实现方式中，本实施例中的集群筛选条件比如说可以包括集群的名称，则集群筛选条件可以指示将特定名称的子集群确定为目标子集群。

或者，本实施例中的集群筛选条件还可以包括集群的标签，则集群筛选条件可以指示将携带有特定标签的子集群确定为目标子集群。

或者，本实施例中的集群筛选条件还可以包括集群的属性要求，则集群筛选条件可以指示将属性信息满足属性要求的子集群，确定为目标子集群。

因此本实施例中在获取到集群信息之后，可以将集群信息和集群筛选条件进行匹配，之后在第一集群控制的多个子集群中，确定出集群信息满足集群筛选条件的子集群，将这部分子集群确定为目标子集群。

可以理解的是，通过获取子集群的集群信息，并且在第一集群的配置信息中包括集群筛选条件，从而可以通过集群信息和集群筛选条件匹配的方式，准确有效的从多个子集群中，将满足用户需要的子集群确定为目标子集群。

下面例如可以结合图5以一个具体的示例进行说明，如图5所示，假设当前集群筛选条件包括：标签1以及节点数量大于10，则表示需要将携带标签1，以及集群内的节点数量大于10的子集群，确定为目标子集群。

参照图5，假设当前第一集群所管控的子集群有4个，分别是子集群A、子集群B、子集群C以及子集群D。其中，子集群A的集群信息包括标签1以及节点数量为5，子集群B的集群信息包括标签1以及节点数量为10，子集群C的集群信息包括标签1以及节点数量为20，子集群D的集群信息包括标签2以及节点数量为10。

则基于上述介绍的集群筛选条件，和图5中所示的4个子集群的集群信息进行匹配，可以确定集群信息满足集群筛选条件的子集群包括子集群B和子集群C，则可以将子集群B和子集群C确定为目标子集群。

S405、根据第一资源类型和第一资源数量，确定至少一个第一资源。

以及，本实施例中还需要确定目标子集群所对应的目标资源。在一种可能的实现方式中，资源配置信息中可以包括第一资源类型和第一资源数量。

其中，第一资源类型用于指示当前第一应用需要配置什么类型的资源，第一资源数量用于指示各个类型的资源分别需要配置多少个。例如第一资源类型可以包括：Deployment、Service，第一资源数量可以包括：1、2。则该资源配置信息就用于指示，第一应用需要配置1个Deployment和2个Service。

因此，可以根据第一资源类型和第一资源数量，确定至少一个第一资源。例如上述示例中介绍的1个Deployment和2个Service，就可以是确定的第一资源。

S406、针对任一个目标子集群，将至少一个第一资源，确定为目标子集群对应的目标资源。

可以理解的是，本实施例中的第一资源类型和第一资源数量，是针对各个目标子集群的指示是通用的，也就是说，上述确定的第一资源，是针对各个目标子集群都要进行配置的。

因此在确定上述介绍的第一资源之后，可以针对任一个目标子集群，将至少一个第一资源，确定为目标子集群对应的目标资源。

例如可以结合图6进行理解，如图6所示，假设在资源指示信息中包括第一资源类型和第一资源数量，以及根据第一资源类型和第一资源数量，可以确定图6所示的第一资源，在第一资源中具体包括1个Deployment和2个Service。

以及，假设当前的目标子集群包括子集群B和子集群C，那么可以确定子集群B的目标资源就包括1个Deployment和2个Service，以及可以确定子集群C的目标资源同样也包括1个Deployment和2个Service。

上述介绍的资源指示信息中的第一资源类型和第一资源数量，是针对各个目标子集群通用指示的，同时可以理解的是，在实际实现过程中，可能需要针对某些子集群进行资源的特殊配置。

因此在一种可选的实现方式中，在资源配置信息中例如还可以包括差异化配置信息，其中，差异化配置信息中包括针对第一类子集群指示的第二资源类型和/或第二资源数量，其中第一类子集群为多个目标子集群中的一部分，第一类子集群也可以理解为需要单独指示资源配置的子集群。

因此在将至少一个第一资源，确定为目标子集群对应的目标资源之后。若确定资源配置信息中包括差异化配置信息，则可以根据差异化配置信息中的第二资源类型和第二资源数量，确定至少一个第二资源。其中，确定第二资源的实现方式与上述介绍的确定第一资源的实现方式类似，此处不再赘述。

因此在确定第二资源之后，若当前确定第一资源为目标资源的目标子集群为第一类子集群，则可以将当前的目标子集群所对应的目标资源更新为第二资源。

例如可以结合图7进行理解，如图7所示，假设在资源指示信息中包括第一资源类型和第一资源数量，以及根据第一资源类型和第一资源数量，可以确定图7所示的第一资源，在第一资源中具体包括1个Deployment和2个Service。

因为第一资源是针对各个目标子集群通用指示的，因此可以首先将第一资源确定为各个目标子集群的目标资源。

进一步的，结合图7可以确定的是，在资源指示信息中还包括差异化配置信息，其中，差异化配置信息中包括针对子集群C的第二资源类型和第二资源舒朗。假设根据第二资源类型和第二资源数量，可以确定图7所示的第二资源，在第二资源中具体包括3个Deployment和4个Service。

那么就可以将子集群C的目标资源更新为第二资源，也就是说子集群C的目标资源包括3个Deployment和4个Service，而子集群B的目标资源仍然包括1个Deployment和2个Service。

可以理解的是，资源指示信息中的差异化配置信息是可选的，在需要针对某些目标子集群进行单独的目标资源的指示时，资源指示信息中可以存在差异化配置信息，而如果所有的目标子集群的目标资源都是通用的指示的话，则资源指示信息中可以不存在差异化配置信息。

其中，如果不提供差异化配置信息的话，则需要针对每一个目标子集群都进行单独的资源指示，而大部分的目标子集群的目标资源都是相同的，这样就会导致在配置信息中需要有大段的重复内容来指示目标子集群的目标资源，比如说当前存在10个目标子集群，如果这10个目标子集群的目标资源，有9个都是相同的，只有1个是不同的，那么仍然需要将资源配置的代码重复10次，才能够实现对这10个目标子集群的资源指示。

而通过在资源指示信息中包括差异化配置信息，就可以保证针对目标资源相同的目标子集群，只需要配置一次第一资源类型和第一资源数据即可，之后针对需要单独指示目标资源的目标子集群，通过差异化配置信息进行另外的声明即可。比如说针对上述介绍的存在10个目标子集群，这10个目标子集群的目标资源，有9个都是相同的，只有1个是不同的，在这种情况下，只需要撰写一次第一资源的指示代码，再通过差异化配置信息单独撰写这1个不同的目标子集群的目标资源即可。

因此基于上述介绍可以确定的是，通过在资源指示信息中提供差异化配置信息，可以有效的减少资源指示信息的配置工作量。

在上述介绍的资源配置信息的基础上，可以理解的是，无论是上述介绍的第一资源类型、第一资源数量，还是差异化配置信息，都是指示多个目标子集群的各自的资源配置。进一步的，在Kubernetes集群中，针对单个资源还存在副本的概念，其中一个副本可以理解为在运行的一个程序，通过针对单个资源设置多个副本，可以保证单个资源的稳定运行。

可以理解的是，本实施例中针对任意一种资源类型，均对应配置有该资源类型下的单个资源的副本数量。比如说针对Deployment这个资源类型，配置单个的Deployment的副本数量是10，则表示需要针对单个的Deployment资源设置10个副本。其中各个资源类型的单个资源所对应的副本数量，可以根据实际需求进行选择和设置。

可以理解在默认情况下，针对任意一个子集群，其多个目标资源中某个资源类型下的单个资源，都是采用集群间复制的机制，各个子集群配置相同数量的副本数量的。比如说当前确定子集群B的目标资源包括1个Deployment和2个Service，以及确定子集群C的目标资源同样包括1个Deployment和2个Service，以及还假设一个Deployment对应的副本数量是10个。那么针对子集群B中的每个Deployment都配置10个副本，以及针对子集群C中的每个Deployment也都配置10个副本。

然而，在另一种可能的实现方式中，在资源配置信息中还包括资源调度信息，其中资源调度信息用于指示多个目标子集群共同配置各种资源类型下的单个资源的多个副本。

本实施例中在确定目标子集群对应的目标资源之后，因为在目标资源中包括多个单个资源，比如说子集群B的目标资源包括2个Deployment和3个Service，那么该目标资源中就包括5个单个资源。

因此之后可以进一步的，根据资源调度信息，确定目标子集群对应的目标资源中，各个资源类型下的单个资源各自对应的副本数量。

比如说可以结合图8进行理解，如图8所示，假设根据资源指示信息中包括第一资源类型和第一资源数量，可以确定图8所示的第一资源，在第一资源中具体包括2个Deployment和3个Service。以及，假设Deployment这个资源类型下的单个资源的副本数量是10，也就是说针对单个的Deployment需要配置10个副本。

以及，在资源指示信息中还包括资源调度信息，其中资源调度信息可以指示多个目标子集群共同配置各种资源类型下单个资源的多个副本。

首先结合图8可以确定的是，可以确定子集群B的目标资源包括2个Deployment和3个Service，以及子集群C的目标资源包括2个Deployment和3个Service。

同时，因为当前需要子集群B和子集群C共同配置各个资源类型下的单个资源的多个副本。为了便于理解，下面仅对Deployment这个资源类型的单个资源的副本配置进行介绍。其中，Deployment这个资源类型的单个资源的副本为10个，那么只需要子集群B和子集群C下的单个Deployment的副本数量加起来等于10就可以了。

比如说参照图8，针对子集群B中的每个Deployment，其副本的数量都是4，以及针对子集群C中的每个Deployment，其副本的数量都是6，这样子集群B和子集群C中的Deployment这个资源类型下的单个资源，其共同组成了Deployment的副本数量是10。

在实际实现过程中，具体在每一个目标子集群中，各个资源类型下的单个资源的副本数量具体为多少，可以根据实际需求进行选择和设置，只要保证其各个目标子集群的相同资源类型下的单个资源的副本数量，加起来等于该资源类型下的单个资源的要求数量即可。

比如说上述介绍的示例中，还可以是子集群B中的每个Deployment的副本数量是7，以及子集群C中的每个Deployment的副本数量是3。

其中要求副本数量的具体的划分方式，比如说可以是平均划分，或者还可以是根据子集群的节点数量进行等比例划分，或者还可以是随机划分，或者还可以是根据外部的调度器输出的结果进行划分，等等。其中要求副本数量的具体划分方式可以根据实际需求进行选择和设置，本实施例对此不做限定。

以及，针对各个资源类型下的单个资源的要求副本数量，其可以是在资源配置信息中指示的，或者还可以是预先设置的，本实施例对此不做限定。

通过设置上述介绍的资源调度信息，可以保证各个目标子集群共同配置各个资源类型下的资源的副本，进而可以有效的实现资源的动态调整。比如说在后续的实现过程中，在子集群C中的一个副本挂掉的时候，子集群B中就会创建一个副本进行补充，从而保证多个目标子集群创建的资源副本，总是可以保证满足该资源类型下的资源的副本要求数量，以实现对资源副本的动态调整。

同样可以理解的是，资源指示信息中的资源调度信息是可选的，在需要多个目标子集群共同配置资源副本的时候，资源指示信息中可以存在资源调度信息，而如果仍然需要各个目标子集群分别配置资源副本的时候，则资源指示信息中可以不存在资源指示信息中。

在上述介绍内容的基础上，在资源指示信息中包括资源调度信息，可以有效的增加针对目标子集群配置目标资源的灵活性和全面性。其中，资源调度信息和差异化配置信息均是可选的，例如在资源指示信息中可以包括资源调度信息，或者在资源指示信息中还可以包括差异化配置信息，或者在资源指示信息中还可以同时包括资源调度信息和差异化配置信息，通过在资源指示信息中包括不同的内容，可以简单高效，并且灵活的组合出针对目标子集群的各种目标资源。

S407、针对任一个目标子集群，将第一集群的操作权限转换为目标子集群的操作权限。

在针对各个目标子集群确定各自对应的目标资源之后，就需要针对目标子集群进行资源的配置了。

在一种可能的实现方式中，在针对目标子集群进行资源配置之前，同样需要进行权限的处理，本实施例中针对各个目标子集群均会进行相同的处理，因此下面以任一个目标子集群为例进行介绍。

因为当前是要向目标子集群进行资源的配置，因此可以将第一集群的操作权限转换为目标子集群的操作权限，之后就可以使用转换后的子集群的权限在子集群中分发资源。

S408、通过第一集群中的资源管理引擎，调用第一集群的资源下发接口，以将目标资源配置给对应的目标子集群。

在第一集群中存在资源管理引擎，其中资源管理引擎用于对子集群中的资源进行管理，此处的管理可以包括资源的下发，也可以包括资源的回收，还可以包括资源的更新

同时，在第一集群中还存在资源下发接口，其中资源下发接口用于和子集群对接，从而将目标资源下发给对应的目标子集群。

因此在本实施例中，可以通过第一集群中的资源管理引擎，调用第一集群的资源下发接口，以将目标资源配置给对应的目标子集群。针对各个目标子集群均进行相同的操作，从而可以实现将第一应用的资源分别的下发给各个目标子集群，从而完成第一应用的部署。

上述介绍的是针对目标子集群进行资源下发的过程，更进一步的，本实施例中的第一集群除了会进行资源下发之外，还会进行后续的资源维护，其中的资源维护可以包括资源的更新、资源的维持、资源的删除，等等。

在一种可能的实现方式中，在确定第一应用的配置信息发生更新的时候，则需要对目标子集群和目标资源也进行相应的更新。

因此可以根据更新后的配置信息，重新确定第一应用的目标子集群，以及还需要重新确定更新后的目标子集群对应的目标资源。并且将重新确定的目标资源，再分别配置给各自对应的更新后的目标子集群。这个也就是说，在第一应用的内容发生变化的时候，第一集群需要相应的将变化更新在各个子集群中。

在另一种可能的实现方式中，针对任意一个目标子集群，在确定目标子集群上的目标资源发生异常时，可以向发生异常的目标子集群重新配置资源，以使得目标子集群上的资源保持为对应的目标资源。

比如说，向子集群C配置了3个Deployment和5个Service，因为某些原因子集群C上的目标资源发生了异常，导致其中的2个Deployment挂掉了，那么这个异常就会导致子集群C上只有1个Deployment和5个Service。为了保证第一应用的正常运行，需要保证子集群C上的目标资源的状态，因此在这种情况下，就可以向发生异常的目标子集群重新配置2个Deployment，以保证在子集群C上保持有3个Deployment和5个Service。

这个也就是说，在第一应用的内容发生变化的时候，第一集群需要相应的将变化更新在各个子集群中。当第一应用处于稳定状态时(配置信息没有更新)，如果外界的操作导致其声明的目标资源发生变化，则第一集群的控制器需要负责将这些目标资源状态拉回至原有的目标状态。

在另一种可能的实现方式中，在确定第一应用的配置信息从第一集群上删除时，第一集群需要清理各个目标子集群上配置的目标资源。这个也就是资源对应的删除，例如可以通过回收的方式，清理各个目标子集群上配置的目标资源。

因此基于上述介绍可以理解的是，本实施例中的第一集群可以将第一应用的配置信息所声明的目标资源，分发到声明的各个目标子集群中，并且可以维护这些目标资源的声明周期，以保证第一应用在多集群上的正常运转。

本申请实施例提供的资源处理方法，通过获取子集群的集群信息，并且在第一集群的配置信息中包括集群筛选条件，从而可以通过集群信息和集群筛选条件匹配的方式，准确有效的从多个子集群中，将满足用户需要的子集群确定为目标子集群。以及，在确定目标子集群的目标资源的时候，可以通过配置信息中的第一资源类型和第一资源数量，确定至少一个第一资源，之后将第一资源分别确定为各个目标子集群的目标资源，从而可以通过一次配置，就实现对各个目标子集群的目标资源的通用的声明，有效缩短了前期应用开发过程中的工作量。以及进一步的，在资源指示信息中还可以包括差异化配置信息，其中差异化配置信息可以指示需要单独进行资源声明的第一类子集群的目标资源，通过在资源指示信息中包括差异化配置信息，从而可以有效的实现减少资源指示信息的配置工作量，并且可以有效的提升资源配置的灵活性。以及进一步的，在资源指示信息中还可以包括资源调度信息，其中资源调度信息指示多个目标子集群共同组合配置，以保证各个资源类型下的单个资源的副本数量总是满足要求的副本数量，因此通过资源调度信息可以有效的提升资源配置方式的灵活性和全面性。在确定各个目标子集群各自对应的目标资源之后，就可以将目标资源下发给对应的目标子集群。以及第一集群除了可以针对第一应用进行资源下发之外，还可以对第一应用的资源进行维护，从而可以有效保证第一应用在多集群上的稳定有序的运行，有效的实现了第一应用的多集群部署，同时可以保证其部署的稳定性和运行有效性。

在上述介绍内容的基础上，下面结合图9对本申请提供的资源处理方法背后的支撑体系进行进一步的详细介绍。图9为本申请实施例提供的资源处理方法的架构示意图。

在介绍图9之前，首先对本申请中提出的多集群应用模型进行介绍，其中多集群应用模型可以理解为，在进行多集群应用的开发时，按照什么样的模板来进行开发，此处的多集群应用模型可以理解为上述介绍的配置信息的模板。

其中，基于多集群应用模型开发的第一应用，会通过第一集群的控制器进行部署，因此可以参照图9中的控制器所示，本申请提出的多集群应用模型，主要包括应用组件(Component)与应用策略(Policy)两个部分。

其中，应用组件的部分，声明了要部署的资源集合的模版，涵盖多种类型的资源，其可以理解为上述介绍的需要部署的目标资源的第一资源类型和第一资源数量。

此处对组件的概念进行简单的解释，其中，组件中包括固定搭配的多个资源。上述实施例中介绍了，第一应用的配置信息中可以声明目标资源，在一种可能的实现方式中，在声明目标资源的时候，可以通过声明组件类型的方式来实现。其中一个组件可以理解为一个固定的资源搭配方式，比如说组件X就是1个Deployment和2个Service组合，那么在第一应用的配置信息中例如包括组件X的标识，该组件X的标识就可以指示上述介绍的第一资源类型和第一资源数量。或者，因为组件包括的都是固定的资源搭配方式，若在各种组件中，不存在用户需要的资源搭配方式，用户也可以在配置信息中直接包括第一资源类型和第一资源数量，本实施例对配置信息信息中的具体声明方式不做限制。

以及，应用策略的部分，声明了上述声明的资源部署到多集群中的配置与策略，主要可分为三个单元：

1、部署目标：部署目标单元中声明了如何去选择要部署的位置，也就是说如何选择目标子集群。具体的，可以通过上述介绍的集群筛选条件，集群筛选条件中可以包括名称、集群标签等等。以及参照图9，部署目标的选择是通过应用实现层中的查询引擎来完成的，查询引擎可以基于CUELang语言，其中CUELang是一种基于Json语言扩展的编程语言。通过声明式的代码描述查询集群的过程与方法，不仅具有高扩展性而且扩展成本低。或者，在实际实现过程中，查询引擎也可以基于其他语言，本实施例对此不做限制，只要其可以实现上述介绍的内容和功能即可。

2、差异化配置：差异化配置单元中描述了要部署的资源，在不同目标子集群中的差异，具体介绍可以参照上述介绍的差异化配置信息。其中，差异化配置信息同样通过可以CUELang语言声明。以及除了静态的差异化配置外，还可根据部署目标的动态计算，差异化的部署资源。同样的，在实际实现过程中，差异化配置信息也可以基于其他语言，本实施例对此不做限制，只要其可以实现上述介绍的内容和功能即可。

3、调度策略：调度策略单元中描述了资源在多个部署目标之间的调度方法，对于单体Deployment资源，例如可以通过调度策略控制它在不同的集群中的副本数。相较于针对每个子集群的差异化配置，调度策略会联合考虑多个集群来决定资源的具体配置。调度策略单元同样可以根据使用场景不同，使用CUELang语言扩展调度器。同样的，在实际实现过程中，调度策略也可以基于其他语言，本实施例对此不做限制，只要其可以实现上述介绍的内容和功能即可。

为了实现上述介绍的多集群应用模型，本方案基于Kubernetes集群的控制器模式，提出整个多集群应用管理系统的实现体系，其中控制器模式是Kubernetes上使用面向终态的声明式资源的一种经典模式。下面结合图9对具体的实现结构进行介绍。

在提出的多集群应用管理体系中，多集群应用模型的控制器可按照图9所示的结构图分解为以下几层：

1、应用层：应用层包括接口层与实现层。接口层即为上文所描述的应用模型，用户可以通过配置信息声明并使用符合应用模型描述的应用，基于Kubernetes控制器模式的应用接口层，便会自动解析配置信息，从而确定在配置信息中包括的组件与策略，并调用实现层对应的引擎完成应用的各种计算与操作。

其中，对于部署目标单元，应用实现层可以使用查询引擎调用CUELang运算器与多集群查询接口，完成部署目标的查询与筛选，其中部署目标就是目标子集群。

以及，对于差异化配置单元，应用实现层可以使用配置计算引擎，将声明的差异化配置信息，合并到原始声明的组件配置上，其中原始声明的组件配置就是上述实施例介绍的第一资源的配置方式。

以及，对于调度策略单元，应用实现层可以使用调度引擎，结合查询引擎返回的目标子集群，计算工作负载在多个目标子集群下的副本配置，合并到原始声明的组件配置上，最后得到了在各个目标子集群内的完整的组件配置，也就是说得到各个目标子集群内完整的资源配置方式。

2、资源层：资源层中包括资源渲染引擎和资源管理引擎。

其中，资源渲染引擎会根据应用实现层计算得到的完整组件配置，渲染出真正所需要部署的目标资源，基于上述介绍可以确定的是，应用实现层计算得到的是组件配置，而组件中包括固定的搭配资源。因此当前的资源渲染实际上就是说，根据组件配置，确定组件的具体组成方式，也就是说确定具体包括几个Deployment，每个Deployment的副本数量是多少等等。

以及，资源管理引擎则是针对所要部署分发的目标资源进行管控，包括记录各个应用版本中所分发的目标资源，调用多集群资源接口下发资源，并在新版本应用成功部署后，同样通过调用多集群资源接口回收过期资源。

3、多集群接口层：多集群接口层屏蔽了底层不同多集群技术方案的实现差异，将集群和集群内资源的查询、创建、变更、修改、监听能力封装成接口提供给资源层和应用层使用。

4、多集群实现层：多集群实现层包含了各类集群操作的具体实现细节。例如可以包括上述介绍的资源下发、资源维护等实现细节。

5、权限层：权限层在多集群接口层和多集群实现层分别会对应用资源的权限进行校验。具体的，在多集群接口层，在调用相应的集群接口或集群资源接口之前，会针对第一集群调用相应子集群的权限进行校验检查，也就是第一集群内的鉴权。在多集群实现层，则是会完成从第一集群权限到子集群权限的转换，使用转换后的子集群权限在子集群中分发资源。

因此基于上述介绍可以确定的是，图9中提出的多集群应用管理体系，是针对于上述介绍的多集群应用模型的一种实践，该体系中的各个实现层可以有不同的实现方式。比如应用实现层中的查询引擎在本方案中是基于具有高可扩展性的CUELang语言的，它也可以被其他编程语言的实现所替代，以提高查询效率、对接其他检索算法或系统。

而在多集群实现层，同样可以将本方案中描述的实现层的具体实践替换成现有的社区方案，如双工模式下的ClusterNet。整个体系中的接口层定义了实现层之间的交互方式，实现层内的具体实现则是可插拔可替换的。除此之外，上文所述的多集群应用管理体系是多集群应用模型的基座，对于用户而言可以在此体系之外，通过多种方式访问、接入到该体系中，如使用命令行工具或是通过网页页面操作。

此处再对本申请的技术方案的技术效果进行进一步强调，现有的多集群资源管理项目中，在没有对资源做抽象的情况下，缺少以应用为粒度将资源集合整体部署在子集群，并维护其整体生命周期的能力。而本申请中，通过应用模型的抽象化使得用户得以以应用维度将资源集合进行部署与生命周期的管理。

其次，现有技术中应用抽象的缺失使得差异化配置的范围难以限定。现有的社区方案中，目前的差异化配置的范围一部分只局限在工作负载的副本数或是标签上，限制性强，另一部分则是支持做没有范围限定的任意差异化配置，容易出错。而本申请中，通过组件模型和差异化配置策略的抽象化，使得用户既可以根据自己的使用场景灵活扩展所需配置，又可以将差异化配置的范围进行不同粒度的限制，避免错误的发生。

另外，现有技术中社区方案中的部署行为策略没有抽象模型提供可扩展性，使得多集群部署的能力完全依赖在方案本身的实现上，用户无法依据自己的场景定制相应的行为，这给集群部署目标的动态选择以及个性化的调度算法造成了很大的困难。而本申请中，对于部署目标和调度策略的抽象则提供了极大的定制化自由度，使用户能够通过多样化的方式决策要部署的集群和跨集群工作负载的副本调度。

最后，现有技术中已有的社区方案缺少接口层的抽象，使得用户只能接入完整的多集群方案，难以做到资源部署决策过程与资源部署执行过程的解藕，一方面用户无法灵活选择多集群连接模式，另一方面使得决策过程与执行过程任一模块的升级都需要变更整体架构，为系统的稳定性带来了风险。而本申请中，提出的多集群应用模型的实现体系通过应用接口层和多集群接口层，将资源部署决策过程与资源部署执行过程接藕，为用户接入各种多集群连接模式提供了可扩展性，用模块化的方式降低了系统整体稳定性层面的风险。

因此综上所述，本申请提供的资源处理方法，提出了多集群应用模型以抽象应用资源部署到多集群的过程，使应用资源在多集群环境下可控，同时具有较高的可扩展性。以及，为多集群应用模型设计了一套多集群应用管理系统的实现体系，通过模块化、接口层与实现层的分离使得用户可以通过插拔方式依据场景定制化各个模块的实现方案，提供了接入不同多集群连接技术的可能性，降低了系统整体稳定性的风险。

同时，本申请提出的多集群应用模型与目前开源的应用开放模型(OpenApplication Model，OAM)完全兼容，可以无缝在原OAM模型上进行扩展，因此同时也具备和其他OAM模型模块组合扩展的能力，如工作流模块，从而实现对于多集群应用部署过程的精细控制。

以及在上述介绍内容的基础上，下面再对现有技术中的两种实现方式以及相应的缺陷进行说明。

Karmada是为了解决多集群下的资源分发问题所提出的方案，其使用了额外的APIServer以及ETCD，其中，API Server是Kubernetes上用于接收请求的服务端，ETCD是一个分布式键值对存储系统，在Kubernetes中是用于存储资源的数据库。

用户使用Karmada时需要更改客户端的连接，也就无法无缝使用原有Kubernetes的各种原生能力，必须借助于切换连接端点才能在多集群资源管理与原生Kubernetes资源管理之间切换。另外，Karmada虽然支持资源的跨集群调度分发，但仍局限于处理单体资源的多集群分发问题，没有解决应用级别的资源集合分发问题。

相较之下，本申请提出的方法在应用资源层面上和集群资源层面上都做了抽象建模，同时采用了Kubernetes的Aggregated Server(聚合服务器)模式使得无需切换连接端点就可以是客户端同时使用多集群能力以及原生Kubernetes能力。其中，AggregatedServer是Kubernetes上用于扩展APIServer的一种技术

以及，ClusterNet方案则是采用了Kubernetes的Aggregated Server方案，在不使用额外的APIServer的情况下解决多集群资源分发问题，但对集群的管理只局限于对于集群的添加删除上，难以满足在集群规模上升时对于大量集群的抽象与管理。

同时，ClusterNet对于应用资源集合的处理也仅限于罗列资源，并不能真正地在应用这一维度去维护生命周期，包括对于版本信息的持久化存储、版本变更回退。

图10为本申请实施例提供的资源处理装置的结构示意图。如图10所示，该装置100包括：获取模块1001、确定模块1002以及处理模块1003。

获取模块1001，用于获取第一应用的配置信息；

确定模块1002，用于根据所述配置信息，在所述多个子集群中确定部署所述第一应用的至少一个目标子集群，以及确定各所述目标子集群各自对应的目标资源；

处理模块1003，用于将各所述目标资源，分别配置给各自对应的目标子集群。

在一种可能的设计中，所述配置信息包括：集群筛选条件、资源配置信息；

所述确定模块1002具体用于：

根据所述集群筛选条件，在所述第一集群控制的多个子集群中，确定满足所述集群筛选条件的至少一个目标子集群；

根据所述资源配置信息，确定各所述目标子集群各自对应的目标资源。

在一种可能的设计中，所述确定模块1002具体用于：

对所述第一集群访问子集群的权限进行校验；

若所述权限校验通过，则通过所述第一集群中的查询引擎，调用所述多个子集群各自的集群接口，以得到各所述子集群各自的集群信息，所述集群信息包括如下中的至少一种：集群名称、集群标签、集群属性信息；

根据所述集群信息和所述集群筛选条件进行匹配，将所述集群信息满足所述集群筛选条件的子集群，确定为所述目标子集群。

在一种可能的设计中，所述资源配置信息包括：第一资源类型、第一资源数量；

所述确定模块1002具体用于：

根据所述第一资源类型和所述第一资源数量，确定至少一个第一资源；

针对任一个所述目标子集群，将所述至少一个第一资源，确定为所述目标子集群对应的目标资源。

在一种可能的设计中，所述资源配置信息还包括：差异化配置信息，其中，所述差异化配置信息中包括针对第一类子集群指示的第二资源类型、第二资源数量，所述第一类子集群为所述多个目标子集群中的一部分；

所述确定模块1002还用于：

在将所述至少一个第一资源，确定为所述目标子集群对应的目标资源之后，根据所述第二资源类型和所述第二资源数量，确定至少一个第二资源；

若所述目标子集群为第一类子集群，则将所述目标子集群对应的目标资源更新为所述第二资源。

在一种可能的设计中，针对任一种资源类型，配置有所述资源类型下的单个资源的副本数量；

所述资源配置信息还包括：资源调度信息，其中，所述资源调度信息用于指示所述多个目标子集群共同配置各种资源类型下单个资源的多个副本；

所述确定模块1002还用于：

在将所述至少一个第一资源，确定为所述目标子集群对应的目标资源之后，根据所述资源调度信息，确定所述目标子集群对应的目标资源中，各个资源类型下的单个资源各自对应的副本数量。

在一种可能的设计中，所述处理模块1003具体用于：

针对任一个所述目标子集群，将所述第一集群的操作权限转换为所述目标子集群的操作权限；

通过所述第一集群中的资源管理引擎，调用所述第一集群的资源下发接口，以将所述目标资源配置给对应的所述目标子集群。

在一种可能的设计中，所述处理模块1003还用于：

在所述将各所述目标资源，分别配置给各自对应的目标子集群之后，

在确定所述第一应用的配置信息发生更新时，根据更新后的配置信息，重新确定所述第一应用的目标子集群，以及重新确定所述目标子集群对应的目标资源，并且将重新确定的所述目标资源分别配置给各自对应的目标子集群；或者，

针对任一个所述目标子集群，在确定所述目标子集群上的目标资源发生异常时，向发生异常的所述目标子集群重新配置资源，以使得所述目标子集群上的资源保持为对应的目标资源；或者，

在确定所述第一应用的配置信息从所述第一集群删除时，清理各所述目标子集群上配置的目标资源。

本实施例提供的装置，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。

图11为本申请实施例提供的资源处理设备设备的硬件结构示意图，如图11所示，本实施例的资源处理设备设备110包括：处理器1101以及存储器1102；其中

存储器1102，用于存储计算机执行指令；

处理器1101，用于执行存储器存储的计算机执行指令，以实现上述实施例中资源处理设备方法所执行的各个步骤。具体可以参见前述方法实施例中的相关描述。

可选地，存储器1102既可以是独立的，也可以跟处理器1101集成在一起。

当存储器1102独立设置时，该资源处理设备设备还包括总线1103，用于连接所述存储器1102和处理器1101。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上资源处理设备设备所执行的资源处理设备方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。

应理解，上述处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application Specific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims

1.一种资源处理方法，其特征在于，应用于第一集群，所述第一集群用于控制多个子集群，所述方法包括：

获取第一应用的配置信息；

将各所述目标资源，分别配置给各自对应的目标子集群。

2.根据权利要求1所述的方法，其特征在于，所述配置信息包括：集群筛选条件、资源配置信息；

所述根据所述配置信息，在所述多个子集群中确定部署所述第一应用的至少一个目标子集群，以及确定各所述目标子集群各自对应的目标资源，包括：

3.根据权利要求2所述的方法，其特征在于，所述根据所述集群筛选条件，在所述第一集群控制的多个子集群中，确定满足所述集群筛选条件的至少一个目标子集群，包括：

对所述第一集群访问子集群的权限进行校验；

4.根据权利要求2或3所述的方法，其特征在于，所述资源配置信息包括：第一资源类型、第一资源数量；

所述根据所述资源配置信息，确定各所述目标子集群各自对应的目标资源，包括：

5.根据权利要求4所述的方法，其特征在于，所述资源配置信息还包括：差异化配置信息，其中，所述差异化配置信息中包括针对第一类子集群指示的第二资源类型、第二资源数量，所述第一类子集群为所述多个目标子集群中的一部分；

所述将所述至少一个第一资源，确定为所述目标子集群对应的目标资源之后，所述方法包括：

根据所述第二资源类型和所述第二资源数量，确定至少一个第二资源；

6.根据权利要求4或5所述的方法，其特征在于，针对任一种资源类型，配置有所述资源类型下的单个资源的副本数量；

根据所述资源调度信息，确定所述目标子集群对应的目标资源中，各个资源类型下的单个资源各自对应的副本数量。

7.根据权利要求1-6任一项所述的方法，其特征在于，所述将各所述目标资源，分别配置给各自对应的目标子集群，包括：

8.根据权利要求1-7任一项所述的方法，其特征在于，所述将各所述目标资源，分别配置给各自对应的目标子集群之后，所述方法还包括：

针对任一个所述目标子集群，在确定所述目标子集群上的目标资源发生异常时，向发生异常的所述目标子集群重新配置资源，以使得所述目标子集群上的资保持为对应的目标资源；或者，

9.一种资源处理装置，其特征在于，应用于第一集群，所述第一集群用于控制多个子集群，所述装置包括：

获取模块，用于获取第一应用的配置信息；

10.一种资源处理设备，其特征在于，包括：

存储器，用于存储程序；

处理器，用于执行所述存储器存储的所述程序，当所述程序被执行时，所述处理器用于执行如权利要求1至8中任一所述的方法。

11.一种计算机可读存储介质，其特征在于，包括指令，当其在计算机上运行时，使得计算机执行如权利要求1至8中任一所述的方法。

12.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至8中任一所述的方法。