CN112199193A - 资源调度方法、装置、电子设备和存储介质 - Google Patents

Abstract

本公开关于资源调度方法、装置、电子设备和存储介质，所述方法应用于应用容器化的容器管理平台；该容器管理平台对接多个设备集群；该方法包括：获取各个设备集群的系统资源余量；基于获取到的各个量，以及新建单个容器组件的资源需求量，确定各个设备集群支持的所述容器组件的最大新建数量；基于各个设备集群支持的所述最大新建数量，以及待新建的容器组件的总数量，确定分配给各个设备集群的与所述容器组件对应的新建任务的数量，并基于确定出的所述数量向各设备集群分配所述新建任务，以完成在所述多个设备集群中新建所述容器组件的跨集群资源调度。应用本方法，可以避免传统资源调度方案下的业务受阻问题。

Description

资源调度方法、装置、电子设备和存储介质

技术领域

本公开涉及计算机应用领域，尤其涉及资源调度方法、装置、电子设备和存储介质。

背景技术

为了满足日益丰富的互联网业务需求，人们通常采用应用容器化的手段，将承载业务程序的容器组件运行在设备集群上，并采用多集群的部署方式进一步扩展服务规模；而每当需要新建容器组件以承载新的业务程序，就可能需要进行跨集群的资源调度。

相关技术中，人们通常采用基于重试的调度策略，来为待新建的容器组件调度资源，换言之，针对待新建的容器组件，可以首先选择某个设备集群尝试新建任务，若其系统资源余量不足导致了容器组件新建失败，再另选其他设备集群并重新尝试新建任务。

但是在采用上述方案的情况下，假如容器组件新建失败，而连续多个另选的设备集群的系统资源余量均出现不足，就会导致容器组件的新建任务长时间受阻，进而影响对应业务的进行；此外，如果需要新建多个容器组件以支持某个大型业务，一旦其中一个容器组件新建失败，则整个大型业务就可能无法顺利进行，变相浪费了其他新建成功的容器组件所分配到的系统资源。

发明内容

有鉴于此，本公开提供了资源调度方法、装置、电子设备和存储介质，以至少解决相关技术中的技术问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提出了一种资源调度方法，应用于应用容器化的容器管理平台；其中，所述容器管理平台对接多个设备集群，所述设备集群用于运行承载容器化的应用的容器组件；所述方法包括：

获取各个设备集群的系统资源余量；

基于获取到的各个设备集群的系统资源余量，以及新建单个待新建的容器组件的资源需求量，确定各个设备集群支持待新建的容器组件的最大新建数量；

基于各个设备集群支持的所述最大新建数量，以及待新建的容器组件的总数量，确定分配给各个设备集群的与所述待新建的容器组件对应的新建任务的数量，并基于确定出的所述新建任务的数量，向各设备集群分配所述新建任务，以完成在所述多个设备集群中针对所述待新建的容器组件的跨集群资源调度。

可选的，所述方法还包括：

确定各个设备集群支持的所述最大新建数量的总和，是否小于所述待新建的容器组件的总数量；如果是，中止针对所述待新建的容器组件的新建任务。

可选的，所述获取各个设备集群的系统资源余量，包括：

分别从各个设备集群对应的数据缓存中，获取各个设备集群的系统资源余量。

可选的，所述设备集群包含若干资源节点；承载容器化的应用的容器组件运行在所述资源节点上；

所述分别从各个设备集群对应的数据缓存中，获取各个设备集群的系统资源余量之后，还包括：

确定所述各个设备集群包含的若干资源节点中不符合所述容器组件的创建需求的资源节点；将确定出的不符合所述容器组件的创建需求的资源节点对应的资源标记为不可用资源，以对获取到的所述系统资源余量进行修正。

可选的，所述确定分配给各个设备集群的与所述容器组件对应的新建任务的数量，包括：

基于负载均衡的策略，确定分配给各个设备集群的与所述容器组件对应的新建任务的数量，以使所述各个设备集群的资源余量保持均衡。

可选的，所述容器管理平台为基于Kubernetes设备集群架构的容器管理平台；所述设备集群为Kubernetes设备集群；所述数据缓存为采用列表-监视模式进行更新的数据缓存；所述资源节点为Kubernetes设备集群中的工作节点；所述容器组件为运行在Kubernetes设备集群中工作节点上的一个或多个容器的集合。

根据本公开实施例的第二方面，提出了一种资源调度装置，应用于应用容器化的容器管理平台；其中，所述容器管理平台对接多个设备集群，所述设备集群用于运行承载容器化的应用的容器组件；所述装置包括：

获取模块，被配置为获取各个设备集群的系统资源余量；

确定模块，被配置为基于获取到的各个设备集群的系统资源余量，以及新建单个待新建的容器组件的资源需求量，确定各个设备集群支持待新建的容器组件的最大新建数量；

调度模块，被配置为基于各个设备集群支持的所述最大新建数量，以及待新建的容器组件的总数量，确定分配给各个设备集群的与所述待新建的容器组件对应的新建任务的数量，并基于确定出的所述新建任务的数量，向各设备集群分配所述新建任务，以完成在所述多个设备集群中针对所述待新建的容器组件的跨集群资源调度。

可选的，所述装置还包括：

中止模块，被配置为确定各个设备集群支持的所述最大新建数量的总和，是否小于所述待新建的容器组件的总数量；如果是，中止针对所述待新建的容器组件的新建任务。

可选的，所述获取模块还被配置为，

分别从各个设备集群对应的数据缓存中，获取各个设备集群的系统资源余量。

可选的，所述设备集群包含若干资源节点；承载容器化的应用的容器组件运行在所述资源节点上；

所述装置还包括：

修正模块，被配置为确定所述各个设备集群包含的若干资源节点中不符合所述容器组件的创建需求的资源节点；将确定出的不符合所述容器组件的创建需求的资源节点对应的资源标记为不可用资源，以对获取到的所述系统资源余量进行修正。

可选的，所述调度模块还被配置为，

基于负载均衡的策略，确定分配给各个设备集群的与所述容器组件对应的新建任务的数量，以使所述各个设备集群的资源余量保持均衡。

可选的，所述容器管理平台为基于Kubernetes设备集群架构的容器管理平台；所述设备集群为Kubernetes设备集群；所述数据缓存为采用列表-监视模式进行更新的数据缓存；所述资源节点为Kubernetes设备集群中的工作节点；所述容器组件为运行在Kubernetes设备集群中工作节点上的一个或多个容器的集合。

根据本公开实施例的第三方面，提出了一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现上述任一实施例所述的资源调度方法。

根据本公开实施例的第四方面，提出一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述任一实施例所述的资源调度方法。

根据本公开实施例的第五方面，提出一种计算机程序产品，所述计算机程序产品被配置为执行上述任一实施例所述的资源调度方法。

以上技术方案中，一方面，由于容器管理平台预先获取了各个设备集群的系统资源余量，因此可以结合新建单个容器组件的资源需求量，得到各个设备集群支持的最大新建数量，进而保证基于该最大新建数量向各个设备集群分配新建任务时，不会出现系统资源不足导致的新建容器组件失败的情况；

另一方面，在需要新建多个容器组件的情况下，所有待新建的容器组件会基于各个设备集群支持的最大新建数量而统一调配资源，因此不会出现相关技术中，多个容器组件中只有部分容器组件新建成功的情况，从而减少了资源浪费。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书文本一同用于解释原理，并不构成对本公开的不当限定。

图1是一种多集群业务系统的架构示意图；

图2是根据本公开的实施例示出的一种资源调度方法流程图；

图3是根据本公开的实施例示出的一种对系统资源余量进行修正的示意图；

图4是根据本公开的实施例示出的一种资源调度装置的示意框图；

图5是根据本公开的实施例示出的一种电子设备的结构图。

具体实施方式

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

下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的系统和方法的例子。

在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

应用容器化通常指，将应用程序及其所需要的配置文件、包等等资源整合到容器中的过程；由于应用程序的正常运行通常依赖于特定的运行环境，而容器化后的应用则能够将上述运行环境随容器一同进行迁移、应用，因此，采用应用容器化的手段，可以显著改善开发和测试的效率，并改善可移植性和稳定性；常见的容器引擎有Docker等等。

在实际应用中，人们通常将承载业务程序的容器组件运行在设备集群上，并采取Kubernetes(又称K8s)、Mesosphere、Openshift等工具对运行有容器组件的设备集群进行管理。而在单个设备集群无法满足业务需求的情况下，则可以采用多集群的部署方式，以进一步扩展服务规模。

请参见图1，图1为本公开示出的一种应用容器化场景下的多集群业务系统的架构示意图；如图1所示，该多集群业务系统包括多个设备集群，以及与上述多个设备集群相对接的容器管理平台；其中，设备集群可以用于运行承载有业务程序的容器组件，而与之对接的容器管理平台可以用于管理上述容器组件，并按需对上述设备集群的系统资源进行调度。

在上述环境下，每当需要新建容器组件以承载新的业务程序，就可能需要进行跨集群的资源调度。

相关技术中，人们通常采用基于重试的调度策略，来为待新建的容器组件调度资源；具体而言，该方案针对待新建的容器组件，可以首先选择某个设备集群尝试新建任务，若被选择的设备集群的系统资源余量不足，导致了容器组件新建失败，则可以另选其他设备集群并重新尝试新建任务。

但在采用上述方案的情况下，假若多个设备集群的系统资源余量均出现不足的情况，那么容器组件新建失败后另选设备集群时，很可能选到系统资源余量不足的设备集群，于是需要再次另选设备集群，有可能陷入长时间的重试循环，导致容器组件的新建任务长时间受阻，进而影响对应业务的进行；

此外，如果需要新建多个容器组件以支持某个大型业务，一旦其中一个容器组件新建失败，则整个大型业务就可能无法顺利进行，变相浪费了其他新建成功的容器组件所分配到的系统资源；

例如，某项业务需要20个容器组件协同工作，在调度系统资源时，前19个容器组件都被成功创建，但第20个容器组件则因为系统资源不足而创建失败，在这种情况下，尽管前19个容器组件创建成功，但由于整个业务缺少第20个容器组件无法顺利进行，因此前19个容器组件所消耗的系统资源无法产生预期的收益，这部分系统资源便被浪费了。

基于此，本公开提出一种在多集群应用容器化的场景下，预先获取各个设备集群的资源余量，并根据资源余量的多少对各个设备集群分配对应待新建容器组件的新建任务，以进行跨集群资源调度的技术方案。

在实现时，可以首先基于新建单个待新建的容器组件的资源需求量，以及获取到的各个设备集群的资源余量，确定出各个设备集群分别能够支持待新建的容器组件的最大新建数量；再基于各个设备集群的最大新建数量，和待新建容器组件的总数量，最终确定分配到各个设备集群的针对上述待新建的容器组件的新建任务数量，从而根据上述新建任务的数量向各个设备集群分配上述新建任务，从而完成跨集群的资源调度。

在以上技术方案中，一方面，由于容器管理平台预先获取了各个设备集群的系统资源余量，因此可以结合新建单个待新建的容器组件的资源需求量，得到各个设备集群支持的最大新建数量，进而保证基于该最大新建数量向各个设备集群分配新建任务时，不会出现相关技术中，多个集群的系统资源均不足导致的新建容器组件受阻的情况；

另一方面，在需要新建多个容器组件的情况下，所有待新建的容器组件均会基于各个设备集群支持的最大新建数量而统一调配资源，因此不会出现相关技术中，多个容器组件中只有部分容器组件新建成功的情况，从而避免了相关技术中产生的资源浪费。

下面通过具体实施例并结合具体的应用场景对技术方案进行描述。

请参考图2，图2是本公开一实施例提供的一种资源调度方法的流程图，该方法应用于应用容器化的容器管理平台；其中，所述容器管理平台对接多个设备集群，所述设备集群用于运行承载容器化的应用的容器组件；该方法执行以下步骤：

S201，获取各个设备集群的系统资源余量；

S202，基于获取到的各个设备集群的系统资源余量，以及新建单个待新建的容器组件的资源需求量，确定各个设备集群支持待新建的容器组件的最大新建数量；

S203，基于各个设备集群支持的所述最大新建数量，以及待新建的容器组件的总数量，确定分配给各个设备集群的与所述待新建的容器组件对应的新建任务的数量，并基于确定出的所述新建任务的数量，向各设备集群分配所述新建任务，以完成在所述多个设备集群中针对所述待新建的容器组件的跨集群资源调度。

上述设备集群，可以是包括多个对外提供业务功能的节点设备的设备集群；可以理解的是，为了实现更加丰富的功能，或者取得性能/稳定性的优势，设备集群中也可以包含其他不直接提供业务功能的设备节点；例如，在Kubernetes设备集群中，除了用于承载上述容器组件的工作节点(又称Node节点)之外，还有用于对Node进行管理并控制外部数据访问的管理节点(又称Master节点)。本领域技术人员可以根据具体需求自行选择所使用的设备集群类型。

上述容器组件，可以包括运行在上述设备集群上、能够作为资源调度的单元，并对容器化的应用起到承载作用的组件；在具体实现上述技术方案时，视设备集群的不同，上述容器组件也可以有不同的实现形式；例如，在普通Docker环境下，上述容器组件可以是容器本身；又例如，在Kubernetes设备集群中，上述容器组件可以是Pod；Pod是Kubernetes中的最小可部署单元，每个Pod中可以包含一个或者多个容器，并可以共享存储和/或网络资源；也就是说，针对Pod的调度，也可以视为是对其包含的一个或者多个容器的组合的调度。

上述容器管理平台，可以包括任意与各个设备集群相对接，并能够对各个设备集群中运行的容器组件进行管理的服务器；其具体实现形式可以是单台专用的服务器，或者是服务器集群，也可以是提供上述功能的虚拟服务器或者软件，对此本领域技术人员可以根据具体需求，自行选择实现方式，本公开无需进行详细限定。

上述系统资源，可以包括上述容器组件所需要使用的任意资源；具体而言，上述系统资源可以包括CPU、GPU算力等计算资源，也可以包括RAM、硬盘等存储资源，还可以包括网络带宽通信资源、供电资源、散热资源等等，本领域技术人员在应用上述技术方案时，可以根据具体需求来确定系统资源的具体种类；

举例而言，业务甲是AI计算业务，其容器组件的运行需要大量的GPU算力以及显存资源，业务乙是文件服务器业务，其容器组件的运行需要较多的网络带宽资源，等等；本领域技术人员可以根据业务特性的不同，进一步自行调整各种资源的取舍或者权重，本公开无需进行限定。

在本示例中，上述容器管理平台可以获取与之对接的各个设备集群的系统资源余量；上述资源余量可以包括上述设备集群所能够用于新建容器组件的系统资源的可用量，例如内存剩余容量，空闲的CPU核数等，其可以通过可用量表示，也可以通过总量和不可用量间接表示，例如“总带宽1Gbps，已使用800Mbps”的表达，亦当视为间接体现了网络带宽这一系统资源余量。

可以理解的是，上述获取动作可以是该容器管理平台对与之对接的各个设备集群发起主动查询，也可以是该容器管理平台被动接收来自与之对接的各个设备集群的上报信息；具体采用的通信机制本公开无需进行限定，本领域技术人员可以根据具体需求自行确定并完成对应开发设计。

在实际应用中，上述获取各个设备集群的系统资源余量的过程中，如果某一设备集群响应缓慢，则可能使得上述容器管理平台进行较长时间的等待，不利于资源调度的快速响应。

在一实施例中，上述与容器管理平台对接的各个设备集群均可以对应配置有数据缓存，用于记录系统资源余量；对应地，上述容器管理平台，可以从各个设备集群对应的数据缓存中，获取与之对接的各个设备集群的系统资源余量；采用此方案，由于上述容器管理平台可以从上述数据缓存中直接获取到各个设备集群的系统资源余量，通常不会受设备集群自身响应缓慢的影响，因此可以减少容器管理平台在获取各个设备集群的系统资源余量时等待的时间。

在实际应用中，系统资源余量的获取与更新，通常有全量更新与增量更新两种方式，全量更新通常更加可靠，但对计算和传输资源有较高的消耗，难以及时更新；增量更新通常更为高效，实时性较佳，但可靠性则不及全量更新。

进一步地，若上述设备集群为Kubernetes集群，则上述数据缓存可以是采用List-Watch模式进行更新的数据缓存；采用此种方案，由于List-Watch模式下，数据缓存通过list获取全量数据，通过watch监听增量数据，因此不仅能够保证汇报系统资源余量的消息的可靠性和实时性，相对于轮询全量数据等解决方案，还能减少性能的浪费。

可以理解的是，上述设备集群所对应的数据缓存，可以由上述设备集群，或者上述容器管理平台内的程序代码实现，也可以由分别与设备集群和容器管理平台相连接的某台中间设备实现；例如，上述数据缓存可以通过一台专用的数据监控服务器实现，该数据监控服务器可以获取对应的设备集群的系统资源余量，并向上述容器管理平台开放对应的查询接口，以使上述容器管理平台可以从中获取到各个设备集群的系统资源余量。因此，本领域技术人员可以自行选择具体的软硬件实现方式，本公开对于上述数据缓存的形式无需进行严格限定。

在一实施例中，上述设备集群可以包含若干资源节点；承载容器化的应用的容器组件运行在上述资源节点上；其中，资源节点可以是提供上述系统资源的节点，具体可以是单台服务器构成的物理节点，也可以是逻辑上划分出的虚拟节点，或者由多台服务器组成的小型集群节点，等等；若继续以Kubernetes设备集群为例，其中的资源节点即可以是能够运行Pod的Node节点。

可以理解的是，不同的资源节点可以提供不同系统资源，以适应不同类型的容器组件；例如，某个资源节点上具有性能较强的GPU卡，可以提供较高的浮点算力，那么可能比较适合运行承载有模型训练类的应用的容器组件，又例如某个资源节点上具有高性能企业级硬盘，可以提供较高的IO吞吐量，那么可能比较适合运行承载有资源网站类的应用的容器组件。

亦可以理解的是，如果上述资源节点中，有部分资源节点实际上不符合某些待新建容器组件的需求，导致该部分资源节点的系统资源余量无法用于新建上述待新建的容器组件，就可能导致实际可用的系统资源余量，小于上述获取到的系统资源余量，可能造成资源调度的失败。

因此在此种情况下，上述容器管理平台，可以进一步根据容器组件的创建需求，对上述获取到的各个设备集群的系统资源余量进行修正；具体而言，可以首先确定出各个设备集群包含的若干资源节点中，不符合上述容器组件的创建需求的资源节点，并将确定出的不符合上述容器组件的创建需求的资源节点对应的资源标记为不可用资源，从而对上述系统资源余量进行修正；

例如，某待新建的容器组件的创建需求包括，资源节点必须具有3.0Ghz以上主频的CPU，那么可以从所有的资源节点中，确定出不具有3.0Ghz以上主频的CPU的资源节点，并将与其对应的CPU算力、内存、硬盘等各种资源均标记为不可用资源，从而确保上述系统资源余量中，不包含上述不符合创建需求的资源节点对应的资源。

请参见图3，图3是根据本公开的实施例示出的一种对系统资源余量进行修正的示意图；其中，包含n个设备集群，每个设备集群中均可以由若干资源节点，且均对应搭载有数据缓存；对于任意一个设备集群而言，其系统资源余量均会首先被提取到对应的数据缓存内，并经过数据修正后进行数据汇总；最终数据汇总得到的，即为针对待新建的容器组件的新建需求进行修正后的所有设备集群的系统资源余量。

继续以Kubernetes设备集群为例，在Kubernetes的规范中，可以为Node添加标签Label，从而便于在为Pod分配Node时根据Label的内容进行筛选；例如，某节点没有配置固态硬盘，其硬盘Label的值被设置为No-SSD，那么就可能被某些对于SSD有需求的Pod认为是不可用节点；此外，Kubernetes还支持Taint污点和Toleration容忍机制，为Pod分配Node时，会避开具有Taint的Node，除非该Pod具有与该Taint相匹配的Toleration字段；应用上述手段，可以在Kubernetes环境下高效筛选不符合容器组件的新建需求的资源节点，如果迁移到其他环境下，也可以应用类似的机制，完成上述任务。

采用此种方案，由于不符合容器组件的新建需求的资源节点，事实上不会参与上述容器组件的新建，因此修正后的系统资源余量，会更贴近该容器组件新建时实际可用的系统资源，进而可以使得后续过程中基于该系统资源余量做出的计算更加精确，做出的资源调度更加合理。

在本示例中，上述容器管理平台可以进一步基于上述步骤获取到的各个设备集群的系统资源余量，结合新建单个待新建的容器组件的资源需求量，综合确定对于上述各个设备集群而言，能够支持该待新建的容器组件的最大新建数量；

举例而言，假设上述系统资源仅考虑内存空间，设备集群A的系统资源余量，也就是剩余内存空间为8100MB，设备集群B的剩余内存空间为7900MB，而每一个当前需要新建的容器组件在新建时都需要800MB内存空间，那么通过整除计算的方法，可以得到设备集群A的最大新建数量为10，而设备集群B的最大新建数量为9。

可以理解的是，正如前文所述，应用本技术方案时可以参与计算的系统资源种类无需限定，因而也可以综合内存容量、CPU负载、IO吞吐量等多种系统资源，确定各个设备集群所能够支持该待新建的容器组件的最大新建数量；

例如，考虑内存空间以及网络带宽两种系统资源种类，每一个当前需要新建的容器组件在新建时都需要800MB内存空间，以及20Mbps的网络带宽，对于一个剩余内存空间为8100MB，闲置网络带宽为1000Mbps的设备集群而言，即使该设备集群闲置的网络带宽还能够支持50个该容器组件，但由于剩余内存空间仅能够支持10个该容器组件，那么该设备集群支持该待新建的容器组件的最大新建数量便只能是10，而不是50。

此外，由于实际应用中，多个容器组件所消耗的系统资源可能并不是纯粹的线性叠加关系；例如，部分系统资源可以在多个容器组件之间进行复用，那么对系统资源的实际消耗量会比直接求和结果要少，这会导致设备集群实际能够支持的容器组件的最大新建数量，大于整除得到的预期值；又例如，部分系统资源需要设置一定的冗余量，那么对系统资源的实际消耗量会比直接求和结果要大，这会导致设备集群实际能够支持的容器组件的最大新建数量，小于整除得到的预期值；

因此，具体确定各个设备集群所能够支持该容器组件的最大新建数量的方式，也不局限于整除计算一种途径，而是可以结合具体实施环境，确定具体的计算方式，对此本领域技术人员可以参照相关技术文献完成设计，本公开不作进一步限定。

在实际应用中，可能会出现上述容器管理平台对接的各个设备集群的资源余量，均不足以完成后续的、对应于待新建容器组件的新建任务，在这种情况下，其中一个容器组件的新建失败，就有可能导致其他新建成功的容器组件所分配到的系统资源被浪费。

在一实施例中，上述容器管理平台可以计算各个设备集群支持的所述最大新建数量的总和，并进一步确定该总和是否小于待新建的容器组件的总数量；如果确定小于，则可以中止上述新建任务。可以理解的是，上述对新建任务的中止的实现方式，可以是对新建任务暂时挂起，也可以是直接取消该新建任务，本领域技术人员可以自行设计相关细节，本公开不作进一步限定。

采用该方案，如果剩余的系统资源不足以支持全部的待新建的容器组件完成新建，就会导致对应的新建任务被中止，因而在前述例子的场景下，需要新建的容器组件有多个时，可以避免由于其中一个容器组件的新建失败，而导致其他新建成功的容器组件所分配到的系统资源被浪费的情况。

在本示例中，上述容器管理平台可以进一步基于上述步骤确定出的各个设备集群支持的最大新建数量，以及待新建的容器组件的总数量，确定分配给各个设备集群的、与待新建的容器组件相对应的新建任务的数量；在该过程中，只需保证各个设备集群分配到的新建任务的数量，不超出其最大新建数量，即可保证对应该容器组件的新建任务下发后，不会由于设备集群的系统资源余量不足而执行失败；具体可以根据需要选择具体的分配策略，例如基于优先级的分配策略，可以设定优先使用某些设备集群，或尽量避免使用某些设备集群；或者，采用基于平均分配的策略，将待新建的容器组件的新建任务尽可能平均分配给有足够系统资源余量的设备集群，等等。

在实际应用中，不同的设备集群可能会因为负载的不均衡而导致老化程度不一，如果部分设备集群负载过高，就可能导致设备提前老化，最终导致业务受阻。

在一实施例中，上述分配策略可以是基于负载均衡的策略，从而使得与容器管理平台对接的各个设备集群的资源余量保持均衡；采用基于负载均衡的策略，可以使得各个设备集群的负载都趋于均衡，因此可以避免部分设备集群负载过高导致的设备老化、业务受阻等情况。

可以理解的是，负载均衡的分配策略也可能导致所有设备集群的资源余量少而平均，进而会出现整个多集群系统的资源余量总和能够满足新建某些大型容器组件的系统资源需求，但由于每一个设备集群都无法直接提供足够多的系统资源而新建失败的情况；例如，由三个设备集群组成的多集群系统中，在负载均衡的调整下，每个设备集群都空闲8个CPU核心，整个多集群系统共24个CPU核心处于可用状态，若新建某容器组件需要一个设备集群上的16个CPU核心协同工作，则每一个设备集群都无法完成此次新建任务，必须进行进一步的跨集群资源调度，以令其中某设备集群给出16个可用CPU核心；但如果彼时采用的不是负载均衡的策略，则有可能某一设备集群上已然存在多于16个可用CPU核心，该新建任务能够顺利完成，无需进行进一步的跨集群资源调度。

因此，上述分配策略的具体选择，可以根据业务的具体需求，以及各种分配策略自身的特性而定，本公开无需进行进一步限定。

在本示例中，上述容器管理平台可以进一步基于上述步骤确定出的、分配给各个设备集群的新建任务的数量，向上述各个设备集群对应分配新建任务；具体而言，在分配给各个设备集群的新建任务的数量确定之后，容器管理平台即可向各个设备集群按照对应的数量分配新建任务，任务下发的方式可以视具体应用场景而定，本公开无需进行具体限定。由于待新建的容器组件被分配到了多个设备集群上进行新建，因而也就完成了一次针对上述待新建的容器组件的跨集群的资源调度。

在一实施例中，上述容器管理平台可以为基于Kubernetes设备集群架构的容器管理平台，与其对接的设备集群可以为Kubernetes设备集群，上述数据缓存可以为采用列表-监视模式(又称List-Watch模式)进行更新的数据缓存；上述资源节点可以为Kubernetes设备集群包含的工作节点node；上述容器组件可以为运行在Kubernetes设备集群包含的工作节点node上的、可以视作一个或者多个容器的集合的pod；各设计分别取得的技术效果已经在其他实施例中进行过描述，在此不再赘述；可以理解的是，本公开所提供的该资源调度方法，也可以应用于基于其他架构的容器管理平台，Kubernetes中的应用仅为便于描述的一示例，并不能限制本公开。

上述内容即为本公开针对所述资源调度方法的全部实施例。本公开还提供了对应的资源调度装置的实施例如下：

请参见图4，图4根据本公开的实施例示出的一种资源调度装置的示意框图；该装置应用于应用容器化的容器管理平台；其中，所述容器管理平台对接多个设备集群，所述设备集群用于运行承载容器化的应用的容器组件；该装置包括：

获取模块401，被配置为获取各个设备集群的系统资源余量；

确定模块402，被配置为基于获取到的各个设备集群的系统资源余量，以及新建单个待新建的容器组件的资源需求量，确定各个设备集群支持待新建的容器组件的最大新建数量；

调度模块403，被配置为基于各个设备集群支持的所述最大新建数量，以及待新建的容器组件的总数量，确定分配给各个设备集群的与所述待新建的容器组件对应的新建任务的数量，并基于确定出的所述新建任务的数量，向各设备集群分配所述新建任务，以完成在所述多个设备集群中针对所述待新建的容器组件的跨集群资源调度。

在本示例中，上述获取模块401可以被配置为获取与之对接的各个设备集群的系统资源余量；具体既是该容器管理平台对与之对接的各个设备集群发起主动查询，也可以是该容器管理平台被动接收来自与之对接的各个设备集群的上报信息。

在一实施例中，上述与容器管理平台对接的各个设备集群均可以对应配置有数据缓存，用于记录系统资源余量；对应地，上述获取模块401，可以被配置为从各个设备集群对应的数据缓存中，获取与之对接的各个设备集群的系统资源余量；采用此方案，可以减少容器管理平台在获取各个设备集群的系统资源余量时等待的时间。

在一实施例中，上述设备集群可以包含若干资源节点；承载容器化的应用的容器组件运行在上述资源节点上；上述装置还可以包括修正模块，被配置为根据容器组件的创建需求，对上述获取到的各个设备集群的系统资源余量进行修正；具体而言，可以首先确定出各个设备集群包含的若干资源节点中，不符合上述容器组件的创建需求的资源节点，并将确定出的不符合上述容器组件的创建需求的资源节点对应的资源标记为不可用资源，从而对上述系统资源余量进行修正。

采用此种方案，修正后的系统资源余量，会更贴近该容器组件新建时实际可用的系统资源，进而可以使得后续过程中基于该系统资源余量做出的计算更加精确，做出的资源调度更加合理。

在本示例中，上述确定模块402可以被配置为基于上述步骤获取到的各个设备集群的系统资源余量，结合新建单个待新建的容器组件的资源需求量，综合确定对于上述各个设备集群而言，能够支持该待新建的容器组件的最大新建数量。

在一实施例中，上述装置还可以包括中止模块，该模块可以被配置为计算各个设备集群支持的所述最大新建数量的总和，并进一步确定该总和是否小于待新建的容器组件的总数量；如果确定小于，则可以中止上述新建任务。应用本方案，当需要新建的容器组件有多个时，可以避免由于其中一个容器组件的新建失败，而导致其他新建成功的容器组件所分配到的系统资源被浪费的情况。

在本示例中，调度模块403在确定分配给各个设备集群的、与待新建的容器组件相对应的新建任务的数量的过程中，只需保证各个设备集群分配到的新建任务的数量，不超出其最大新建数量，即可保证对应该容器组件的新建任务下发后，不会由于设备集群的系统资源余量不足而执行失败。

在一实施例中，上述分配策略可以是基于负载均衡的策略，从而使得与容器管理平台对接的各个设备集群的资源余量保持均衡。采用基于负载均衡的策略，可以避免部分设备集群负载过高导致的设备老化、业务受阻等情况。

在一实施例中，上述容器管理平台可以为基于Kubernetes设备集群架构的容器管理平台，与其对接的设备集群可以为Kubernetes设备集群，上述数据缓存可以为采用列表-监视模式(又称List-Watch模式)进行更新的数据缓存；上述资源节点可以为Kubernetes设备集群包含的工作节点node；上述容器组件可以为运行在Kubernetes设备集群包含的工作节点node上的、可以视作一个或者多个容器的集合的pod；可以理解的是，本公开所提供的该资源调度方法，也可以应用于基于其他架构的容器管理平台，Kubernetes中的应用仅为便于描述的一示例，并不能限制本公开。

在本示例中，上述调度模块403还可以被配置为，进一步基于上述步骤确定出的、分配给各个设备集群的新建任务的数量，向各个设备集群按照对应的数量分配新建任务；由于待新建的容器组件被分配到了多个设备集群上进行新建，因而也就完成了一次针对上述待新建的容器组件的跨集群的资源调度。

关于上述实施例中的装置，其中各模块的具体实现方式，已经在描述对应方法的实施例中进行了详细描述，此处将不做详细阐述说明。

本公开的实施例还提出一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如上述任一实施例所述的资源调度方法。

本公开的实施例还提出一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述任一实施例所述的资源调度方法。

本公开的实施例还提出一种计算机程序产品，所述计算机程序产品被配置为执行上述任一实施例所述的资源调度方法。

图5是根据本公开的实施例示出的一种电子设备的示意框图。参照图5，电子设备500可以包括以下一个或多个组件：处理组件502，存储器504，电源组件506，多媒体组件508，音频组件510，输入/输出(I/O)的接口512，传感器组件514，以及通信组件518。

处理组件502通常控制电子设备500的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件502可以包括一个或多个处理器520来执行指令，以完成上述资源调度方法的全部或部分步骤。此外，处理组件502可以包括一个或多个模块，便于处理组件502和其他组件之间的交互。例如，处理组件502可以包括多媒体模块，以方便多媒体组件508和处理组件502之间的交互。

存储器504被配置为存储各种类型的数据以支持在电子设备500的操作。这些数据的示例包括用于在电子设备500上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器504可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件506为电子设备500的各种组件提供电力。电源组件506可以包括电源管理系统，一个或多个电源，及其他与为电子设备500生成、管理和分配电力相关联的组件。

多媒体组件508包括在电子设备500和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件508包括一个前置摄像头和/或后置摄像头。当电子设备500处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件510被配置为输出和/或输入音频信号。例如，音频组件510包括一个麦克风(MIC)，当电子设备500处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器504或经由通信组件518发送。在一些实施例中，音频组件510还包括一个扬声器，用于输出音频信号。

I/O接口512为处理组件502和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件514包括一个或多个传感器，用于为电子设备500提供各个方面的状态评估。例如，传感器组件514可以检测到电子设备500的打开/关闭状态，组件的相对定位，例如所述组件为电子设备500的显示器和小键盘，传感器组件514还可以检测电子设备500或电子设备500一个组件的位置改变，用户与电子设备500接触的存在或不存在，电子设备500方位或加速/减速和电子设备500的温度变化。传感器组件514可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件514还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件514还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件518被配置为便于电子设备500和其他设备之间有线或无线方式的通信。电子设备500可以接入基于通信标准的无线网络，如WiFi，运营商网络(如2G、3G、4G或5G)，或它们的组合。在一个示例性实施例中，通信组件518经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件518还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在本公开一实施例中，电子设备500可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述资源调度方法。

在本公开一实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器504，上述指令可由电子设备500的处理器520执行以完成上述资源调度方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

需要说明的是，在本公开中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本公开实施例所提供的方法和装置进行了详细介绍，本文中应用了具体个例对本公开的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本公开的方法及其核心思想；同时，对于本领域的一般技术人员，依据本公开的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本公开的限制。

Claims (10)

1.一种资源调度方法，应用于应用容器化的容器管理平台；其中，所述容器管理平台对接多个设备集群，所述设备集群用于运行承载容器化的应用的容器组件；所述方法包括：

获取各个设备集群的系统资源余量；

基于获取到的各个设备集群的系统资源余量，以及新建单个待新建的容器组件的资源需求量，确定各个设备集群支持待新建的容器组件的最大新建数量；

基于各个设备集群支持的所述最大新建数量，以及待新建的容器组件的总数量，确定分配给各个设备集群的与所述待新建的容器组件对应的新建任务的数量，并基于确定出的所述新建任务的数量，向各设备集群分配所述新建任务，以完成在所述多个设备集群中针对所述待新建的容器组件的跨集群资源调度。

2.根据权利要求1所述的方法，所述方法还包括：

确定各个设备集群支持的所述最大新建数量的总和，是否小于所述待新建的容器组件的总数量；如果是，中止针对所述待新建的容器组件的新建任务。

3.根据权利要求1所述的方法，所述获取各个设备集群的系统资源余量，包括：

分别从各个设备集群对应的数据缓存中，获取各个设备集群的系统资源余量。

4.根据权利要求3所述的方法，所述设备集群包含若干资源节点；承载容器化的应用的容器组件运行在所述资源节点上；

所述分别从各个设备集群对应的数据缓存中，获取各个设备集群的系统资源余量之后，还包括：

确定所述各个设备集群包含的若干资源节点中不符合所述容器组件的创建需求的资源节点；将确定出的不符合所述容器组件的创建需求的资源节点对应的资源标记为不可用资源，以对获取到的所述系统资源余量进行修正。

5.根据权利要求1所述的方法，

所述确定分配给各个设备集群的与所述容器组件对应的新建任务的数量，包括：

基于负载均衡的策略，确定分配给各个设备集群的与所述容器组件对应的新建任务的数量，以使所述各个设备集群的资源余量保持均衡。

6.根据权利要求4所述的方法，

所述容器管理平台为基于Kubernetes设备集群架构的容器管理平台；所述设备集群为Kubernetes设备集群；所述数据缓存为采用列表-监视模式进行更新的数据缓存；所述资源节点为Kubernetes设备集群中的工作节点；所述容器组件为运行在Kubernetes设备集群中工作节点上的一个或多个容器的集合。

7.一种资源调度装置，应用于应用容器化的容器管理平台；其中，所述容器管理平台对接多个设备集群，所述设备集群用于运行承载容器化的应用的容器组件；所述装置包括：

获取模块，被配置为获取各个设备集群的系统资源余量；

确定模块，被配置为基于获取到的各个设备集群的系统资源余量，以及新建单个待新建的容器组件的资源需求量，确定各个设备集群支持待新建的容器组件的最大新建数量；

调度模块，被配置为基于各个设备集群支持的所述最大新建数量，以及待新建的容器组件的总数量，确定分配给各个设备集群的与所述待新建的容器组件对应的新建任务的数量，并基于确定出的所述新建任务的数量，向各设备集群分配所述新建任务，以完成在所述多个设备集群中针对所述待新建的容器组件的跨集群资源调度。

8.一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1～6中任一项所述的资源调度方法。

9.一种计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如权利要求1～6中任一项所述的资源调度方法。

10.一种计算机程序产品，所述计算机程序产品被配置为执行如权利要求1～6中任一项所述的资源调度方法。

Images