CN116954816A - 容器集群控制方法、装置、设备及计算机存储介质 - Google Patents

Abstract

本申请公开了一种容器集群控制方法、装置、设备及计算机存储介质，涉及集群技术领域，可应用至云计算领域，该方法通过全局管理节点和本地管理节点二级管理的模式，可以显著提升集群管理的节点规模和支持应用程序跨集群调度，提升资源共享率和利用率，并通过任务控制器提供细粒度的应用生命周期管理，在集群节点运维、软件更新时，能够将业务进程调整时的出错率，提供更高的服务保障，且支持异构节点接入，可根据不同的应用程序特点，调整节点的配置文件，来提升应用程序性能，降低资源消耗，进一步提升集群整体利用率。

Description

容器集群控制方法、装置、设备及计算机存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及集群技术领域，提供一种容器集群控制方法、装置、设备及计算机存储介质。

背景技术

随着云计算技术的快速发展，对于大规模集群的需求逐渐增大，而集群管理与调度的性能，决定了大规模集群的基础设施即服务(Infrastructure as aService，IaaS)层的资源利用率，因而，目前对于高效的大规模集群管理系统有着迫切的需求。

目前较为常见的集群管理系统例如另一种资源协调者(Yet Another ResourceNegotiator，YARN)以及Kubernetes(K8s)等，其中，YARN是大数据领域的专用集群管理调度器，通常只适合调度大数据计算框架任务的调度，并非是通用的集群管理系统，相对YARN而言，Kubernetes的使用率更高，但是Kubernetes的功能实现依赖etcd(一款分布式存储中间件)，当集群规模增大后，etcd的元数据会显著增大，则相关的操作的耗时则会显著增加，因此，通常Kubernetes管理的集群规模在5000台机器左右，当集群规模更大后，通过Kubernetes来进行管理则会出现较为明显的性能问题。

为了解决单个Kubernetes集群管理机器数量上限的问题，相关技术中提出了集群联邦的解决方案，即引入一个集群代理层，通过该集群代理层将多个小的Kubernetes集群组合成一个大的集群，以此来提升集群规模。但是，通过这种联邦的方式，所形成的集群中各个小的Kubernetes集群是独立调度的，会存在多个小集群控制平面，使得同一个应用程序则不能跨多个小集群进行部署，从而使得小集群之间可能存在负载不均衡的情况，且相互之间的资源也无法共享，使得资源利用率不高。

发明内容

本申请实施例提供一种容器集群控制方法、装置、设备及计算机存储介质，用于提升容器集群的资源利用率。

一方面，提供一种容器集群控制方法，应用于容器集群系统包括的全局管理节点，所述容器集群系统还包括多个容器集群，以及部署于各个容器集群的本地管理节点；该方法包括：

接收目标对象提交的任务部署请求，所述任务部署请求指示待部署的目标业务任务所需的容器资源数目；

基于各个本地管理节点上报的本地资源状态信息，从所述各容器集群中，获得所述目标对象对应的剩余容器资源集，以及基于预设的资源选择策略，从所述剩余容器资源集中，选择出满足所述容器资源数目的目标容器资源集，所述目标容器资源集来源于所述多个容器集群中的至少一个容器集群；

将所述目标业务任务划分为多个子任务，并分别从所述目标容器资源集中，为所述多个子任务分配相应的目标容器资源；

基于资源分配结果，分别向所述至少一个容器集群各自对应的本地管理节点发送资源调度请求，以使得各本地管理节点基于接收的资源调度请求，调度相应容器集群中的目标容器资源执行相应的子任务。

一方面，提供一种容器集群控制方法，应用于集群管理系统包括的本地管理节点，所述集群管理系统还包括全局管理节点和多个容器集群，所述多个容器集群各自对应配置有本地管理节点；所述方法包括：

向所述全局管理节点上报本地容器集群的本地资源状态信息，所述本地资源状态信息指示所述本地容器集群的节点资源状态；

接收所述全局管理节点发送的资源调度请求，所述资源调度请求用于指示通过所述本地容器集群中的目标容器资源执行目标对象提交的目标业务任务的至少一个子任务，所述目标容器资源是所述全局管理节点基于所述本地资源状态信息以及预设的资源选择策略，从所述目标对象在本地容器集群中的剩余容器资源中选择出的；

响应于所述资源调度请求，通过所述目标容器资源启动相应的目标容器，并通过所述目标容器执行所述至少一个子任务。

一方面，提供一种容器集群控制装置，应用于容器集群系统包括的全局管理节点，所述容器集群系统还包括多个容器集群，以及部署于各个容器集群的本地管理节点；所述装置包括：

收发单元，用于接收目标对象提交的任务部署请求，所述任务部署请求指示待部署的目标业务任务所需的容器资源数目；

资源调度单元，用于基于各个本地管理节点上报的本地资源状态信息，从所述各容器集群中，获得所述目标对象对应的剩余容器资源集，以及基于预设的资源选择策略，从所述剩余容器资源集中，选择出满足所述容器资源数目的目标容器资源集，所述目标容器资源集来源于所述多个容器集群中的至少一个容器集群；

资源分配单元，用于将所述目标业务任务划分为多个子任务，并分别从所述目标容器资源集中，为所述多个子任务分配相应的目标容器资源；

所述收发单元，用于基于资源分配结果，分别向所述至少一个容器集群各自对应的本地管理节点发送资源调度请求，以使得各本地管理节点基于接收的资源调度请求，调度相应容器集群中的目标容器资源执行相应的子任务。

一方面，提供一种容器集群控制装置，应用于集群管理系统包括的本地管理节点，所述集群管理系统还包括全局管理节点和多个容器集群，所述多个容器集群各自对应配置有本地管理节点；所述装置包括：

状态上报单元，用于向所述全局管理节点上报本地容器集群的本地资源状态信息，所述本地资源状态信息指示所述本地容器集群的节点资源状态；

收发单元，用于接收所述全局管理节点发送的资源调度请求，所述资源调度请求用于指示通过所述本地容器集群中的目标容器资源执行目标对象提交的目标业务任务的至少一个子任务，所述目标容器资源是所述全局管理节点基于所述本地资源状态信息以及预设的资源选择策略，从所述目标对象在本地容器集群中的剩余容器资源中选择出的；

执行单元，用于响应于所述资源调度请求，通过所述目标容器资源启动相应的目标容器，并通过所述目标容器执行所述至少一个子任务。

一方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任一种方法的步骤。

一方面，提供一种计算机存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任一种方法的步骤。

一方面，提供一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机程序，处理器执行该计算机程序，使得该计算机设备执行上述任一种方法的步骤。

本申请实施例中，容器集群系统包括全局管理节点和部署于各个容器集群的本地管理节点，全局管理节点用于统揽全局的容器资源调度，本地管理节点用于管理本地容器集群的资源管理，通过采用全局管理节点-本地管理节点的两级管理模式，大大提升了所能管理的容器集群的规模，使得能够针对超大规模集群实现调度和管理，此外，整个容器集群系统的调度控制都是由全局管理节点来实现的，因而对于整个容器集群系统而言只存在一个控制平面，在接收到目标对象提交任务部署请求时，全局管理节点可以基于各个本地管理节点上报的本地资源状态信息，从各容器集群中，获得目标对象在整个容器集群系统中的剩余容器资源集，以将其所有的剩余容器资源统一进行调度，来满足任务部署请求指示的目标业务任务的需求，从而能够实现跨集群的容器资源调度，以充分利用各个容器集群中的碎片化资源，提升容器集群整体的资源利用率。

附图说明

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

图1为本申请实施例提供的应用场景示意图；

图2为本申请实施例提供的容器集群系统的系统架构图；

图3为本申请实施例提供的容器集群控制方法的流程示意图；

图4为本申请实施例提供的指定调度器的流程示意图；

图5为本申请实施例提供的调度原理示意图；

图6为本申请实施例提供的数据分片分布示意图；

图7为本申请实施例提供的结合任务控制器实现任务调度的流程示意图；

图8a～图8b为本申请实施例提供的任务控制器的实现原理示意图；

图9为本申请实施例提供的reblance过程的流程示意图；

图10为本申请实施例提供的一种容器集群控制装置的一种结构示意图；

图11为本申请实施例提供的另一种容器集群控制装置的一种结构示意图；

图12为本申请实施例提供的计算机设备的组成结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

可以理解的是，在本申请的下述具体实施方式中，涉及到目标对象相关的数据，例如资源偏好信息，当本申请的各实施例运用到具体产品或技术中时，需要获得相关许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

为便于理解本申请实施例提供的技术方案，这里先对本申请实施例使用的一些关键名词进行解释：

容器(container)资源：容器技术是指有效的将单个操作系统的资源划分到孤立的组中，以便更好的在孤立的组之间平衡有冲突的资源使用需求，则能够提供一个容器运行的资源则称之为容器资源，在一个物理机器节点上，可以包含一个或者多个容器资源可供调度。

容器集群：容器集群包含多个物理机器节点，每个物理机器节点包含一个或者多个容器资源，这些容器资源所组成的集群及称之为容器集群。

Kubernetes：是一种开源的容器调度、编排管理软件。

Etcd：是一个开源的、分布式的键值对数据存储系统，是基于go语言实现，主要用于共享配置和服务发现的组件，用于解决集群管理系统中os升级时的分布式并发控制、配置文件的存储与分发等问题。因此，etcd是在分布式系统中提供强一致性、高可用性的组件，用来存储少量重要的数据。

raft：一种分布式共识算法，主要用于管理日志复制的一致性。

ZooKeeper：是一个分布式的应用程序协调服务。

伴随着云计算技术的快速发展，云原生理念也被业界广泛采纳。对高效的大规模集群管理系统有着迫切的需求以及更高的要求，因为集群管理与调度的性能，决定了对IAAS层资源利用率，更高的利用率，可以有效降低云服务商的成本，提升竞争力。相关技术中，为了解决单个Kubernetes集群管理机器数量上限的问题，相关技术中提出了集群联邦的解决方案，但是，通过联邦的方式所形成的集群中各个小的Kubernetes集群是独立调度的，会存在多个小集群控制平面，使得同一个应用程序则不能跨多个小集群进行部署，从而使得小集群之间可能存在负载不均衡的情况，且在实际生产环境中，业务任务通常都存在潮汐现象，当某个容器集群在业务低峰时，会出现较大范围的机器空闲，但按照集群联邦的方式集群相互之间的资源也无法共享，使得资源利用率不高。

考虑到目前联邦的方式其问题主要在于各个小的容器集群中的容器资源是无法被统一调度的，因而虽然在一定程度上行扩充了集群规模，但各个小的容器集群之间是无法互通，因此，若想要解决集群联邦所带来的问题，则首先需要解决的是容器集群统一调度的问题。

基于此，本申请实施例提供了一种容器集群控制方法，在该方法中，容器集群系统包括全局管理节点和部署于各个容器集群的本地管理节点，全局管理节点用于统揽全局的容器资源调度，本地管理节点用于管理本地容器集群的资源管理，通过采用全局管理节点-本地管理节点的两级管理模式，大大提升了所能管理的容器集群的规模，使得能够针对超大规模集群实现调度和管理，此外，整个容器集群系统的调度控制都是由全局管理节点来实现的，因而对于整个容器集群系统而言只存在一个控制平面，在接收到目标对象提交任务部署请求时，全局管理节点可以基于各个本地管理节点上报的本地资源状态信息，从各容器集群中，获得目标对象在整个容器集群系统中的剩余容器资源集，以将其所有的剩余容器资源统一进行调度，来满足任务部署请求指示的目标业务任务的需求，从而能够实现跨集群的容器资源调度，以充分利用各个容器集群中的碎片化资源，提升容器集群整体的资源利用率。

此外，目前的集群管理系统中，都缺乏针对细粒度的应用生命周期管理，使得集群管理系统是不能感知到应用程序内部的状态的，从而对应用进行操作时可能导致应用数据发生错误，例如错误重启应用会导致数据不一致。基于此，本申请实施例中，可以注册任务控制器(Application Controller，AC)，当一个任务注册有AC时，集群调度时会和AC进行协调，使得集群可以感知业务任务状态，实现细粒度的生命周期管理，在集群节点运维、软件更新时，避免出现数据不一致等情况的发生。

本申请实施例中，还可以持续检测集群中机器节点的负载状态，当出现负载较大的机器节点时，将其任务调度磁盘或网络空闲的机器节点中，以加速业务任务执行速度，同时也使得集群整体资源使用更加均衡。此外，本申请实施例还可以在整个集群中虚拟一个可用区(Zone)，每个可用Zone为一群机器节点的集合，不同Zone中的机器节点的系统环境配置可以不同，以满足不同业务作业对系统配置参数的不同的要求。

下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

本申请实施例提供的方案可以适用于容器集群管理场景中，比如适用于超大规模容器集群管理场景中。如图1所示，为本申请实施例提供的一种应用场景示意图，在该场景中，可以包括全局管理节点(Cluster Resource Manager，CRM)组和多个容器集群102，CRM组包含多个CRM101，且每个容器集群102均部署有相应的本地管理节点(Local ResourceManager，LRM)1021，用于管理同一容器集群的机器节点资源。

如图1所示，多个CRM101之间通过共识算法互备冗余以实现高可用(HighAvailability，HA)要求，其中一个CRM101作为全局管理主节点，用于提供写服务，其余CRM101作为全局管理备用节点，用于提供只读服务。其中，共识算法例如可以为raft算法，当然，也可以为其他可能的方式实现高可用，例如还可以通过ZooKeeper、etcd等中间件选主的方式实现高可用，本申请实施例对此不做限制。

一个容器集群102也可以称为一个数据中心(Data Center，DC)，是一个逻辑概念，比如若是一个地理位置的机房M规模较小时，则此时该机房M中的机器节点可以组成一个容器集群，例如图1所示的容器集群1其由同一机房的所有机器节点组成，而当机房M规模较大，则也可以拆分为多个容器集群，如图1所示，机房2所包含的机器节点数量规模较大，则被划分为了两个容器集群，即图1所示的容器集群2和3，通常一个逻辑上的容器集群可以包含数千台机器节点。其中，每个容器集群也可以包含多个LRM1021，用于管理本容器集群中的所有机器节点资源，多个LRM1021之间通过共识算法互备冗余以实现高可用要求，其中一个LRM1021作为本地管理主节点，用于提供写服务，其余LRM1021作为本地管理备用节点，用于提供只读服务，且同一时刻只有一个LRM1021向CRM101上报心跳，以更新本容器集群的本地资源状态信息。

一个CRM组可以管理数千个容器集群，从而整体上达到管理百万机器节点的规模。并且，整个集群中只存在一个控制平面，CRM可以将一个业务任务拆分为多个子任务，分发到任意容器集群中的某些节气节点执行，避免了集群联邦技术中存在多个子集群，每个子集群都存在一个控制平面，从而不能实现跨集群调度的问题。

上述的CRM101和LRM1021可以通过服务器来实现，例如可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、即内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云端服务器，但并不局限于此。

具体的，每个CRM101和LRM1021均可以包括一个或多个处理器、存储器以及交互输入/输出(input/output，I/O)接口等。此外，每个CRM和LRM还可以配置数据库，可以用于存储本申请实施例中涉及到的数据信息等。其中，每个CRM101或者LRM1021的存储器中还可以存储本申请实施例提供的容器集群控制方法中各自所需执行的程序指令，这些程序指令被处理器执行时能够用以实现本申请实施例提供的容器集群控制过程，例如CRM101中可以存储集群调度、移除或者参数配置等相关过程的程序指令，以被CRM101的处理器执行实现这些过程，LRM1021中可以存储本地资源管理相关过程的程序指令，以被LRM1021的处理器执行实现重排序过程。

本申请实施例中，CRM101和LRM1021之间可以通过一个或者多个网络进行直接或间接的通信连接。该网络可以是有线网络，也可以是无线网络，例如无线网络可以是移动蜂窝网络，或者可以是无线保真(Wireless-Fidelity，WIFI)网络，当然还可以是其他可能的网络，本申请实施例对此不做限制。

需要说明的是，图1所示只是举例说明，实际上容器集群、CRM或者LRM等的数量均不受限制，在本申请实施例中不做具体限定。

如图2所示，为本申请实施例提供的一种容器集群系统的系统架构图，在该架构中，可以包括CRM部分和LRM部分，通常而言，在CRM组和LRM组中都会选举出一个master节点来实现相关的管理过程，如图2所示的CRM-master和LRM-master。

具体的，CRM部分可以包括如下模块：

(1)接口服务(API Server)模块

API Server模块作为容器集群系统的总入口，负责应用程序编程接口(Application Programming Interface，API)接入、权限控制，限流等功能。API接入功能包括用于接收前端发送的集群调用请求，如增、删、改、查等请求，并在集群调用请求通过合法性校验后，将该调用请求转发给其他模块进行进一步处理。其中，合法性校验包含API版本检测、用户身份检查、资源权限验证以及流量控制等校验功能。此外，API Server模块还提供了系统管理接口的能力。

参见图2所示，通过API Server可以将用户自定义任务调度器(ApplicationLevel Orchestrator，ALO)注册到容器集群系统，进而容器集群系统中可以同时有多个调度器存在，当用户提交的任务数据中指定了ALO，则会将该任务委托给对应的ALO进行管理，从而可以通过ALO使得调度更加灵活，如批处理作业、机器学习类作业，大数据处理作业以及万维网(World Wide Web，web)服务，可以使用不同的调度器，以满足不同的业务需求，达到最优调度效果。此外，通过API Server模块，业务侧还可以注册AC来达到更为细粒度的调度、作业管理的效果。

(2)调度器(Orchestrator)模块

Orchestrator模块用于管理业务任务的整个生命周期，并根据业务任务配置参数和集群状态，将业务任务调度到一个或多个机器节点中去执行。

(3)资源均衡管理器(Node Re-Balancer)模块

Node Re-Balancer模块为机器节点的业务任务资源均衡管理器，能够持续异步的检测机器节点的资源状态信息，包括机器节点的网络资源、磁盘资源、中央处理器(CentralProcessing Unit，CPU)资源或者存储器(Memory)资源等资源的资源状态信息，Node Re-Balancer模块可以有效判断因为网络或磁盘等资源不足，导致业务任务执行慢的作业的问题，当发现此类型的任务，Node Re-Balancer模块则可与Orchestrator模块协同，将任务调度磁盘或网络空闲的机器节点，一方面可以加速业务任务执行速度，另一方面也使得集群的整体资源使用更加均衡。磁盘IO重、网络请求重的业务任务在大数据计算场景中是非常常见的，例如数据同步或者Hive表join等任务，进而通过Node Re-Balancer模块可以有效避免相关技术中进行调度时并不考虑网络资源和磁盘资源使用率所带来的问题。

(4)容量管理服务(Business Capacity Service，BCS)模块

BCS模块可根据业务配置，从容器集群中选取若干机器节点组成一个逻辑Zone，每个逻辑Zone中的机器系统配置参数可以与集群其他节点不同，以实现以满足不同业务任务对系统配置参数的不同的要求。系统配置参数例如可以包括系统核心(kernel)版本、CPU加速技术(Turbo Boost)、网卡配置参数等。当一个机器节点从一个可用Zone切换到另外一个可用Zone时，则容器集群中的profiler模块会判断是否需要重置系统配置，以达到适配业务任务的需求，达到最佳系统环境配置。进而，通过BCS模块与profiler模块的有效协调，实现动态参数配置，使得不同任务使用不同系统配置参数，达到提升业务任务性能的有益效果。

具体的，参见图2所示，LRM部分可以包括如下模块：

(1)参数配置器(Profiler)模块

Profiler模块部署在每一个机器节点上，用于根据LRM的指令，动态调整当前机器节点的系统配置参数，用于适配不用类型的业务任务，提升单个机器节点的业务执行效率。例如，当一个机器节点从一个逻辑Zone切换加入到另外一个逻辑Zone，则Profiler模块可以根据业务配置，修改机器节点的系统配置参数，以达到适配当前业务任务的目的。

(2)节点健康检测(Health Check Manager，HCM)模块

HCM模块用于收集机器节点的资源状态信息，从而上报给CRM。

(3)进程代理(Agent)模块

Agent模块部署在容器集群中的每一个机器节点，用于采集当前机器节点的资源状态等信息汇报到HCM模块，以及在本机器节点启动相应的业务任务进程。

下面结合上述描述的应用场景，参考附图来描述本申请示例性实施方式提供的容器集群控制方法，需要注意的是，上述应用场景仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。

参见图3所示，为本申请实施例提供的容器集群控制方法的流程示意图，在该方法中涉及到全局管理节点和本地管理节点的交互过程，因此在后续的介绍中，将CRM和LRM分别执行的内容联合进行介绍。需要说明的是，通常而言，后续涉及到的全局管理节点和本地管理节点均是指全局管理主节点和本地管理主节点，但在实际应用时，全局管理主节点和本地管理主节点可以随着容器集群系统的状态发生切换，但无论如何切换，本申请实施例提供的容器集群控制方法的执行主体都可以是当前的全局管理主节点和本地管理主节点。该方法的具体实施流程如下：

步骤301：全局管理节点接收目标对象提交的任务部署请求，任务部署请求指示待部署的目标业务任务所需的容器资源数目。

本申请实施例中，任务部署请求用于请求通过目标对象所拥有的容器资源执行目标业务任务，且任务部署请求指示了待部署的目标业务任务所需的容器资源数目。其中，任务部署请求中可以直接包含目标业务任务所需的容器资源数目，例如，目标对象可以通过容器集群系统所提供的客户端(client)进行目标业务任务的提交，在进行目标业务任务的任务配置时，则可以输入该目标业务任务所需的容器资源数目；或者，任务部署请求中可以包含目标业务任务的任务量，则可以基于任务量预估所需的容器资源数目；或者，任务部署请求中可以包含目标业务任务的完成时间要求，进而可以基于任务量以及完成时间要求来确定其所需的容器资源数目。

相应的，全局管理节点中的API Server模块作为容器集群系统的总接入，则会接收到该任务部署请求，同时针对该任务部署请求进行合法性校验。

具体的，合法性校验可以包括API版本检测、用户身份检查、资源权限验证、以及流量控制等功能。其中，API检测功能主要是考虑升级兼容性的问题，当目标对象在客户端提交任务部署请求时，任务部署请求中会携带客户端的版本号，则API Server模块接收到该任务部署请求后，则可以从中读取该版本号，并根据后端的配置，确定该版本号对应的版本是否为废弃的，如果是废弃版本就直接拒绝该请求，如果是可用版本，则根据版本号将其路由到相应版本的服务层；用户身份检查是指根据任务部署请求携带的目标对象的身份信息进行身份校验，以确认目标对象的身份是否合法，身份校验支持多种方式，如临时秘钥校验或者代理token校验的方式；资源权限验证是指根据目标对象的级别来进行权限校验，以判断当前请求的动作是否允许执行，例如当前目标对象为只读用户则不能响应其删除应用的请求，或者也可以根据资源的访问控制列表(Access Control List，ACL)规则判断目标对象是否有权限操作某个资源，也支持按照目标对象所在的用户组来判断；流量控制是指进行限流操作，防止异常请求导致服务不可用。

在实际应用时，除了本申请实施例的任务部署请求之外，还可以包括其他的操作请求，如增、删、改、查等操作请求，针对这些请求，API Server模块同样可以执行上述的校验操作，并发送到后续的其他模块进行处理。

步骤302：各个本地管理节点向全局管理节点上报本地资源状态信息。

本申请实施例中，为了便于全局管理节点实现容器资源的分配，各个本地管理节点需要向全局管理节点上报自身对应的容器集群的本地资源状态信息，本地资源状态信息用于指示自身对应的容器集群中的各个机器节点所包括的容器资源的资源状态信息。

在一种可能的实施方式中，各个本地管理节点可以采用上报心跳包(heartbeat)的形式向全局管理节点上报本地资源状态信息，例如可以预先配置各个本地管理节点上报心跳包的周期，则各个本地管理节点可以周期性的向全局管理节点上报心跳包，使得全局管理节点知晓各个容器集群中容器资源的资源状态。

需要说明的是，步骤302上报本地资源状态信息的过程与步骤301的过程并无实质上的先后顺序，可以是在步骤301触发时，触发获取本地资源状态信息，也可以是不管步骤301的过程是否触发，步骤302的过程可以是持续进行的，本申请实施例对此并不进行限制。

步骤303：全局管理节点从各个容器集群中，获得目标对象对应的剩余容器资源集。

通常而言，容器集群中的容器资源是需要权限调用的，例如目标对象所能调用的容器资源是其拥有调用权限的容器资源，因此在部署目标对象的目标业务任务时，则需要调用目标对象对应的容器资源来部署。其中，通过被动管理节点上报的本地资源状态信息可以获知各个容器集群中的资源状态，同样的，则可以从中获知目标对象所拥有的容器资源的资源状态，从而从中确定出目标对象对应的剩余容器资源集，剩余容器资源集是指目标对象所拥有的所有容器资源的总和，其可以来源于同一个容器集群，也可以来源于不同的容器集群，换句话说，在本申请实施例提供的容器集群系统中，所有容器集群中的资源都是放在同一层面上进行调度的，因而不管目标对象的所拥有的容器资源来源于哪一个容器集群，都是可以统一被全局管理节点调度的，进而实现了跨集群的资源调度。

步骤304：全局管理节点基于预设的资源选择策略，从剩余容器资源集中，选择出满足容器资源数目的目标容器资源集，目标容器资源集来源于多个容器集群中的至少一个容器集群。

本申请实施例中，资源选择策略可以是目标对象预先配置的，也可以是容器集群系统默认设置的。其中，资源选择策略可以是基于用户容器标签(tag)偏好的选择策略，也可以是优先同地域的选择策略，当然也可以是其他可能的选择策略，本申请实施例对此不做限制。

在一种可能的实施方式中，在进行容器资源的选择时，可以优先检测目标对象的剩余容器资源集所来源的各个容器集群中，是否存在剩余容器资源的总数目不小于容器资源数目的目标容器集群，也就是说可以优先为同一业务任务调用同一容器集群的容器资源，从而降低业务任务过程中涉及到的通信时延，那么则需要首先确定是否满足分配同一容器集群的容器资源的前提条件，若是，则表明从同一容器集群中可以选择出足够多的容器资源实现目标业务任务的调度，则可以从剩余容器资源集中目标容器集群对应的剩余容器资源中，选择出满足容器资源数目的目标容器资源集。

否则，也就是任一个容器资源均不足以满足容器资源数目的要求，则基于目标对象针对各个容器集群的资源偏好信息，依次从各个容器集群对应的剩余容器资源中进行资源选择，直至满足容器资源数目为止，获得目标容器资源集。例如，目标对象针对各个容器集群存在资源偏好等级，则优先从资源偏好等级高的容器集群中选择容器资源，若选择的容器资源数目仍不满足目标业务任务的需求，则继续从下一资源偏好等级次之的容器集群中选择容器资源，直至满足目标业务任务需求的容器资源数目为止。

本申请实施例中，资源调度的过程可以是通过全局管理节点包括的Orchestrator模块来实现的，即API Server模块针对任务部署请求进行合法性校验且校验通过时，则APIServer模块可以将任务部署请求转发给Orchestrator模块进行处理，以通过Orchestrator模块进行资源调度。

本申请实施例中，当处理的业务任务不同时，可以通过不同类型的调度器，从而适配当前业务任务的调度需求，达到最优的调度效果。因此，目标对象可以预先进行自定义任务调度器的注册，将自定义任务调度器注册到容器集群系统，从而后续的业务任务可以指定通过该自定义任务调度器来进行调度，相应的，其提交的业务任务则会委托给对应的自定义任务调度器进行管理。

具体的，参见图4所示，为本申请实施例提供的指定调度器的流程示意图。其中，目标对象可以预先发起调度器注册请求，全局管理节点的API Server模块响应于目标对象发送的调度器注册请求，可以基于调度器注册请求携带的自定义调度器信息，执行调度器注册操作，以在集群管理系统中新增自定义任务调度器。其中，自定义调度器信息例如可以包含调度器的名称、类型、调度策略等信息，以便于后续实现相应类型作业的调度。

那么，目标对象在后续发起任务部署请求时，则可以在任务部署请求中指定使用自身注册的自定义任务调度器，从而当API Server模块将任务部署请求转发给Orchestrator模块进行资源调度时，Orchestrator模块可以解析确定其指定了自定义任务调度器，则Orchestrator模块调用自定义任务调度器，基于资源选择策略，从剩余容器资源集中，选择出满足容器资源数目的目标容器资源集，也就是将该任务部署请求转交给指定的自定义任务调度器进行调度处理。

步骤305：全局管理节点将目标业务任务划分为多个子任务，并分别从目标容器资源集中，为多个子任务分配相应的目标容器资源。

本申请实施例中，所选取的各个容器资源可以分别用于执行目标业务任务的不同任务，因此，为了进行容器资源调度，全局管理节点可以对目标业务任务进行拆分，获得多个子任务，并为不同的子任务分配相应的目标容器资源。

在一种可能的实施方式中，任务的拆分可以是基于目标对象的指定进行的，例如目标对象在进行目标业务任务的提交时，可以预先指定目标业务任务拆分后的子任务，以及每个子任务所需的容器资源，这样，全局管理节点可以依据目标对象的指定进行任务的拆分，并按照各个子任务所需的容器资源数目进行目标容器资源的分配。

在一种可能的实施方式中，任务的拆分也可以是按照工作量进行的，即可以均衡各个子任务所需要的容器资源，将目标业务任务均匀拆分为工作量相当的多个子任务，并分别部署到各个容器资源上执行。

在进行容器资源的分配时，还可以考虑子任务之间的关联关系，例如可以优先将存在关联的子任务分配到同一容器集群中去执行，则当这些子任务执行时需要相互进行调用或者需求其他子任务的任务数据时，则可以在同一容器集群中获取，以降低相应数据的传输时延，提升业务任务的执行效率。

步骤306：全局管理节点基于资源分配结果，分别向至少一个容器集群各自对应的本地管理节点发送资源调度请求。

本申请实施例中，当目标容器资源集均来源于同一容器集群时，则可以在资源分配完成后，向该容器集群的本地资源管理节点发送资源调度请求，资源调度请求用于指示通过本地容器集群中的目标容器资源执行目标对象提交的目标业务任务的至少一个子任务。其中，资源调度请求中可以携带全局管理节点的资源分配结果，从而本地资源管理节点可以知晓需要调度哪些目标容器资源执行相应的子任务。

本申请实施例中，当目标容器资源集来源于不同的容器集群时，则全局管理节点则可以分别向涉及到的至少一个容器集群的本地管理节点发送资源调度请求，每个资源调度请求中携带了本地容器集群中所需调用的容器资源，以及每个容器资源所需执行的子任务，进而本地管理节点可以基于资源调度请求，调度相应的目标容器资源进行相应子任务的执行。

步骤307：本地管理节点响应于资源调度请求，通过目标容器资源启动相应的目标容器，并通过目标容器执行相应的至少一个子任务。

具体的，一个目标容器可以用于执行一个或者多个子任务，具体任务的分配则可以依据实际的调度策略来实现。

本申请实施例中，在一个容器集群中，会存在多个本地管理节点，每个本地管理节点可以通过专用节点来实现，以提升管理服务的稳定性，多个本地管理节点可以使用raft协议进行选举，使得同一时刻保持同一容器集群个只有一个本地管理节点作为主节点，提供写服务，其他LRM可以作为只读节点，提供读服务，以分担主节点的请求压力。通常而言，本地管理节点的数量需要部署3个或者以上，当读取请求压力较大时，可以通过扩容本地管理节点来分担压力。每个本地管理节点都会写日志(log)到本地磁盘，非主节点会定期压缩、整理和合并log，并将其写入到共享存储中，那么当本地管理节点出现异常发生重启时，则可以从共享存储中加载log，回放状态信息，以保证数据的正确性。

具体的，共享存储可以采用Hadoop分布式文件系统(Hadoop Distributed FileSystem，HDFS)或者对象存储的方式来实现，当然，也可以采用将log写入一个分布式的KV存储系统的方式进行保存，来保障数据不丢失，或者采用其他可能的方式，本申请实施例对此不做限制。

与此同理的，全局管理节点也可以采用与本地管理节点同样的技术来达到高可用的效果。同时，本地管理节点会向全局管理节点汇报心跳，以达到更新整个集群的资源状态信息的目的，这样一来，整个容器集群系统中有且只存在一个控制平面，使得全局管理节点可以将一个业务任务拆分为多个子任务，分发到任意容器集群中的机器节点执行，实现跨集群调度的效果。

下面参见图5所示，结合一个任务运行过程的具体用例，来阐述本申请实施例的调度原理。

目标对象A在容器集群系统拥有的资源队列为Q，Q中总共有100个相同规格的容器资源，这100个容器资源分别分布在容器集群1的60个机器节点上，和容器集群2的40个机器节点上，参见图5所示，当前，队列Q中已经分配出去了60个容器资源，还剩余40个容器，容器集群1中剩余30个容器资源，容器集群2中剩余10个容器资源。

当目标对象A向容器集群系统提交一个机器学习任务，例如TensorFlow模型训练任务，合计需要使用35个容器资源。那么，首先全局管理节点的API Server模块会接收到该任务部署请求，当参数校验和权限校验等前置依赖全部校验通过后，API Server模块则会请求Orchestrator模块调度和启动目标对象A指定数量的容器来执行TensorFlow模型训练任务。

可以看到，由于单一的容器集群最多也只有30个容器资源，因此单一的容器集群是无法满足该TensorFlow模型训练任务的训练资源需求的，则Orchestrator模块会同时考虑容器集群1的本地管理节点1上报的机器资源状态和容器集群2的本地管理节点2上报的机器资源状态，同时从容器集群1中和容器集群2中来分配容器资源，此时可以考虑目标对象的容器tag偏好来进行容器资源分配，比如tag偏好为优先同地域。一种可选的分配方案是，容器集群1中分配28个容器资源，容器集群2中分配7个容器资源，可见，正是因为本申请实施例采用了原生扩展方案，在整个容器集群系统中有且只有一个控制平面，即全局管理节点，从而才能将所有的容器集群的容器资源进行统一调度，最终实现跨集群调度，避免了相关技术中集群联邦方案带来的资源碎片的问题。

本申请实施例中，考虑到相关技术中的集群管理系统，均缺乏细粒度的应用生命周期管理，以Kubernetes为例，Kubernetes是无法感知部署的应用程序内部的状态的，发生错误重启应用时则容易导致数据不一致，参见图6所示，一份数据有A、B、C三个数据分片，为了保障数据的可靠性，每一份数据均存储多份，参见图6所示分布在task1～task5，以分片B为例，其分布在task2～task4，如果Kubernetes集群由于某种原因需要发生迁移，那么就不能同时迁移task2和task3，因为同时迁移了，B就剩一个副本在线，这时候B就不能写，只能读，因为一旦写，只有task4上的分片能更新，task2和task3都在迁移中，不能达到过半分片的一致性，就会导致数据崩溃恢复时数据不一致的错误情况。

然而，若是如果在调度时能实现细粒度管理，就可以避免同时迁移task2和task3了，可以先同时迁移task2和task5，则不会发生上述的问题。

因此，考虑到业务侧比容器集群系统的调度器更加理解业务任务的状态含义，如业务侧可以知晓业务进程在整个生命周期中，哪些状态可以迁移，何时可以重启，而不会导致出现数据不一致，逻辑缺陷等问题，而容器集群系统的调度器是无法直接感知到这些细粒度的信息，因此，本申请实施例提供给业务侧注册任务控制器的途径，当业务任务注册有任务控制器时，则Orchestrator模块会和任务控制器协调，达到细粒度的任务生命周期管理，如延迟调度、优雅重启，从而达到细粒度的调度、作业管理的效果。

本申请实施例中，在基于任务控制器进行调度之前，需要预先进行任务控制器的注册。

具体的，目标对象可以预先发起控制器注册请求，进而API Server模块可以接收到控制器注册请求，并对其进行合法性校验。其中，控制器注册请求携带了需要向容器集群系统的全局管理节点提供任务控制器的元信息，任务控制器的服务端口信息以及任务控制器能处理的服务信息等，服务端口信息例如可以包含网际互联协议(Internet Protocol)地址、端口号、域名或者远程调用方式(Remote Procedure Call，RPC)服务名称中的至少一个。

具体的，API Server模块提供了系统管理接口的能力，通过API Server模块，可以将用户提交的任务控制器注册到容器集群系统中。其中，注册的任务控制器是一种代理进程，当集群在发起业务容器迁移、重启或者下线等操作时，都会由任务控制器进程操作来感知业务需求。一个用户可以注册一个任务控制器来管理一个任务或者一批类似任务。

API Server模块在控制器注册请求校验通过时，则响应于控制器注册请求，基于控制器注册请求携带的控制器信息，执行控制器注册操作，在容器集群系统中新增任务控制器。任务控制器注册成功后，则可以基于控制器注册请求携带的目标业务任务的任务标识，将目标业务任务与任务控制器进行关联处理。

具体的，目前对象发起控制器注册请求时，可以指定与注册的任务控制器管理的目标业务任务的任务标识，这样在注册任务控制器之后，则可以将该任务控制器与目标业务任务进行关联，使得任务控制器能够获得目标业务任务的任务状态信息。

在一种可能的实施方式中，任务控制器可以包含如下接口：

(1)tryFailOver(ApplicationControllerRequest request)，其中，括号中为该接口的请求参数，调用tryFailOver用于预发起容错请求，例如迁移容器，并等待应答，如允许则进行下一步调用graceFailOver，否则当前请求失败。

(2)graceFailOver(ApplicationControllerRequest request)，调用graceFailOver用于发起容错操作。

(3)isFinished(ApplicationControllerRequest request)，调用isFinished用于确认容错操作是否已完成。

任务控制器注册完成后，则可以结合任务控制器实现任务的调度，参见图7所示，为本申请实施例提供的结合任务控制器实现任务调度的流程示意图。

步骤701：Orchestrator模块接收机器节点移除命令，机器节点移除命令指示将目标机器节点从其所属的目标容器集群中移除。

本申请实施例中，当处于某种需求，需要将容器集群中的机器节点移除时，则可以发起机器节点移除命令，来将相应机器节点从目标容器集群中下线。当然，在实际应用中，除了机器节点移除之外，还可以针对机器节点进行任务迁移、重启等操作，同样需要结合任务控制器来进行。

步骤702：Orchestrator模块响应于节点移除命令，检测到目标机器节点包括的容器资源被目标业务任务占用。

步骤703：Orchestrator模块向目标业务任务对应的任务控制器发起操作确认请求。

步骤704：任务控制器基于目标业务任务的任务状态信息，向Orchestrator模块返回操作确认响应。

本申请实施例中，由于需要移除的目标机器节点被目标业务任务占用，那么为了下线该目标机器节点，需要向该任务关联的任务控制器进行询问，是否能够执行该目标机器节点的下线。任务控制器能够更为了解当前任务的具体状态，从而可以给Orchestrator模块返回操作确认响应指示是否执行后续的操作，进而Orchestrator模块基于操作确认响应，来决定是否向目标容器集群对应的本地管理节点发送节点移除请求，使得本地管理节点响应于节点移除请求，执行针对目标机器节点的节点移除处理。

具体的，当需要下线的目标机器节点是目标业务任务的主处理节点，则将其下线可能造成任务无法正常执行，因此不能直接执行下线操作，则任务控制器可以向Orchestrator模块返回的操作确认响应可以指示需要针对目标业务任务进行节点扩容。而若是目标机器节点并非目标业务任务的主处理节点，或者满足下线的要求，则向Orchestrator模块返回的操作确认响应可以指示可进行节点移除处理。

步骤705：Orchestrator模块基于操作确认响应，向本地管理节点发起针对目标业务任务的扩容请求，并等待本地管理节点完成扩容操作。

具体的，扩容操作是指针对目标业务任务扩充容器资源，用于替代需要下线的主处理节点执行相应的任务过程。

步骤706：本地管理节点完成扩容操作时，向Orchestrator模块返回扩容完成指示。

步骤707：Orchestrator模块向任务控制器发起针对目标业务任务的主节点切换请求，以通知任务控制器已完成扩容，触发任务控制器发起主节点切换。

具体的，扩容完成后，目标业务任务新增了机器节点，但是待移除的目标机器节点仍然为该任务的主处理节点，在进行移除之前，则需要将该目标业务任务的主处理节点切换为新增的机器节点。

步骤708：当主节点切换成功时，任务控制器向Orchestrator模块返回的主节点切换成功指示。

步骤709：Orchestrator模块向本地管理节点发送节点移除请求。

步骤710：本地管理节点执行节点移除操作，关闭目标机器节点上的集群服务进程，完成移除任务命令。

参见图8a和图8b所示，结合一个具体的实施用例，来对任务控制器的实现原理进行介绍。其中，目标业务任务在容器集群系统中A、B、C三个机器节点中部署了一个分布式etcd中间件服务，其中A节点是etcd服务中的master节点，承担数据写入角色，系统部署如图8b中的初始态所示。由于容器集群系统的运营管理需要，需要将A机器节点剔除下线，按照相关技术的方案，在没有任务控制器存在时，为了下线A机器节点，Orchestrator模块会根据预定调度算法，选择一个节点，新启动一个etcd进程，然后再关闭A机器节点上etcd-master进程。此时，新启动etcd进程仍然为slave节点，在集群关闭A机器节点时，会触发etcd选主，此时etcd服务会存在一段不可用时间。

而本申请实施例中，当注册了任务控制器之后，则Orchestrator模块在T1时刻发起A机器节点的驱除下线命令，则在T2时刻，Orchestrator模块并不直接请求LRM执行驱除服务，而是先通过graceFailOver接口请求任务控制器，任务控制器发现A机器节点进程是etcd服务的master节点，直接关闭会导致etcd服务有不可用的风险，因此，在T3时刻，任务控制器会向Orchestrator模块返回需要扩容节点的信息，并在内部记录etcd服务为等待扩容状态。

Orchestrator模块在收到扩容请求后，于T4时刻向LRM发起扩容请求，并等待扩容完成；在T5时刻，扩容完成，LRM向Orchestrator模块返回扩容完成指示，此时的节点状态如图8b中扩容完成态所示，此时etcd服务存在4个节点，A节点仍然为master节点。

Orchestrator模块在T6时刻，通过isFinished接口请求任务控制器，并等待任务控制器返回结果，任务控制器在接收请求后，发起etcd优雅切主流程，即执行切主操作，此时etcd集群可能发起多轮切主操作，直到切主成功，这是因为在优雅切主的时候，需要保障新的主节点和当前主节点状态同步，然后当前的主节点写请求全部导入到新的主节点执行，实现热切换。

由于在上述过程中，主节点并没有被强制关闭，此时etcd服务仍然是可用的。在经过一轮或多轮切主操作后，与T7时刻切主成功，则任务控制器向Orchestrator模块返回切主成功指示，Orchestrator模块于T8时刻，向LRM发起关闭A机器节点上的etcd服务进程的指示，进而LRM关闭A机器节点上的etcd服务进程，完成驱除任务命令。在上述的整个过程中，通过引入了任务控制器，实现了细粒度的业务任务生命周期管理，在集群节点运维、软件更新时，能够优雅停止业务进程，从而使得集群管理器提供更高质量的服务保障。

相关技术中通常针对CPU资源、Memory资源进行检测，但是在一些场景中，例如业务任务的磁盘IO重、网络请求重在大数据计算场景中是非常常见的，在调度时不考虑网络资源和磁盘资源使用率的问题，可能使得业务任务的执行效率较低。基于此，本申请实施例中引入了Node Re-Balancer模块，通过Node Re-Balancer模块，可以持续异步检测各个机器节点的负载状态，包括但不限于针对机器节点的网络资源维度、磁盘资源维度、处理器资源维度以及内存资源维度中的至少一种进行检测，而非仅仅CPU资源、Memory资源两种资源维度，Node Re-Balancer模块可以有效判断因为网络或磁盘资源不足的原因，导致用户任务执行慢的作业，并且当发现此类型的任务，Node Re-Balancer模块可与Orchestrator模块协同，将任务调度磁盘或网络空闲的机器节点，一方面可以加速业务任务执行速度，另一方面也使得集群整体资源使用更加均衡。

参见图9所示，为本申请实施例提供的reblance过程的流程示意图。

步骤901：Node Re-Balancer模块针对目标容器资源集所在的各个机器节点，分别检测相应的负载评估值，负载评估值用于表征相应机器节点的负载高低程度。

具体的，Node Re-Balancer模块可以读取各个机器节点的负载状态数据，来针对负载状态进行评估。其中，Node Re-Balancer模块可以针对所有机器节点的负载状态进行评估，也可以是针对已部署了业务任务的机器的负载状态进行评估，这里主要是针对目标业务任务为例进行示出。

在一种可能的实施方式中，Node Re-Balancer模块可以基于各个机器节点各自对应的节点资源状态信息，分别进行多个节点资源维度的资源评估，获得各个机器节点各自对应的资源评估值集，资源评估值集中的一个资源评估值对应一个节点资源维度，进而基于获得的各个资源评估值集，分别获得各个机器节点各自对应的负载评估值。

在一种可能的实施方式中，Node Re-Balancer模块也可以针对每个资源维度分别进行负载高低的评估，当任一个资源维度出现高负载时，则可以认为该机器为高负载节点。

步骤902：Node Re-Balancer模块确认是否检测到负载评估值大于第一评估值阈值的目标机器节点，也就是Node Re-Balancer模块会持续检测是否出现高负载节点。

步骤903：若检测到高负载节点，则Node Re-Balancer模块会从多个容器集群包括的机器节点中，选择出负载评估值低于第二评估值阈值的推荐机器节点集，即选择出低负载的一个或者多个推荐机器节点。

其中，第二评估值阈值可以小于第一评估值阈值。

示例性的，目标对象提交了一个spark日志处理任务，已经分配在AB C三台机器节点上执行，此时D机器节点负载较低。Node Re-Balancer模块检测到B机器节点发生磁盘坏道，读写性能下降，则将B机器节点确定为慢IO容器节点，并选择出部分IO负载低的机器节点，例如D机器节点，作为推荐机器节点.

步骤904：Node Re-Balancer模块将高负载节点和推荐机器节点集发送给给Orchestrator模块。

步骤905：Orchestrator模块从推荐机器节点集中选取目标机器节点的替换机器节点。

步骤906：Orchestrator模块向替换机器节点对应的本地管理节点发送节点调度请求，以在替换机器节点启动新的容器。

步骤907：Orchestrator模块向目标机器节点对应的本地管理节点发送停止调度请求，以关闭原来的容器，从而通过替换机器节点执行目标机器节点对应的子任务。

本申请实施例中，通过reblance后，可以有效规避单个节点的故障或性能衰减导致的应用程序性能变差的问题，提高集群调度的容错性能。

在相关技术中，以Kubernetes为例，Kubernetes管理的集群，通常要求所有的机器节点需要部署相同版本的操作系统，节点主机系统配置也相同或类似。但是，往往调整系统环境配置是可以提升应用程序性能，相同业务负载下，可以降低资源占用，但当前Kubernetes并不支持根据应用程序来调整主机配置。

基于此，本申请实施例还引入了BCS模块，可以在整个容器集群中虚拟出一个可用Zone，不同Zone中的机器节点的系统环境配置可以不同，以满足不同业务任务对系统配置参数的不同的要求。

具体的，当资源运营规划、机房裁撤、故障容灾时触发节点切换，或者用户可以主动发起节点切换，则全局管理节点都可以接收到节点切换命令，节点切换命令用于指示将目标机器节点从第一机器节点集切换至第二机器节点集。其中，Orchestrator模块在接收到节点切换命令时，可以向BCS模块发起切换，以更改BCS模块管理的机器节点集，每个机器节点集则为一个可用Zone，同一机器节点集内的所有机器节点的节点配置参数相同。

此外，Orchestrator模块还会向目标机器节点对应的本地管理节点发送节点切换请求，指示将本地容器集群中的目标机器节点从第一机器节点集切换至第二机器节点集，以使得本地管理节点可以基于节点切换请求，基于第二机器节点集对应的节点配置参数，向目标机器节点发起配置参数更新请求，从而使得目标机器节点将自身的节点配置参数修改为节点配置参数。其中，本地管理节点包含的profiler模块会判断是否需要冲刷系统配置，以达到适配业务作业需求，达到最佳环境配置。

本申请实施例中，节点配置参数可以包括系统kernel版本、CPU Turbo Boost以及网卡配置参数等参数，当一个机器节点从一个可用Zone切换到另外一个可用Zone时，则可以通过BCS模块与profiler模块的有效协调，实现动态参数配置，使得不同任务使用不同系统配置参数，达到提升业务作业性能的有益效果。

综上所述，本申请实施例提出一种原生超大规模的集群管理方式，可以显著提升集群管理的节点规模和支持应用程序跨集群调度，提升资源共享率和利用率，并通过任务控制器提供细粒度的应用生命周期管理，且支持异构节点接入，可根据不同的应用程序特点，调整宿主机配置文件，来提升应用程序性能，降低资源消耗，进一步提升集群整体利用率，可应用至云计算领域，例如基于超大规模集群管理与任务调度技术的容器集群，可以支持上层数据分析任务、机器学习训练任务、Web在线服务调度与部署等应用。

请参见图10，基于同一发明构思，本申请实施例还提供了一种容器集群控制装置100，应用于容器集群系统包括的全局管理节点，所述容器集群系统还包括多个容器集群，以及部署于各个容器集群的本地管理节点；该装置包括：

收发单元1001，用于接收目标对象提交的任务部署请求，任务部署请求指示待部署的目标业务任务所需的容器资源数目；

资源调度单元1002，用于基于各个本地管理节点上报的本地资源状态信息，从各容器集群中，获得目标对象对应的剩余容器资源集，以及基于预设的资源选择策略，从剩余容器资源集中，选择出满足容器资源数目的目标容器资源集，目标容器资源集来源于多个容器集群中的至少一个容器集群；

资源分配单元1003，用于将目标业务任务划分为多个子任务，并分别从目标容器资源集中，为多个子任务分配相应的目标容器资源；

收发单元1001，用于基于资源分配结果，分别向至少一个容器集群各自对应的本地管理节点发送资源调度请求，以使得各本地管理节点基于接收的资源调度请求，调度相应容器集群中的目标容器资源执行相应的子任务。

在一种可能的实施方式中，资源调度单元1002，具体用于：

检测剩余容器资源集所来源的各个容器集群中，是否存在剩余容器资源的总数目不小于容器资源数目的目标容器集群；

若是，则从剩余容器资源集中目标容器集群对应的剩余容器资源中，选择出满足容器资源数目的目标容器资源集；

否则，则基于目标对象针对各个容器集群的资源偏好信息，依次从各个容器集群对应的剩余容器资源中进行资源选择，直至满足容器资源数目为止，获得目标容器资源集。

在一种可能的实施方式中，资源调度单元1002，还用于：

接收机器节点移除命令，机器节点移除命令指示将目标机器节点从其所属的目标容器集群中移除；

若响应于节点移除命令，检测到目标机器节点包括的容器资源被目标业务任务占用，向目标业务任务对应的任务控制器发起操作确认请求，并接收任务控制器基于目标业务任务的任务状态信息返回的操作确认响应；

基于操作确认响应，向目标容器集群对应的本地管理节点发送节点移除请求，使得本地管理节点响应于节点移除请求，执行针对目标机器节点的节点移除处理。

在一种可能的实施方式中，若目标机器节点为目标业务任务的主处理节点，则操作确认响应指示需要针对目标业务任务进行节点扩容；则资源调度单元1002，具体用于：

基于操作确认响应，向本地管理节点发起针对目标业务任务的扩容请求；

若接收到本地管理节点返回的扩容完成指示时，则向任务控制器发起针对目标业务任务的主节点切换请求；

若接收到任务控制器返回的主节点切换成功指示，则向本地管理节点发送节点移除请求。

在一种可能的实施方式中，该装置还包括控制器注册单元1004，用于：

响应于目标对象发送的控制器注册请求，基于控制器注册请求携带的控制器信息，执行控制器注册操作，以在容器集群系统中新增任务控制器；

基于控制器注册请求携带的目标业务任务的任务标识，将目标业务任务与任务控制器进行关联处理，使得任务控制器能够获得目标业务任务的任务状态信息。

在一种可能的实施方式中，该装置还包括负载均衡单元1005，用于：

针对目标容器资源集所在的各个机器节点，分别检测相应的负载评估值，负载评估值用于表征相应机器节点的负载高低程度；

若检测到负载评估值大于第一评估值阈值的目标机器节点，则从多个容器集群包括的机器节点中，选择出负载评估值低于第二评估值阈值的推荐机器节点集；其中，第二评估值阈值小于第一评估值阈值；

从推荐机器节点集中选取目标机器节点的替换机器节点，并向替换机器节点对应的本地管理节点发送节点调度请求，以及向目标机器节点对应的本地管理节点发送停止调度请求，以通过替换机器节点执行目标机器节点对应的子任务。

在一种可能的实施方式中，负载均衡单元1005，具体用于：

基于各个机器节点各自对应的节点资源状态信息，分别进行多个节点资源维度的资源评估，获得各个机器节点各自对应的资源评估值集，资源评估值集中的一个资源评估值对应一个节点资源维度；

基于获得的各个资源评估值集，分别获得各个机器节点各自对应的负载评估值；

其中，多个节点资源维度包括网络资源维度、磁盘资源维度、处理器资源维度以及内存资源维度中的至少一种。

在一种可能的实施方式中，该装置还包括调度器注册单元1006，用于：

响应于目标对象发送的调度器注册请求，基于调度器注册请求携带的自定义调度器信息，执行调度器注册操作，以在集群管理系统中新增自定义任务调度器；

则资源调度单元1002，用于：

若任务部署请求指定自定义任务调度器，则调用自定义任务调度器，基于资源选择策略，从剩余容器资源集中，选择出满足容器资源数目的目标容器资源集。

在一种可能的实施方式中，该装置还包括参数配置单元1007，用于：

接收节点切换命令，节点切换命令用于指示将目标机器节点从第一机器节点集切换至第二机器节点集；其中，同一机器节点集内的所有机器节点的节点配置参数相同；

向目标机器节点对应的本地管理节点发送节点切换请求，以使得本地管理节点基于节点切换请求，将目标机器节点的节点配置参数修改为第二机器节点集对应的节点配置参数。

该装置可以用于执行本申请各实施例中全局管理节点所执行的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考前述实施例的描述，不多赘述。

请参见图11，基于同一发明构思，本申请实施例还提供了一种容器集群控制装置110，应用于集群管理系统包括的本地管理节点，集群管理系统还包括全局管理节点和多个容器集群，多个容器集群各自对应配置有本地管理节点；装置包括：

状态上报单元1101，用于向全局管理节点上报本地容器集群的本地资源状态信息，本地资源状态信息指示本地容器集群的节点资源状态；

收发单元1102，用于接收全局管理节点发送的资源调度请求，资源调度请求用于指示通过本地容器集群中的目标容器资源执行目标对象提交的目标业务任务的至少一个子任务，目标容器资源是全局管理节点基于本地资源状态信息以及预设的资源选择策略，从目标对象在本地容器集群中的剩余容器资源中选择出的；

执行单元1103，用于响应于资源调度请求，通过目标容器资源启动相应的目标容器，并通过目标容器执行至少一个子任务

在一种可能的实施方式中，该装置还包括参数配置单元1104，用于：

接收全局管理节点发送的节点切换请求，节点切换请求指示将本地容器集群中的目标机器节点从第一机器节点集切换至第二机器节点集；其中，同一机器节点集内的所有机器节点的节点配置参数相同；

基于第二机器节点集对应的节点配置参数，向目标机器节点发起配置参数更新请求，以使得目标机器节点将自身的节点配置参数修改为节点配置参数。

该装置可以用于执行本申请各实施例中本地管理节点所执行的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考前述实施例的描述，不多赘述。

通过上述装置，在取得超大规模集群调度管理的同时，只存在一个控制平面，从而实现了跨集群调度，有效提升集群整体利用率，并且通过引入任务控制器，使得集群可以感知业务应用状态，实现细粒度的生命周期管理，在集群节点运维、软件更新时，能够优雅停止业务进程，提供更高的服务保障。此外，还可以持续异步检测集群节点的负载状态，当发现任务执行慢的任务，则将任务调度磁盘或网络空闲的机器节点，加速业务任务执行速度，使得集群整体资源使用更加均衡。以及，可以在整个集群中虚拟一个可用Zone，不同Zone中的机器节点的系统环境配置可以不同，以满足不同业务作业对系统配置参数的不同的要求，当一个机器节点从一个可用Zone切换到另外一个可用Zone时，则会冲刷系统配置，以达到适配业务作业需求，达到最佳环境配置，实现了动态参数配置，使得不同任务使用不同系统配置参数，达到提升业务作业性能的有益效果。

请参见图12，基于同一技术构思，本申请实施例还提供了一种计算机设备。在一种实施例中，该计算机设备可以为上述的本地管理节点或者全局管理节点，该计算机设备如图12所示，包括存储器1201，通讯模块1203以及一个或多个处理器1202。

存储器1201，用于存储处理器1202执行的计算机程序。存储器1201可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统，以及运行即时通讯功能所需的程序等；存储数据区可存储各种即时通讯信息和操作指令集等。

存储器1201可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器1201也可以是非易失性存储器(non-volatilememory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)；或者存储器1201是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器1201可以是上述存储器的组合。

处理器1202，可以包括一个或多个中央处理单元(central processing unit，CPU)或者为数字处理单元等等。处理器1202，用于调用存储器1201中存储的计算机程序时实现上述容器集群控制方法。

通讯模块1203用于与终端设备和其他服务器进行通信。

本申请实施例中不限定上述存储器1201、通讯模块1203和处理器1202之间的具体连接介质。本申请实施例在图12中以存储器1201和处理器1202之间通过总线1204连接，总线1204在图12中以粗线描述，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线1204可以分为地址总线、数据总线、控制总线等。为便于描述，图12中仅用一条粗线描述，但并不描述仅有一根总线或一种类型的总线。

存储器1201中存储有计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于实现本申请实施例的容器集群控制方法，处理器1202用于执行上述各实施例的容器集群控制方法。

基于同一发明构思，本申请实施例还提供一种存储介质，该存储介质存储有计算机程序，当该计算机程序在计算机上运行时，使得计算机执行本说明书上述描述的根据本申请各种示例性实施方式的容器集群控制方法中的步骤。

在一些可能的实施方式中，本申请提供的容器集群控制方法的各个方面还可以实现为一种计算机程序产品的形式，其包括计算机程序，当程序产品在计算机设备上运行时，计算机程序用于使计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的容器集群控制方法中的步骤，例如，计算机设备可以执行各实施例的步骤。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请的实施方式的程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括计算机程序，并可以在计算机设备上运行。然而，本申请的程序产品不限于此，在本申请件中，可读存储介质可以是任何包含或存储程序的有形介质，其包括的计算机程序可以被命令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由命令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的计算机程序，程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

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

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (16)

1.一种容器集群控制方法，其特征在于，应用于容器集群系统包括的全局管理节点，所述容器集群系统还包括多个容器集群，以及部署于各个容器集群的本地管理节点；所述方法包括：

接收目标对象提交的任务部署请求，所述任务部署请求指示待部署的目标业务任务所需的容器资源数目；

基于各个本地管理节点上报的本地资源状态信息，从所述各容器集群中，获得所述目标对象对应的剩余容器资源集，以及基于预设的资源选择策略，从所述剩余容器资源集中，选择出满足所述容器资源数目的目标容器资源集，所述目标容器资源集来源于所述多个容器集群中的至少一个容器集群；

将所述目标业务任务划分为多个子任务，并分别从所述目标容器资源集中，为所述多个子任务分配相应的目标容器资源；

基于资源分配结果，分别向所述至少一个容器集群各自对应的本地管理节点发送资源调度请求，以使得各本地管理节点基于接收的资源调度请求，调度相应容器集群中的目标容器资源执行相应的子任务。

2.如权利要求1所述的方法，其特征在于，基于预设的资源选择策略，从所述剩余容器资源集中，选择出满足所述容器资源数目的目标容器资源集，包括：

检测所述剩余容器资源集所来源的各个容器集群中，是否存在剩余容器资源的总数目不小于所述容器资源数目的目标容器集群；

若是，则从所述剩余容器资源集中所述目标容器集群对应的剩余容器资源中，选择出满足所述容器资源数目的目标容器资源集；

否则，则基于所述目标对象针对所述各个容器集群的资源偏好信息，依次从所述各个容器集群对应的剩余容器资源中进行资源选择，直至满足所述容器资源数目为止，获得所述目标容器资源集。

3.如权利要求1所述的方法，其特征在于，在基于资源分配结果，分别向所述至少一个容器集群各自对应的本地管理节点发送资源调度请求之后，所述方法还包括：

接收机器节点移除命令，所述机器节点移除命令指示将目标机器节点从其所属的目标容器集群中移除；

若响应于所述节点移除命令，检测到所述目标机器节点包括的容器资源被所述目标业务任务占用，向所述目标业务任务对应的任务控制器发起操作确认请求，并接收所述任务控制器基于所述目标业务任务的任务状态信息返回的操作确认响应；

基于所述操作确认响应，向所述目标容器集群对应的本地管理节点发送节点移除请求，使得所述本地管理节点响应于所述节点移除请求，执行针对所述目标机器节点的节点移除处理。

4.如权利要求3所述的方法，其特征在于，若所述目标机器节点为所述目标业务任务的主处理节点，则所述操作确认响应指示需要针对所述目标业务任务进行节点扩容；

则基于所述操作确认响应，向所述目标容器集群对应的本地管理节点发送节点移除请求，包括：

基于所述操作确认响应，向所述本地管理节点发起针对所述目标业务任务的扩容请求；

若接收到所述本地管理节点返回的扩容完成指示时，则向所述任务控制器发起针对所述目标业务任务的主节点切换请求；

若接收到所述任务控制器返回的主节点切换成功指示，则向所述本地管理节点发送节点移除请求。

5.如权利要求3所述的方法，其特征在于，在若响应于所述节点移除命令，检测到所述目标机器节点包括的容器资源被所述目标业务任务占用，向所述目标业务任务对应的任务控制器发起操作确认请求之前，所述方法还包括：

响应于所述目标对象发送的控制器注册请求，基于所述控制器注册请求携带的控制器信息，执行控制器注册操作，以在所述容器集群系统中新增任务控制器；

基于所述控制器注册请求携带的所述目标业务任务的任务标识，将所述目标业务任务与所述任务控制器进行关联处理，使得所述任务控制器能够获得所述目标业务任务的任务状态信息。

6.如权利要求1～5任一所述的方法，其特征在于，在基于资源分配结果，分别向所述至少一个容器集群各自对应的本地管理节点发送资源调度请求之后，所述方法还包括：

针对所述目标容器资源集所在的各个机器节点，分别检测相应的负载评估值，所述负载评估值用于表征相应机器节点的负载高低程度；

若检测到负载评估值大于第一评估值阈值的目标机器节点，则从所述多个容器集群包括的机器节点中，选择出负载评估值低于第二评估值阈值的推荐机器节点集；其中，所述第二评估值阈值小于所述第一评估值阈值；

从所述推荐机器节点集中选取所述目标机器节点的替换机器节点，并向所述替换机器节点对应的本地管理节点发送节点调度请求，以及向所述目标机器节点对应的本地管理节点发送停止调度请求，以通过所述替换机器节点执行所述目标机器节点对应的子任务。

7.如权利要求6所述的方法，其特征在于，针对所述目标容器资源集所在的各个机器节点，分别检测相应的负载评估值，包括：

基于所述各个机器节点各自对应的节点资源状态信息，分别进行多个节点资源维度的资源评估，获得所述各个机器节点各自对应的资源评估值集，所述资源评估值集中的一个资源评估值对应一个节点资源维度；

基于获得的各个资源评估值集，分别获得所述各个机器节点各自对应的负载评估值；

其中，所述多个节点资源维度包括网络资源维度、磁盘资源维度、处理器资源维度以及内存资源维度中的至少一种。

8.如权利要求1～5任一所述的方法，其特征在于，在接收目标对象提交的任务部署请求之前，所述方法还包括：

响应于所述目标对象发送的调度器注册请求，基于所述调度器注册请求携带的自定义调度器信息，执行调度器注册操作，以在所述集群管理系统中新增自定义任务调度器；

则所述基于预设的资源选择策略，从所述剩余容器资源集中，选择出满足所述容器资源数目的目标容器资源集，包括：

若所述任务部署请求指定所述自定义任务调度器，则调用所述自定义任务调度器，基于所述资源选择策略，从所述剩余容器资源集中，选择出满足所述容器资源数目的目标容器资源集。

9.如权利要求1～5任一所述的方法，其特征在于，所述方法还包括：

接收节点切换命令，所述节点切换命令用于指示将目标机器节点从第一机器节点集切换至第二机器节点集；其中，同一机器节点集内的所有机器节点的节点配置参数相同；

向所述目标机器节点对应的本地管理节点发送节点切换请求，以使得所述本地管理节点基于所述节点切换请求，将所述目标机器节点的节点配置参数修改为所述第二机器节点集对应的节点配置参数。

10.一种容器集群控制方法，其特征在于，应用于集群管理系统包括的本地管理节点，所述集群管理系统还包括全局管理节点和多个容器集群，所述多个容器集群各自对应配置有本地管理节点；所述方法包括：

向所述全局管理节点上报本地容器集群的本地资源状态信息，所述本地资源状态信息指示所述本地容器集群的节点资源状态；

接收所述全局管理节点发送的资源调度请求，所述资源调度请求用于指示通过所述本地容器集群中的目标容器资源执行目标对象提交的目标业务任务的至少一个子任务，所述目标容器资源是所述全局管理节点基于所述本地资源状态信息以及预设的资源选择策略，从所述目标对象在本地容器集群中的剩余容器资源中选择出的；

响应于所述资源调度请求，通过所述目标容器资源启动相应的目标容器，并通过所述目标容器执行所述至少一个子任务。

11.如权利要求10所述的方法，其特征在于，所述方法还包括：

接收所述全局管理节点发送的节点切换请求，所述节点切换请求指示将所述本地容器集群中的目标机器节点从第一机器节点集切换至第二机器节点集；其中，同一机器节点集内的所有机器节点的节点配置参数相同；

基于所述第二机器节点集对应的节点配置参数，向所述目标机器节点发起配置参数更新请求，以使得所述目标机器节点将自身的节点配置参数修改为所述节点配置参数。

12.一种容器集群控制装置，其特征在于，应用于容器集群系统包括的全局管理节点，所述容器集群系统还包括多个容器集群，以及部署于各个容器集群的本地管理节点；所述装置包括：

收发单元，用于接收目标对象提交的任务部署请求，所述任务部署请求指示待部署的目标业务任务所需的容器资源数目；

资源调度单元，用于基于各个本地管理节点上报的本地资源状态信息，从所述各容器集群中，获得所述目标对象对应的剩余容器资源集，以及基于预设的资源选择策略，从所述剩余容器资源集中，选择出满足所述容器资源数目的目标容器资源集，所述目标容器资源集来源于所述多个容器集群中的至少一个容器集群；

资源分配单元，用于将所述目标业务任务划分为多个子任务，并分别从所述目标容器资源集中，为所述多个子任务分配相应的目标容器资源；

所述收发单元，用于基于资源分配结果，分别向所述至少一个容器集群各自对应的本地管理节点发送资源调度请求，以使得各本地管理节点基于接收的资源调度请求，调度相应容器集群中的目标容器资源执行相应的子任务。

13.一种容器集群控制装置，其特征在于，应用于集群管理系统包括的本地管理节点，所述集群管理系统还包括全局管理节点和多个容器集群，所述多个容器集群各自对应配置有本地管理节点；所述装置包括：

状态上报单元，用于向所述全局管理节点上报本地容器集群的本地资源状态信息，所述本地资源状态信息指示所述本地容器集群的节点资源状态；

收发单元，用于接收所述全局管理节点发送的资源调度请求，所述资源调度请求用于指示通过所述本地容器集群中的目标容器资源执行目标对象提交的目标业务任务的至少一个子任务，所述目标容器资源是所述全局管理节点基于所述本地资源状态信息以及预设的资源选择策略，从所述目标对象在本地容器集群中的剩余容器资源中选择出的；

执行单元，用于响应于所述资源调度请求，通过所述目标容器资源启动相应的目标容器，并通过所述目标容器执行所述至少一个子任务。

14.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，

所述处理器执行所述计算机程序时实现权利要求1～9或者10～11任一项所述方法的步骤。

15.一种计算机存储介质，其上存储有计算机程序，其特征在于，

该计算机程序被处理器执行时实现权利要求1～9或者10～11任一项所述方法的步骤。

16.一种计算机程序产品，包括计算机程序，其特征在于，

该计算机程序被处理器执行时实现权利要求1～9或者10～11任一项所述方法的步骤。