CN114598665A

CN114598665A - 资源调度方法、装置和计算机可读存储介质及电子设备

Info

Publication number: CN114598665A
Application number: CN202210062506.XA
Authority: CN
Inventors: 吴坤安; 周彧; 洪丽萍
Original assignee: Ruijie Networks Co Ltd
Current assignee: Ruijie Networks Co Ltd
Priority date: 2022-01-19
Filing date: 2022-01-19
Publication date: 2022-06-07

Abstract

本申请公开了一种集群中的资源调度方法、装置和计算机可读存储介质及电子设备。该方法包括：获取服务列表，其中，所述服务列表为所述集群中至少一个目标节点上运行的服务列表；根据所述服务列表对所述集群中除所述至少一个目标节点之外的其他节点执行过滤处理，以获得满足所述服务列表的服务要求的候选节点列表；将所述候选节点列表中具有满足预定资源要求的资源的节点确定为调度目的节点；将所述服务列表中的服务调度到所述调度目的节点。本申请实施例避免了出现申请资源较多的服务运行在剩余资源不充足的节点和资源碎片化的情形，降低了服务容器因为系统内存不足被强行杀死的几率，并且通过根据其他节点的服务资源需求确定调度目的节点的预留资源，避免了调度目的节点预留过多资源，提高了资源利用率。

Description

资源调度方法、装置和计算机可读存储介质及电子设备

技术领域

本申请涉及通信领域，尤其涉及一种集群中的资源调度方法、装置和计算机可读存储介质及电子设备。

背景技术

随着网络技术的发展，人们已经可以在日常的生活和工作中使用基于网络的云服务技术。特别是虚拟桌面技术的发展，使得人们可以使用基于云服务器的虚拟桌面来进行工作，从而用户只需要使用能够访问网络的各种终端就可以随时随地使用同一个桌面来进行工作，大大提高了工作的便利性和效率。但是由于这样的虚拟桌面需要通过云服务器来进行配置和管理，这对于不具有专业知识的普通用户来说带来了一定的使用上的困难。

在现有技术中，超融合基础架构(Hyper Converged Infrastructure，或简称“HCI”)和容器虚拟化技术(Docker技术)的提出，使得基于互联网的数据方面的容量扩展性、可用性、高性能以及管理方面的高可用性和易部署特点大大降低了桌面虚拟化平台的管理难度，减少了平台的维护成本，为政府、企业、医院的办公和中小学以及高校教育的云桌面管理人员和使用人员带来更多便利。

在现有的桌面虚拟化平台技术中，虽然超融合技术提供了计算资源、存储资源、网络资源等资源，容器虚拟化技术则负责托管计算、存储、网络等管理服务，使其具有了高可用性。但是，通常情况下，桌面虚拟化平台所使用的物理资源(CPU、Memory)可以根据使用类别分为几个部分：操作系统使用的资源、云桌面使用的资源(虚拟机)、托管服务使用的资源和托管服务预留资源，其中，托管服务预留资源用于保障宕机节点的托管服务在迁移到当前节点后能够恢复运行，从而保障节点宕机时服务的持续可用以及服务故障恢复的功能。容器技术具有轻量级、标准化和秒级启动的特点，那么就需要在桌面虚拟化平台中预留足够多的资源给托管服务可以保障托管服务的持续可用性，但是这样的方案会大大减少预留给云桌面的资源，导致可运行的云桌面数量减少，不能够满足云桌面业务场景的需求。

因此，需要在同等配置计算机中有效地利用节点资源以及合理的为托管服务预留资源，使得在保障托管服务可用性的同时，增加云桌面的运行数量。

发明内容

本申请实施例提供一种集群中的资源调度方法、装置和计算机可读存储介质及电子设备，以解决现有技术中节点资源缺乏有效调度的缺陷。

为达到上述目的，本申请实施例提供了一种集群中的资源调度方法，其中，所述集群包括多个节点，并且所述方法包括：

获取服务列表，其中，所述服务列表为所述集群中至少一个目标节点上运行的服务列表；

根据所述服务列表对所述集群中除所述至少一个目标节点之外的其他节点执行过滤处理，以获得满足所述服务列表的服务要求的候选节点列表；

将所述候选节点列表中具有满足预定资源要求的资源的节点确定为调度目的节点，其中，所述调度目的节点预留有下述资源：所述调度目的节点运行其自己的服务的资源与所述候选节点列表中预定数目的节点上的服务需要的资源之和；

将所述服务列表中的服务调度到所述调度目的节点。

本申请实施例还提供了一种集群中的资源调度装置，其中，所述集群包括多个节点，并且所述装置包括：

获取模块，用于获取服务列表，其中，所述服务列表为所述集群中至少一个目标节点上运行的服务列表；

过滤模块，用于根据所述服务列表对所述集群中除所述至少一个目标节点之外的其他节点执行过滤处理，以获得满足所述服务列表的服务要求的候选节点列表；

确定模块，用于将所述候选节点列表中具有满足预定资源要求的资源的节点确定为调度目的节点，其中，所述调度目的节点预留有下述资源：所述调度目的节点运行其自己的服务的资源与所述候选节点列表中预定数目的节点上的服务需要的资源之和；

调度模块，用于将所述服务列表中的服务调度到所述调度目的节点。

本申请实施例还提供了一种计算机可读存储介质，其上存储有可被处理器执行的计算机程序，其中，所述程序被处理器执行时实现如本申请实施例提供的集群中的资源调度方法。

本申请实施例还提供了一种电子设备，包括：

存储器，用于存储程序；

处理器，用于运行所述存储器中存储的所述程序，以执行如本申请实施例提供的集群中的资源调度方法。

本申请实施例提供的集群中的资源调度方法、装置和计算机可读存储介质及电子设备，通过获取服务列表，根据服务列表对集群中节点执行过滤处理，以获得满足所述服务列表的服务要求的候选节点列表，确定候选节点列表中具有满足预定资源要求的资源的调度目的节点，并将服务列表中的服务调度到所述调度目的节点，因此，通过根据集群中节点上运行的服务以及节点的资源来确定满足资源要求的调度目的节点，从而将服务调度到该节点上，避免了出现申请资源较多的服务运行在剩余资源不充足的节点和资源碎片化的情形，降低了服务容器因为系统内存不足被强行杀死的几率，并且通过根据其他节点的服务资源需求确定调度目的节点的预留资源，避免了调度目的节点预留过多资源，提高了资源利用率。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本申请实施例提供的集群中的资源调度方案的应用场景示意图；

图2为本申请提供的集群中的资源调度方法一个实施例的流程图；

图3为本申请提供的集群中的资源调度装置一个实施例的结构示意图；

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

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本申请实施例提供的方案可应用于任何具有资源调度能力的设备或系统等等。图1为本申请实施例提供的集群中的资源调度方案的应用场景示意图，图1所示的场景仅仅是本申请的技术方案可以应用的场景的示例之一。

超融合基础架构通过分布式存储技术将各个计算节点(Hypervisor)的存储资源整合为一个统一的存储资源池，给虚拟化平台提供存储服务，实现计算、存储、网络、虚拟化的统一管理和资源的横向扩展，保障用户业务的高可用。而容器虚拟化技术是在操作系统层上创建一个个容器，这些容器共享下层的操作系统内核和硬件资源，但是每个容器可单独限制CPU、内存、硬盘和网络带宽容量，并且拥有单独的IP地址和操作系统管理员账户，每个容器可以关闭和重启并且容器之间互不影响。与虚拟机相比，容器里不用再安装操作系统，因此减少了因操作系统浪费的计算资源，增加了计算机服务的租户数量。

但是，在现有的桌面虚拟化平台技术中，虽然超融合技术提供了计算资源、存储资源、网络资源等资源，容器虚拟化技术则负责托管计算、存储、网络等管理服务，使其具有了高可用性。但是，通常情况下，桌面虚拟化平台所使用的物理资源(CPU、Memory)可以根据使用类别分为几个部分：操作系统使用的资源、云桌面使用的资源(虚拟机)、托管服务使用的资源和托管服务预留资源，其中，托管服务预留资源用于保障宕机节点的托管服务在迁移到当前节点后能够恢复运行，从而保障节点宕机时服务的持续可用以及服务故障恢复的功能。容器技术具有轻量级、标准化和秒级启动的特点，那么就需要在桌面虚拟化平台中预留足够多的资源给托管服务可以保障托管服务的持续可用性，但是这样的方案会大大减少预留给云桌面的资源，导致可运行的云桌面数量减少，不能够满足云桌面业务场景的需求。

现有技术中也提出了在主备模式中，通过主节点对外提供服务时备用节点用于同步主机的数据且不对外提供服务。此时备用节点运行着和主节点一样的服务，当主节点出现故障或主节点内的服务出现故障时，备用节点的服务开始对外提供服务，即备用节点用于运行服务的资源是预留的资源。但是该方案的缺点是预留的资源值较高，主备模式的预留值是2倍，主备备的预留值是3倍，从而在该方案中，随着集群内备用节点个数和服务数量的增加，预留的资源值也增加。

此外，在现有容器技术的调度器基础上还提供大容器适配的资源预留算法。现有容器技术的调度器：根据接收到的服务列表随机调度，导致在节点宕机前桌面虚拟化平台无法预知调度服务的顺序。为了解决在服务列表无序的前提下大容器适配的问题，该方案提供大容器适配的资源预留算法。但是该方案的缺点是当各托管服务资源需求相差很大时，例如当一个托管需要的内存为128MB，另一个托管服务需要的内存为6GB时，预留的资源值较高，在3节点环境中大约是2.6倍。因此节点的资源利用率较低，随着集群内节点个数、服务数量越多，预留的资源值越高，集群的资源利用率越低。

对此，本申请实施例中，在如图1中所示的场景中，集群中可以设置有5个节点，即节点1至节点5，并且有9个服务分别运行在这五个节点上。例如，服务6和服务9可以运行在节点1上，服务8可以运行在节点2上，服务7可以运行在节点3上，服务1和3可以运行在节点4上，并且服务2、服务4和服务5可以运行在节点5上。并且服务1-9各自需要的资源也不尽相同。例如，服务1可以要求使用2GB的内存，服务2可以要求使用1GB的内存空间，服务3可以要求使用2.5GB的内存空间，服务4可以要求使用1GB的内存空间，服务5可以要求使用1.5GB的内存空间，服务6可以要求使用3GB的内存空间，服务7可以要求使用4.5GB的内存空间，服务8可以要求使用4GB的内存空间，并且服务9可以要求使用3.5GB的内存空间。

在该集群中，可以假设桌面虚拟化平台支持的宕机节点数为2，即当在该集群中出现两个节点宕机时，集群可以及时将该两个节点上运行的服务调度到合适的节点继续运行。

因此，在本申请实施例中，可以例如以图1中所示的节点2作为示例来说明根据本申请的资源调度方法，即在该该集群中出现2个节点宕机时，节点2需要预留出多少资源以便于能够将宕机节点的服务调度到该节点2上运行。

例如，可以基于节点2之外剩余的其他节点作为目标节点来按照该集群支持的宕机节点数组合出宕机节点，例如可以得到多个宕机节点组合，并根据以下步骤计算出针对这些宕机节点组合的节点2的预留资源，即节点2需要预留出多少资源以便于确保在出现宕机时可以将服务调度到节点2上。

可以针对每个宕机节点组合根据以下步骤执行，直到上述获得的多个宕机节点组合遍历完成。

例如，可以在根据本申请的资源调度装置获取宕机节点，例如节点4和5上运行的服务列表服务1至服务5。并且在获取到该服务列表时，可以根据存控制条件对服务列表进行排序并输出排序后的服务列表，例如服务3、服务1、服务5、服务2和服务4。

之后可以将该排序后的服务列表中的服务，例如服务3和集群内的除了上述宕机节点之外的剩余节点，例如节点1至节点3的列表进行过滤处理，例如可以通过过滤器进行过滤处理。

例如，在本申请实施例中，可以使用Constraints限制过滤器，用于校验服务是否有限制要求；可以使用Affinity亲和性过滤器，用于校验服务的关联性；还可以使用Dependency依赖过滤器，用于校验服务与服务之间的依赖性；可以使用Health健康过滤器，用于校验节点的健康状况；可以使用Port端口过滤器，用于校验节点的端口是否占用，从而可以获得满足服务的资源要求的节点列表，例如节点1至节点3。

之后，可以对于获得的满足服务要求的节点列表进一步进行挑选以选择例如剩余资源最多的节点，例如节点2。在本申请实施例中，可以使用各种策略来挑选适合的节点。例如，Random随机策略对容器运行没有限制要求，换言之，根据该策略可以在节点列表中随机选择一个节点。Spread扩散策略要求容器均匀分布在各个节点，因此在使用该策略时可以在节点列表选择剩余资源最多的节点启动容器，从而保证集群中所有节点资源的均匀使用。Binpack装箱策略要求容器尽可能分布在一个节点，因此，可以在节点列表中选择运行容器数量最多的节点启动容器，从而可以提高该节点的资源使用率。在本申请实施例中，可以使用Spread扩散策略，以从节点列表中选取剩余资源对多的节点，例如节点2。因此，可以最终将服务调度至该节点2来执行。

此外，在本申请实施例中为节点2确定需要为运行宕机节点的服务预留的资源为针对各宕机节点组合获得的该组合中的宕机节点上的服务中需要调度到节点2的服务所需的资源之和。并且因此可以在获得的所有预留资源值中取最大值，保证节点2预留的资源支持宕机任意2个节点。

因此，节点2需要的资源为：本节点运行服务的资源值+排序后的服务列表中调度给节点2的服务资源值。例如，可以使用下面的公式来计算节点2的预留资源。

resource＝current+max(reserved_resource1，reserved_resourceN)

其中：current表示节点2自身上运行的服务所需资源总和，N表示集群中节点数A、支持的宕机节点数B已知的前提下(0<B<1/2A，即B小于A的半数)，宕机节点(B个节点)组合成宕机节点列表的种类，并且reserved_resourceN是第N种宕机节点组合时，根据调度规则将宕机节点运行的服务调度至最优节点，得到本节点需要运行的服务列表，从而获得服务列表申请的资源总和。

图2为本申请提供的集群中的资源调度方法一个实施例的流程图。如图2所示，该集群中的资源调度方法可以包括如下步骤：

S201，获取服务列表。

在本申请实施例中，可以从应用有本申请实施例中的资源调度方法的集群来获取服务列表，该服务列表可以为集群中至少一个目标节点上运行的服务列表。例如，如图1中所示，在该集群中可以设置有5个节点，并且9个服务可以分别运行在这5个节点上。

因此，例如，可以在步骤S201中获取例如被设定为目标节点的节点4和5上运行的服务列表，即服务1至服务5。

此外，在步骤S201中，在获取到该服务列表时，还可以根据各种预置条件对服务列表进行排序并输出排序后的服务列表，例如服务3、服务1、服务5、服务2和服务4。

S202，根据服务列表对集群中除至少一个目标节点之外的其他节点执行过滤处理，以获得满足服务列表的服务要求的候选节点列表。

在步骤S202中，可以将步骤S201中获得的服务列表中的服务和集群中除了目标节点4和5之外的其他节点，例如节点1至节点3进行过滤处理，以获得满足步骤S201中获得的目标节点的服务列表的候选节点列表。特别地，在步骤S201中对获得的服务列表中的服务进行排序的情况下，也可以在步骤S202中将该排序后的服务列表中的服务，例如服务3和集群内的除了目标节点(节点4和节点5)之外的剩余节点，例如节点1至节点3的列表进行过滤处理，例如可以通过过滤器进行过滤处理。

S203，将候选节点列表中具有满足预定资源要求的资源的节点确定为调度目的节点。

在步骤S203中可以对于步骤S202中获得的满足服务要求的候选节点列表进一步进行挑选以选择例如剩余资源最多的节点，例如节点2作为满足预定资源要求的调度目的节点。

例如，在本申请实施例中，可以使用各种策略来挑选适合的节点。例如，Random随机策略对容器运行没有限制要求，换言之，根据该策略可以在节点列表中随机选择一个节点。Spread扩散策略要求容器均匀分布在各个节点，因此在使用该策略时可以在节点列表选择剩余资源最多的节点启动容器，从而保证集群中所有节点资源的均匀使用。Binpack装箱策略要求容器尽可能分布在一个节点，因此，可以在候选节点列表中选择运行容器数量最多的节点作为调度目的节点，从而可以提高该节点的资源使用率。在本申请实施例中，可以使用Spread扩散策略，以从节点列表中选取剩余资源最多的节点，例如节点2。

S204，将服务列表中的服务调度到调度目的节点。

因此，可以在步骤S204中将步骤S201中获取到的服务调度至步骤S203中确定的节点2来执行。

resource＝current+max(reserved_resource1，reserved_resourceN)

本申请实施例提供的集群中的资源调度方法，通过获取服务列表，根据服务列表对集群中节点执行过滤处理，以获得满足所述服务列表的服务要求的候选节点列表，确定候选节点列表中具有满足预定资源要求的资源的调度目的节点，并将服务列表中的服务调度到所述调度目的节点，因此，通过根据集群中节点上运行的服务以及节点的资源来确定满足资源要求的调度目的节点，从而将服务调度到该节点上，避免了出现申请资源较多的服务运行在剩余资源不充足的节点和资源碎片化的情形，降低了服务容器因为系统内存不足被强行杀死的几率，并且通过根据其他节点的服务资源需求确定调度目的节点的预留资源，避免了调度目的节点预留过多资源，提高了资源利用率。

图3为本申请提供的集群中的资源调度装置一个实施例的结构示意图，可用于执行如图2所示的方法步骤。如图3所示，该集群中的资源调度装置可以包括：获取模块31、过滤模块32、确定模块33和调度模块34。

获取模块31可以用于获取服务列表。

在本申请实施例中，获取模块31可以从应用有本申请实施例中的资源调度方法的集群来获取服务列表，该服务列表可以为集群中至少一个目标节点上运行的服务列表。例如，如图1中所示，在该集群中可以设置有5个节点，并且9个服务可以分别运行在这5个节点上。

因此，例如，获取模块31可以获取例如被设定为目标节点的节点4和5上运行的服务列表，即服务1至服务5。

此外，获取模块31在获取到该服务列表时，还可以根据各种预置条件对服务列表进行排序并输出排序后的服务列表，例如服务3、服务1、服务5、服务2和服务4。

过滤模块32可以用于根据服务列表对集群中除至少一个目标节点之外的其他节点执行过滤处理，以获得满足服务列表的服务要求的候选节点列表。

过滤模块32可以将获取模块31获得的服务列表中的服务和集群中除了目标节点4和5之外的其他节点，例如节点1至节点3进行过滤处理，以获得满足获取模块31获得的目标节点的服务列表的候选节点列表。特别地，在获取模块31对获得的服务列表中的服务进行排序的情况下，过滤模块32可以将该排序后的服务列表中的服务，例如服务3和集群内的除了目标节点(节点4和节点5)之外的剩余节点，例如节点1至节点3的列表进行过滤处理，例如可以通过过滤器进行过滤处理。

例如，在本申请实施例中，过滤模块32可以使用Constraints限制过滤器，用于校验服务是否有限制要求；可以使用Affinity亲和性过滤器，用于校验服务的关联性；还可以使用Dependency依赖过滤器，用于校验服务与服务之间的依赖性；可以使用Health健康过滤器，用于校验节点的健康状况；可以使用Port端口过滤器，用于校验节点的端口是否占用，从而可以获得满足服务的资源要求的节点列表，例如节点1至节点3。

确定模块33可以用于将候选节点列表中具有满足预定资源要求的资源的节点确定为调度目的节点。

确定模块33可以对于过滤模块32获得的满足服务要求的候选节点列表进一步进行挑选以选择例如剩余资源最多的节点，例如节点2作为满足预定资源要求的调度目的节点。

调度模块34可以用于将服务列表中的服务调度到调度目的节点。

因此，调度模块34可以将获取模块31获取到的服务调度至确定模块33确定的节点2来执行。

resource＝current+max(reserved_resource1，reserved_resourrceN)

本申请实施例提供的集群中的资源调度装置，通过获取服务列表，根据服务列表对集群中节点执行过滤处理，以获得满足所述服务列表的服务要求的候选节点列表，确定候选节点列表中具有满足预定资源要求的资源的调度目的节点，并将服务列表中的服务调度到所述调度目的节点，因此，通过根据集群中节点上运行的服务以及节点的资源来确定满足资源要求的调度目的节点，从而将服务调度到该节点上，避免了出现申请资源较多的服务运行在剩余资源不充足的节点和资源碎片化的情形，降低了服务容器因为系统内存不足被强行杀死的几率，并且通过根据其他节点的服务资源需求确定调度目的节点的预留资源，避免了调度目的节点预留过多资源，提高了资源利用率。

以上描述了集群中的资源调度装置的内部功能和结构，该装置可实现为一种电子设备。图4为本申请提供的电子设备实施例的结构示意图。如图4所示，该电子设备包括存储器41和处理器42。

存储器41，用于存储程序。除上述程序之外，存储器41还可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

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

处理器42，不仅仅局限于中央处理器(CPU)，还可能为图形处理器(GPU)、现场可编辑门阵列(FPGA)、嵌入式神经网络处理器(NPU)或人工智能(AI)芯片等处理芯片。处理器42，与存储器41耦合，执行存储器41所存储的程序，该程序运行时执行上述实施例的集群中的资源调度方法。

进一步，如图4所示，电子设备还可以包括：通信组件43、电源组件44、音频组件45、显示器46等其它组件。图4中仅示意性给出部分组件，并不意味着电子设备只包括图4所示组件。

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

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

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

显示器46包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

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

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

Claims

1.一种集群中的资源调度方法，其中，所述集群包括多个节点，其特征在于，所述方法包括：

将所述服务列表中的服务调度到所述调度目的节点。

2.根据权利要求1所述的集群中的资源调度方法，其特征在于，所述资源调度方法进一步包括：

从所述至少一个目标节点中生成至少一组目标节点，并且

所述确定所述候选节点列表中具有满足预定资源要求的资源的调度目的节点包括：

从所述候选节点列表中的候选节点中选择剩余资源最多的节点作为调度目的候选节点；

根据所述调度目的候选节点自己运行所需的资源和所述至少一组目标节点确定所述调度目的候选节点具有满足所述预定资源要求的资源，并且

所述将所述候选节点列表中具有满足预定资源要求的资源的节点确定为调度目的节点包括：

将所述具有满足所述预定资源要求的资源的调度目的候选节点确定为调度目的节点。

3.根据权利要求2所述的集群中的资源调度方法，其特征在于，所述资源调度方法进一步包括：

根据所述集群中的节点总数、所述至少一个目标节点的数量以及所述至少一个目标节点的节点标识确定第一服务列表；

对所述第一服务列表中的服务进行排序；

以预定顺序将所述第一服务列表中的服务依次分配给所述集群中消耗资源最小的节点，以确定所述待调度资源。

4.根据权利要求3所述的集群中的资源调度方法，其特征在于，所述对所述第一服务列表中的服务进行排序包括：

使用服务限制使用的处理器或内存作为权重值来对所述服务进行排序。

5.根据权利要求1所述的集群中的资源调度方法，其特征在于，所述根据所述服务列表对所述集群中除所述至少一个目标节点之外的其他节点执行过滤处理包括下述过滤处理中的至少一种或多种的组合：

根据服务对操作系统类型、内核版本、存储类型的要求进行过滤；

根据服务对所述其他节点上的标签要求进行过滤；

根据服务的关联性进行过滤；

根据服务与服务之间的依赖性进行过滤；

根据所述其他节点的健康状况进行过滤；

根据所述其他节点的端口使用情况进行过滤。

6.根据权利要求5所述的集群中的资源调度方法，其特征在于，所述根据服务的关联性进行过滤包括：

选择运行了指定容器或具有指定镜像的节点作为候选节点。

7.根据权利要求5所述的集群中的资源调度方法，其特征在于，所述根据服务与服务之间的依赖性进行过滤包括：

选择具有关联性服务的容器所运行的节点作为候选节点。

8.根据权利要求1所述的集群中的资源调度方法，其特征在于，所述预定数目的节点上的服务需要的资源是根据如下方式确定的：

确定所述集群中宕机节点的宕机组合的列表；

针对所述宕机组合的列表中的每一个宕机组合，确定需要调度到所述调度目的节点的服务所需资源；

对针对所有宕机组合对应的所述服务所需资源进行排序，并将其中最大值作为所述预定数目节点上的服务所需的资源。

9.一种集群中的资源调度装置，其中，所述集群包括多个节点，其特征在于，所述装置包括：

10.一种计算机可读存储介质，其上存储有可被处理器执行的计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1至8中任一所述的集群中的资源调度方法。

11.一种电子设备，其特征在于，包括：

存储器，用于存储程序；

处理器，用于运行所述存储器中存储的所述程序，以执行如权利要求1至8中任一所述的集群中的资源调度方法。