1.本技术涉及边缘计算技术领域，尤其涉及一种资源调度的方法、装置及电子设备。
背景技术：2.随着边缘计算技术的发展，可以将应用放到边缘计算服务器来处理。进一步的，目前通常采用容器集群技术来管理边缘服务器上的应用，即将应用作为任务封装到容器中，再将容器调度到集群中的节点来执行，以完成对边缘服务器上应用的处理。
3.但在实际应用中上述边缘计算服务器的资源具有局限性，即边缘计算服务器在面对需要一次性处理的大量时延敏感的一次性任务时，往往受其资源局限性而无法按时处理所有的一次性任务。更为详细的，对集群中的节点来讲，单个节点会受到其节点资源限制，而无法及时处理大量容器中的时延敏感的一次性任务，进而导致这些时延敏感的一次性任务存在时延大的问题。
4.鉴于此，当前缺乏一种适用于边缘计算场景的资源调度方法，来解决处理大量时延敏感的一次性任务存在的时延大的问题。
技术实现要素：5.本技术提供一种资源调度的方法、装置及电子设备，用以对海量人像数据进行资源调度。
6.第一方面，本技术提供了一种资源调度的方法，所述方法包括：
7.响应于为每个待调度容器确定一个目标节点，得到m个待调度容器各自对应的目标节点；其中，m为大于0的整数，一个目标节点对应至少一个待调度容器；
8.判断各个目标节点的当前可用资源是否能够处理所述各个目标节点对应的单个或多个待调度容器；
9.若否，则从所述单个或多个待调度容器中确定至少一个待调度容器作为再调度容器；
10.响应于未触发终止条件时，重新为每个再调度容器确定一个目标节点。
11.基于上述方法，通过容器和节点对彼此之间的评分来建立匹配关系实现资源调度，使得资源的使用更加合理化，进而提高资源的利用率，缓解边缘计算环境下存在大量超负荷的时延敏感的一次性任务无法及时处理的情况。
12.在一种可能的设计中，所述触发终止条件，包括：所述各个目标节点的当前可用资源能够执行所述各个目标节点对应的m个待调度容器；或存在至少一个所述再调度容器，并且集群中的各个节点的当前可用资源都无法执行至少一个所述再调度容器。
13.基于上述设计，设置触发终止条件的判定条件，若触发终止条件可以认定当前的所有待调度容器都成为相应目标节点的匹配容器，或当前的待调度容器已经遍历过集群中的各个节点也没有成为任一节点的匹配容器。在这种情况下，可以认定继续循环资源调度的过程是没有意义的，因此可以停止资源调度的过程，并将各个匹配容器调度至各个匹配
容器各自对应的目标节点执行。
14.在一种可能的设计中，所述为每个待调度容器确定一个目标节点，包括：计算单个待调度容器调度至单个节点执行的节点综合评分，得到所述每个待调度容器调度至多个节点执行的多个节点综合评分；其中，一个节点综合评分对应一个节点；从所述多个节点综合评分中选取最大节点综合评分对应的节点作为所述每个待调度容器对应的目标节点。
15.基于上述设计，对于每个待调度容器来说，会计算得到n个节点综合评分，然后，从n个节点综合评分中选取最大节点综合评分对应的节点作为相应待调度容器对应的目标节点。
16.在一种可能的设计中，所述计算单个待调度容器调度至单个节点执行的节点综合评分，包括：计算第一系数与所述单个节点的cpu核数之间的第一乘积；其中，所述第一系数基于所述单个待调度容器的cpu核数确定；计算第二系数与所述单个节点的内存需求之间的第二乘积；其中，所述第二系数基于所述单个待调度容器的内存需求确定；基于所述第一乘积、所述第二乘积以及所述单个节点的网络速率，计算所述单个待调度容器调度至所述单个节点执行的节点性能评分；确定在所述单个待调度容器调度至所述单个节点执行后，所述单个节点的cpu空闲率、内存空闲率以及网络空闲率；基于所述单个节点的cpu空闲率、内存空闲率以及网络空闲率，计算所述单个待调度容器调度至所述单个节点执行的节点负载评分；对所述节点性能评分以及所述节点负载评分进行加权求和，得到所述单个待调度容器调度至所述单个节点执行的节点综合评分。
17.基于上述设计，在计算节点综合评分时考虑待调度容器对节点的cpu资源以及内存资源的不同需求偏重，还考虑待调度容器对节点的cpu资源以及网络资源的基本需求。
18.在一种可能的设计中，在判断各个目标节点的当前可用资源是否能够处理所述各个目标节点对应的单个或多个待调度容器之后，还包括：若是，则将所述m个待调度容器作为所述同一目标节点对应的m个匹配容器；响应于触发所述终止条件，在将各个匹配容器调度至所述各个匹配容器各自对应的目标节点执行。
19.基于上述设计，匹配各个目标节点将与相应的单个或多个待调度容器，至此，将与目标节点建立起这种匹配关系的待调度容器，作为目标节点对应的匹配容器。
20.在一种可能的设计中，所述从所述单个或多个待调度容器中确定至少一个待调度容器作为再调度容器，包括：计算单个目标节点执行单个待调度容器的容器综合评分，得到所述各个目标节点各自执行所述单个或多个待调度容器的单个或多个容器综合评分；基于所述单个或多个容器综合评分按照数值大小进行排序，得到所述单个或多个待调度容器的优先级排序；基于所述优先级排序，依次添加待调度容器至所述各个目标节点上执行，直到所述各个目标节点的当前可用资源无法执行下一个待调度容器；将所述各个目标节点的当前可用资源无法执行的待调度容器作为再调度容器。
21.基于上述设计，提出一种目标节点对各个待调度容器进行容器综合评分的机制，基于该机制可以确定出再调度容器。
22.在一种可能的设计中，所述计算单个目标节点执行单个待调度容器的容器综合评分，包括：确定所述目标节点执行所述单个待调度容器的实际执行时间以及所述单个待调度容器的预设执行时间；对所述实际执行时间以及所述预设执行时间作对数计算，得到时间维度的第一评分指数；对所述实际执行时间以及所述目标节点执行所述单个待调度容器
的单位资源成本系数作乘积运算，得到资源维度的第二评分指数；计算所述单个待调度容器对应的执行资源代价与所述实际执行时间之间的比值，得到代价维度的第三评价指数；基于所述第一评分指数、所述第二评分指数以及所述第三评分指数，得到所述单个目标节点执行所述单个待调度容器的容器综合评分。
23.基于上述设计，提出一种结合时间维度、资源维度以及代价维度计算容器综合评分的计算方法。基于此，对于当前可用资源不足以执行对应的所有待调度容器的目标节点而言，可以将容器综合评分高的作为优先考虑的待调度容器，通过这种方式淘汰部分待调度容器，并将这些待调度容器作为再调度容器。
24.第二方面，本技术提供了一种资源调度的装置，所述装置包括：
25.第一确定模块，响应于为每个待调度容器确定一个目标节点，得到m个待调度容器各自对应的目标节点；其中，m为大于0的整数，一个目标节点至少对应一个待调度容器；
26.判断模块，判断各个目标节点的当前可用资源是否能够处理所述各个目标节点对应的单个或多个待调度容器；
27.第二确定模块，若各个目标节点的当前可用资源无法执行所述各个目标节点对应的单个或多个待调度容器，则从所述单个或多个待调度容器中确定至少一个待调度容器作为再调度容器；
28.第三确定模块，在未触发终止条件时，重新为每个再调度容器确定一个目标节点，直到触发所述终止条件。
29.在一种可能的设计中，所述触发终止条件，所述第三确定模块，具体用于：所述各个目标节点的当前可用资源能够执行所述各个目标节点对应的m个待调度容器；或存在至少一个所述再调度容器，并且集群中的各个节点的当前可用资源都无法执行至少一个所述再调度容器。
30.在一种可能的设计中，所述为每个待调度容器确定一个目标节点，所述第一确定模块，具体用于：计算单个待调度容器调度至单个节点执行的节点综合评分，得到所述每个待调度容器调度至多个节点执行的多个节点综合评分；其中，一个节点综合评分对应一个节点；从所述多个节点综合评分中选取最大节点综合评分对应的节点作为所述每个待调度容器对应的目标节点。
31.在一种可能的设计中，所述计算单个待调度容器调度至单个节点执行的节点综合评分，所述第一确定模块，具体用于：计算第一系数与所述单个节点的cpu核数之间的第一乘积；其中，所述第一系数基于所述单个待调度容器的cpu核数确定；计算第二系数与所述单个节点的内存需求之间的第二乘积；其中，所述第二系数基于所述单个待调度容器的内存需求确定；基于所述第一乘积、所述第二乘积以及所述单个节点的网络速率，计算所述单个待调度容器调度至所述单个节点执行的节点性能评分；确定在所述单个待调度容器调度至所述单个节点执行后，所述单个节点的cpu空闲率、内存空闲率以及网络空闲率；基于所述单个节点的cpu空闲率、内存空闲率以及网络空闲率，计算所述单个待调度容器调度至所述单个节点执行的节点负载评分；对所述节点性能评分以及所述节点负载评分进行加权求和，得到所述单个待调度容器调度至所述单个节点执行的节点综合评分。
32.在一种可能的设计中，在判断各个目标节点的当前可用资源是否能够处理所述各个目标节点对应的单个或多个待调度容器之后，所述装置，还用于：若是，则将所述m个待调
度容器作为所述同一目标节点对应的m个匹配容器；响应于触发所述终止条件，在将各个匹配容器调度至所述各个匹配容器各自对应的目标节点执行。
33.在一种可能的设计中，所述从所述单个或多个待调度容器中确定至少一个待调度容器作为再调度容器，所述第二确定模块，具体用于：计算单个目标节点执行单个待调度容器的容器综合评分，得到所述各个目标节点各自执行所述单个或多个待调度容器的单个或多个容器综合评分；基于所述单个或多个容器综合评分按照数值大小进行排序，得到所述单个或多个待调度容器的优先级排序；基于所述优先级排序，依次添加待调度容器至所述各个目标节点上执行，直到所述各个目标节点的当前可用资源无法执行下一个待调度容器；将所述各个目标节点的当前可用资源无法执行的待调度容器作为再调度容器。
34.在一种可能的设计中，所述计算单个目标节点执行单个待调度容器的容器综合评分，所述第二确定模块，具体用于：确定所述目标节点执行所述单个待调度容器的实际执行时间以及所述单个待调度容器的预设执行时间；对所述实际执行时间以及所述预设执行时间作对数计算，得到时间维度的第一评分指数；对所述实际执行时间以及所述目标节点执行所述单个待调度容器的单位资源成本系数作乘积运算，得到资源维度的第二评分指数；计算所述单个待调度容器对应的执行资源代价与所述实际执行时间之间的比值，得到代价维度的第三评价指数；基于所述第一评分指数、所述第二评分指数以及所述第三评分指数，得到所述单个目标节点执行所述单个待调度容器的容器综合评分。
35.第三方面，本技术提供了一种电子设备，所述电子设备包括：
36.存储器，用于存放计算机程序；
37.处理器，用于执行所述存储器上所存放的计算机程序时，实现上述的一种资源调度的方法步骤。
38.第四方面，本技术提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述的一种资源调度的方法步骤。
39.上述第二方面至第四方面中的各个方面以及各个方面可能达到的技术效果请参照上述针对第一方面或第一方面中的各种可能方案可以达到的技术效果说明，这里不再重复赘述。
附图说明
40.图1为本技术提供的一种可能的应用场景的结构图；
41.图2为本技术提供的一种资源调度的方法的流程图；
42.图3为本技术提供的一种资源调度的装置的示意图；
43.图4为本技术提供的一种电子设备的结构的示意图。
具体实施方式
44.为了使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术作进一步地详细描述。方法实施例中的具体操作方法也可以应用于装置实施例或系统实施例、以及计算机程序产品中。
45.在本技术的描述中“多个”理解为“至少两个”。“和/或”，描述关联对象的关联关
系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。a与b连接，可以表示：a与b直接连接和a与b通过c连接这两种情况。另外，在本技术的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。
46.本技术实施例提供的方案涉及容器集群技术。具体的，本技术实施例应用于调度器，尤其是集群调度器。
47.详细来说，获取m个待调度容器以及n个节点，基于每个待调度容器对n个节点各自的综合节点评分，确定出每个待调度容器各自对应的一个目标节点，最终得到m个待调度容器各自对应的目标节点，在这里，一个待调度容器唯一对应一个目标节点，而一个目标节点至少对应一个待调度容器。然后，判断各个目标节点的当前可用资源是否能够执行其对应的所有待调度容器，若判定为否，则从其对应的所有待调度容器中确定出至少一个待调度容器作为再调度容器。若未触发终止条件，则重新为每个再调度容器确定一个目标节点，直到触发终止条件，则可以视为完成对这m个待调度容器的资源调度工作。
48.此外，若判断各个目标节点的当前可用资源能够执行其对应的所有待调度容器，则将各个目标节点各自对应的所有待调度容器作为各自的匹配容器，然后，响应于触发终止条件，执行在各个目标节点上执行其各自对应的匹配容器。
49.下面对本技术实施例的设计思想进行简要介绍。
50.目前，随着边缘计算的发展与应用，通常采用kubernetes容器集群技术管理和保障边缘服务器上的应用，在采用kubernetes容器集群技术管理如监控图像处理、语音分析等的一次性任务时，由于边缘环境下计算资源有限，往往无法及时处理这些一次性任务。进一步的，随着一次性任务对于执行实现要求的提高，其具有越来越高的时延敏感性，将这些时延敏感的任务置于边缘环境下处理将导致处理时延变大。基于此，当前亟需一种资源调度的方式解决上述问题。
51.以kubernetes容器集群技术为例，kubernetes调度器的默认调度方法分为predicates阶段和priority阶段。predicates阶段的工作是节点初筛，priority阶段从predicates阶段初筛的节点中进行挑选并确定调度的目标节点。发明人经过创造性劳动发现，现有kubernetes容器调度算法无法解决边缘计算环境下大量超负荷的时延敏感的一次性任务。
52.鉴于此，本技术实施例提供一种资源调度方法，在该方法中，从容器角度：单个待调度容器会想被预调度至其对应的目标节点执行，即单个待调度容器对应的目标节点为最高节点综合评分对应的节点，节点综合评分由节点性能评分以及节点负载评分加权求和得到。具体的，节点性能评分基于待调度容器的cpu核数、待调度容器的内存需求、节点的cpu核数、节点的内存需求、节点的网络速率、节点的cpu频率得到；节点负载评分基于节点的cpu空闲率、内存空闲率以及网络空闲率得到。
53.从容器角度，通过每个待调度容器对各个节点评分，可以确定出每个待调度节点的目标节点，即待调度节点放置于目标节点上执行可以使得执行相应待调度节点中的任务的内存资源、cpu资源以及网络速率角度是最优的。
54.进一步的，从节点角度：单个目标节点可以对应一个待调度容器也可以对应有多个待调度容器，单个目标节点理当执行其对应的所有待调度容器。然而，考虑到待调度容器
中一次性任务的时延敏感的特性，存在单个目标节点的当前可用资源不足以处理其对应的所有待调度容器的情况。在这种情况下，单个目标节点会计算其对应的所有待调度容器各自的容器综合评分，在其当前可用资源充足的前提下，优先选择容器综合评分更好的待调度容器作为其匹配容器，然后将剩余的待调度容器作为再调度容器。在未触发终止条件时，将再调度容器作为新的待调度容器，对这些新的调度容器执行同上述容器角度所包含的操作。
55.另外，容器综合评分还综合考虑时间维度、资源维度以及代价维度。具体的，时间维度考虑：待调度容器在节点上执行所需要的实际执行时间、以及待调度容器中任务执行完成所要求的最长时间；资源维度考虑：节点执行待调度容器的单位资源成本、以及待调度容器在节点上执行所需要的实际执行时间；代价维度考虑：节点执行待调度容器的执行资源代价、以及待调度容器在节点上执行所需要的实际执行时间。
56.也就是说，本技术实施例中通过容器和节点对彼此之间的评分来建立匹配关系实现资源调度，使得资源的使用更加合理化，进而提高资源的利用率，缓解边缘计算环境下存在大量超负荷的时延敏感的一次性任务无法及时处理的情况。
57.下面对本技术实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本技术实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本技术实施例提供的技术方案。
58.本技术实施例提供的方案可以适用于大多数容器集群场景中，尤其适用于边缘计算的容器集群场景，即一次性任务容器调度到边缘计算节点上执行的场景。
59.如图1所示，为本技术实施例提供的一种应用场景示意图，在该场景中，可以包括终端设备以及边缘计算环境下的kubernetes集群。
60.在图1中，边缘计算的场景下，对于如监控图像处理，语音分析等的一次性任务将卸载到kubernetes集群的边缘计算服务器上执行。考虑到边缘计算服务器存在资源受限，无法按时处理所有一次性任务的问题。本技术实施例采用kubernetes容器资源调度的方式来调度容器，使得容器中的一次性任务能够被调度到相应节点执行，以充分利用边缘服务器的计算资源，提高资源利用的整体效益。
61.需要说明的是，图1所示只是举例说明，实际上kubernetes集群可以是其他集群，在本技术实施例中不做具体限定。当然，本技术实施例提供的方法并不限用于图1所示的应用场景中，还可以用于其他可能的应用场景，本技术实施例并不进行限制。对于图1所示的应用场景的各个设备所能实现的功能将在后续的方法实施例中一并进行描述，在此先不过多赘述。
62.下面结合上述描述的应用场景，参考附图来描述本技术示例性实施方式提供的方法，需要注意的是，上述应用场景仅是为了便于理解本技术的精神和原理而示出，本技术的实施方式在此方面不受任何限制。
63.参见图2所示，为本技术实施例提供的资源调度的方法的流程示意图，该方法的具体实施流程如下：
64.步骤201：响应于为每个待调度容器确定一个目标节点，得到m个待调度容器各自对应的目标节点；
65.其中，m为大于0的整数，一个目标节点对应至少一个待调度容器，换而言之，一个
待调度容器唯一对应一个目标节点，而一个目标节点可以对应单个或多个待调度容器。
66.在执行步骤201之前，可以通过kubernetes集群中api server接收各个用户提交的一次性任务容器创建请求，并存储一次性任务容器的相关数据。
67.进一步的，通过调度器监听api server，从一次性任务容器列表中确定出所有未调度的m个待调度容器，获取这m个待调度容器各自的容器信息，同时获取kubernetes集群中n个节点各自的节点信息。
68.更为详细的，容器信息可以包括容器所封装一次性任务的：cpu核数需求、内存需求、预设执行时间(执行完成的截止时间)、数据量大小、工作负载、执行资源代价(容器为执行任务所愿意的价格付出)、在不同节点上的实际执行时间等。
69.节点信息可以包括节点的：cpu频率、cpu核数、内存资源、网络速率以及单位资源成本系数等。
70.在本技术实施例中，首先为每个待调度容器确定一个目标节点，具体的，计算单个待调度容器调度至单个节点执行的节点综合评分，得到每个待调度容器调度至n个节点执行的n个节点综合评分。换而言之，对于每个待调度容器来说，会计算得到n个节点综合评分。然后，从n个节点综合评分中选取最大节点综合评分对应的节点作为相应待调度容器对应的目标节点。
71.更为详细的，上述节点综合评分在计算过程中考虑待调度容器对节点的cpu资源以及内存资源的不同需求偏重，还考虑待调度容器对节点的cpu资源以及网络资源的基本需求，下面以计算单个待调度容器调度至单个节点执行的节点综合评分为例，对上述计算过程作如下具体说明。
72.具体来说，以单个待调度容器调度至单个节点执行为例，首先计算节点性能评分以及节点负载评分，然后对节点性能评分以及节点负载评分进行加权求和，得到单个待调度容器调度至单个节点执行的节点综合评分。
73.在本技术实施例中，节点综合评分的计算可以参见如下公式所示：
[0074][0075]
其中，为待调度容器j调度至节点i执行的节点综合评分；为待调度容器j调度至节点i执行的节点性能评分；为待调度容器j调度至节点i执行的节点负载评分；a、b为指定系数，如等。
[0076]
具体来说，节点性能评分可以通过如下方式得到：首先计算第一系数与单个节点的cpu核数之间的第一乘积，然后计算第二系数与单个节点的内存需求之间的第二乘积，再基于第一乘积、第二乘积以及单个节点的网络速率，计算单个待调度容器调度至单个节点执行的节点性能评分。
[0077]
在本技术实施例中，节点性能评分的计算可以参见如下公式所示：
[0078][0079]
其中，fi为节点i的cpu频率；为第一乘积；为第二乘积；为节点i的网络速率。
[0080]
一方面，在第一乘积中，为节点i的cpu核数；为第一系数，第一系数为单个待调度容器的cpu核数与m个待调度容器的cpu核数总数之间的比值。
[0081]
具体的，在第一系数中，为待调度容器j的cpu核数需求；数需求；为待调度容器j的内存需求，m
total
为m个待调度容器的内存需求的总和；为待调度容器j的内存需求；为待调度容器j的内存需求；为待调度容器j的内存需求，c
total
为m个待调度容器的cpu核数需求的总和。
[0082]
另一方面，在第二乘积中，为节点i的内存需求；为第二系数，第二系数为单个待调度容器的内存需求与m个待调度容器的内存需求总数之间的比值。
[0083]
具体的，在第二系数中，为待调度容器j的内存需求；求；为待调度容器j的内存需求，m
total
为m个待调度容器的内存需求的总和；为待调度容器j的内存需求；为待调度容器j的内存需求；为待调度容器j的内存需求，c
total
为m个待调度容器的cpu核数需求的总和。
[0084]
具体来说，节点负载评分可以通过如下方式得到：首先确定在单个待调度容器调度至单个节点执行后单个节点的cpu空闲率、内存空闲率以及网络空闲率，然后基于单个节点的cpu空闲率、内存空闲率以及网络空闲率，计算得到单个待调度容器调度至单个节点执行的节点负载评分。
[0085]
在本技术实施例中，节点负载评分的计算可以参见如下公式所示：
[0086][0087]
其中，为节点负载评分；为节点i执行待调度容器j后的cpu空闲率；为节点i执行待调度容器j后的内存空闲率；为节点i执行待调度容器j后的网络空闲率。
[0088]
综上所述，上述节点综合评分一方面考虑节点执行相应待调度容器中任务的节点性能，还考虑到节点执行相应待调度容器中任务的负载均衡。更为详细的，在对节点性能的衡量中，还结合cpu核数、cpu频率、内存需求以及网络速率进行计算。
[0089]
鉴于此，对于待调度容器而言，可以将每个待调度容器对应的目标节点视为其调度的最优节点，也就是说，如果待调度节点可以在其对应的目标节点上执行可以达到最好的效果。
[0090]
步骤202：判断各个目标节点的当前可用资源是否能够处理所述各个目标节点对应的单个或多个待调度容器；
[0091]
在确定出m个待调度容器各自对应的目标节点后，可以使得这m个待调度容器向各自对应的目标节点发送调度意向。对于节点侧，各个目标节点将接收到待调度容器发送的调度意向，但此时，若目标节点接收所有的调度意向，则将在其当前可用资源不足的情况下，导致部分待调度容器中任务不能得到及时执行或处理，造成任务处理时延大的问题。
[0092]
在本技术实施例中，为解决上述问题，首先需要基于各个目标节点的当前可用资源，来判断其当前可用资源是否能够处理相应的单个或多个待调度容器：若是，则执行步骤203；若否，则执行步骤204。
[0093]
步骤203：将所述m个待调度容器作为所述同一目标节点对应的m个匹配容器；
[0094]
在本技术实施例中，若判定各个目标节点的当前可用资源能够处理各个目标节点对应的单个或多个待调度容器，那么便可以接收待调度节点发送的调度意向，即各个目标节点接纳相应的单个或多个待调度容器。
[0095]
进一步的，各个目标节点将与相应的单个或多个待调度容器进行匹配，至此，可以将与目标节点建立起这种匹配关系的待调度容器，作为目标节点对应的匹配容器。进一步的，执行步骤206。
[0096]
步骤204：从所述单个或多个待调度容器中确定至少一个待调度容器作为再调度容器；
[0097]
在本技术实施例中，若判定各个目标节点的当前可用资源不能处理各个目标节点对应的单个或多个待调度容器，那么便需要拒绝一些待调度容器的调度意向，即各个目标节点基于其当前可用资源拒绝部分待调度容器，并将拒绝的部分待调度容器作为再调度容器。
[0098]
具体来说，通过目标节点对各个待调度容器进行容器综合评分的机制来确定出再调度容器。详细来说，基于计算单个目标节点执行单个待调度容器的容器综合评分，得到各个目标节点各自执行单个或多个待调度容器的单个或多个容器综合评分，然后基于单个或多个容器综合评分按照数值大小进行排序，得到单个或多个待调度容器的优先级升序排
列，再基于该优先级升序排列，依次添加待调度容器至各个目标节点上执行，直到各个目标节点的当前可用资源无法执行下一个待调度容器，将各个目标节点的当前可用资源无法执行的待调度容器作为再调度容器。
[0099]
更为详细的，上述容器综合评分在计算过程中考虑时间维度、资源维度和代价维度。具体的，主要考虑节点执行待调度容器的时间宽裕度、节点执行待调度容器所耗费的服务器成本、以及待调度容器所对应的执行资源代价，即待调度容器在节点上执行平均单元资源所愿意付出的价格付出。
[0100]
具体来说，以计算单个目标节点执行单个待调度容器的容器综合评分为例，首先确定时间维度的第一评分指数、资源维度的第二评分指数和代价维度的第三评分指数，然后基于第一评分指数、第二评分指数和第三评分指数计算容器综合评分。
[0101]
在本技术实施例中，容器综合评分的计算可以参见如下公式所示：
[0102][0103]
其中，为节点i对待调度容器j的容器综合评分；为节点i对待调度容器j的第三评分指数；为节点i对待调度容器j的第一评分指数；为节点i对待调度容器j的第二评分指数；c、d、e为指定系数，其基于实际应用场景设置。
[0104]
具体来说，第一评分指数可以通过如下方式得到：确定目标节点执行单个待调度容器的实际执行时间以及单个待调度容器的预设执行时间，然后对实际执行时间以及预设执行时间作对数计算，得到时间维度的第一评分指数。
[0105]
在本技术实施例中，第一评分指数的计算可以参见如下公式所示：
[0106][0107]
其中，为节点i对待调度容器j的第一评分指数；为节点i执行待调度容器j的实际执行时间；为待调度容器j的预设执行时间，即其任务完成的最迟截止时间。
[0108]
具体来说，第二评分指数可以通过如下方式得到：确定目标节点执行单个待调度容器的实际执行时间，然后对实际执行时间以及目标节点执行单个待调度容器的单位资源成本作乘积运算，得到资源维度的第二评分指数。
[0109]
在本技术实施例中，第二评分指数的计算可以参见如下公式所示：
[0110][0111]
其中，为节点i对待调度容器j的第二评分指数；为待调度容器j的单位资源成本系数；为待调度容器j的预设执行时间，即其任务完成的最迟截止时间。
[0112]
具体来说，第三评分指数可以通过如下方式得到：确定目标节点执行单个待调度容器的实际执行时间，然后计算单个待调度容器对应的执行资源代价与实际执行时间之间的比值，得到代价维度的第三评价指数。
[0113]
在本技术实施例中，第三评分指数的计算可以参见如下公式所示：
[0114][0115]
其中，为节点i对待调度容器j的第三评分指数；为待调度容器j对应的执行资源代价；为待调度容器j的预设执行时间，即其任务完成的最迟截止时间。
[0116]
综上所述，上述容器综合评分结合时间维度、资源维度以及代价维度计算得到。因此，对于当前可用资源不足以执行对应的所有待调度容器的目标节点而言，可以将容器综合评分高的作为优先考虑的待调度容器，通过这种方式淘汰部分待调度容器，并将这些待调度容器作为再调度容器。
[0117]
值得说明的是，在本技术实施例中，再调度容器的本质也是待调度容器，在此用于表征其发送的调度意向未被接收，因此需要进行重新调度。
[0118]
步骤205：响应于未触发终止条件时，重新为每个再调度容器确定一个目标节点；
[0119]
在本技术实施例中，存在两种触发终止条件的情况：情况一，若各个目标节点的当前可用资源能够执行各个目标节点对应的m个待调度容器；情况二，存在至少一个再调度容器且集群中的各个节点的当前可用资源都无法执行至少一个所述再调度容器。若满足上述任一情况，那么便可以认定为触发终止条件。
[0120]
进一步的，响应于未触发终止条件，重新为每个再调度容器重新确定一个目标节点，即将这些再调度容器作为当前的待调度容器，并执行步骤201。
[0121]
在一些实施方式中，响应于触发终止条件，执行步骤206。
[0122]
步骤206：响应于触发所述终止条件，将各个匹配容器调度至所述各个匹配容器各自对应的目标节点执行。
[0123]
在本技术实施例中，若判定触发终止条件，则可以认定当前的所有待调度容器都成为相应目标节点的匹配容器，或当前的待调度容器已经遍历过集群中的n个节点也没有成为任一节点的匹配容器。在这种情况下，可以认定继续循环资源调度的过程是没有意义的，因此可以停止资源调度的过程，并将各个匹配容器调度至各个匹配容器各自对应的目标节点执行。
[0124]
综上所述，本技术实施例通过提出一种资源调度的方法，主要适用于大量一次性任务卸载到基于kubernetes集群的边缘计算服务器上执行的场景。在边缘计算服务器资源有限情况下，综合考虑到任务容器对不同资源的偏重，任务容器时间宽裕度、愿意付出的代价和节点的性能、负载等因素，并提出一种稳定匹配的多对多算法进行一次性任务的待调度容器和节点的匹配绑定，以提高资源的利用率。
[0125]
基于同一发明构思，本技术还提供了一种资源调度的装置，用以实现边缘计算场景的容器资源调度，解决处理大量时延敏感的一次性任务存在的时延大的问题，有效提高资源的利用率，参见图3，该装置包括：
[0126]
第一确定模块301，响应于为每个待调度容器确定一个目标节点，得到m个待调度容器各自对应的目标节点；其中，m为大于0的整数，一个目标节点至少对应一个待调度容器；
[0127]
判断模块302，判断各个目标节点的当前可用资源是否能够处理所述各个目标节点对应的单个或多个待调度容器；
[0128]
第二确定模块303，若各个目标节点的当前可用资源无法执行所述各个目标节点对应的单个或多个待调度容器，则从所述单个或多个待调度容器中确定至少一个待调度容器作为再调度容器；
[0129]
第三确定模块304，在未触发终止条件时，重新为每个再调度容器确定一个目标节点，直到触发所述终止条件。
[0130]
在一种可能的设计中，所述触发终止条件，所述第三确定模块304，具体用于：所述各个目标节点的当前可用资源能够执行所述各个目标节点对应的m个待调度容器；或存在至少一个所述再调度容器，并且集群中的各个节点的当前可用资源都无法执行至少一个所述再调度容器。
[0131]
在一种可能的设计中，所述为每个待调度容器确定一个目标节点，所述第一确定模块301，具体用于：计算单个待调度容器调度至单个节点执行的节点综合评分，得到所述每个待调度容器调度至多个节点执行的多个节点综合评分；其中，一个节点综合评分对应一个节点；从所述多个节点综合评分中选取最大节点综合评分对应的节点作为所述每个待调度容器对应的目标节点。
[0132]
在一种可能的设计中，所述计算单个待调度容器调度至单个节点执行的节点综合评分，所述第一确定模块301，具体用于：计算第一系数与所述单个节点的cpu核数之间的第一乘积；其中，所述第一系数基于所述单个待调度容器的cpu核数确定；计算第二系数与所述单个节点的内存需求之间的第二乘积；其中，所述第二系数基于所述单个待调度容器的内存需求确定；基于所述第一乘积、所述第二乘积以及所述单个节点的网络速率，计算所述单个待调度容器调度至所述单个节点执行的节点性能评分；确定在所述单个待调度容器调度至所述单个节点执行后，所述单个节点的cpu空闲率、内存空闲率以及网络空闲率；基于所述单个节点的cpu空闲率、内存空闲率以及网络空闲率，计算所述单个待调度容器调度至所述单个节点执行的节点负载评分；对所述节点性能评分以及所述节点负载评分进行加权求和，得到所述单个待调度容器调度至所述单个节点执行的节点综合评分。
[0133]
在一种可能的设计中，在判断各个目标节点的当前可用资源是否能够处理所述各个目标节点对应的单个或多个待调度容器之后，所述装置，还用于：若是，则将所述m个待调度容器作为所述同一目标节点对应的m个匹配容器；响应于触发所述终止条件，在将各个匹配容器调度至所述各个匹配容器各自对应的目标节点执行。
[0134]
在一种可能的设计中，所述从所述单个或多个待调度容器中确定至少一个待调度容器作为再调度容器，所述第二确定模块303，具体用于：计算单个目标节点执行单个待调度容器的容器综合评分，得到所述各个目标节点各自执行所述单个或多个待调度容器的单个或多个容器综合评分；基于所述单个或多个容器综合评分按照数值大小进行排序，得到所述单个或多个待调度容器的优先级排序；基于所述优先级排序，依次添加待调度容器至所述各个目标节点上执行，直到所述各个目标节点的当前可用资源无法执行下一个待调度容器；将所述各个目标节点的当前可用资源无法执行的待调度容器作为再调度容器。
[0135]
在一种可能的设计中，所述计算单个目标节点执行单个待调度容器的容器综合评分，所述第二确定模块303，具体用于：确定所述目标节点执行所述单个待调度容器的实际
执行时间以及所述单个待调度容器的预设执行时间；对所述实际执行时间以及所述预设执行时间作对数计算，得到时间维度的第一评分指数；对所述实际执行时间以及所述目标节点执行所述单个待调度容器的单位资源成本系数作乘积运算，得到资源维度的第二评分指数；计算所述单个待调度容器对应的执行资源代价与所述实际执行时间之间的比值，得到代价维度的第三评价指数；基于所述第一评分指数、所述第二评分指数以及所述第三评分指数，得到所述单个目标节点执行所述单个待调度容器的容器综合评分。
[0136]
基于上述装置，通过容器和节点对彼此之间的评分来建立匹配关系实现资源调度，使得资源的使用更加合理化，进而提高资源的利用率，缓解边缘计算环境下存在大量超负荷的时延敏感的一次性任务无法及时处理的情况。
[0137]
基于同一发明构思，本技术实施例中还提供了一种电子设备，所述电子设备可以实现前述一种资源调度的装置的功能，参考图4，所述电子设备包括：
[0138]
至少一个处理器401，以及与至少一个处理器401连接的存储器402，本技术实施例中不限定处理器401与存储器402之间的具体连接介质，图4中是以处理器401和存储器402之间通过总线400连接为例。总线400在图4中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线400可以分为地址总线、数据总线、控制总线等，为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。或者，处理器401也可以称为控制器，对于名称不做限制。
[0139]
在本技术实施例中，存储器402存储有可被至少一个处理器401执行的指令，至少一个处理器401通过执行存储器402存储的指令，可以执行前文论述的资源调度方法。处理器401可以实现图3所示的装置中各个模块的功能。
[0140]
其中，处理器401是该装置/系统的控制中心，可以利用各种接口和线路连接整个该控制设备的各个部分，通过运行或执行存储在存储器402内的指令以及调用存储在存储器402内的数据，该装置/系统的各种功能和处理数据，从而对该装置/系统进行整体监控。
[0141]
在一种可能的设计中，处理器401可包括一个或多个处理单元，处理器401可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器401中。在一些实施例中，处理器401和存储器402可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。
[0142]
处理器401可以是通用处理器，例如中央处理器(cpu)、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本技术实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本技术实施例所公开的资源调度方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
[0143]
存储器402作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器402可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(random access memory，ram)、静态随机访问存储器(static random access memory，sram)、可编程只读存储器(programmable read only memory，prom)、只读存储器(read only memory，rom)、带电可擦除可编程只读存储器(electrically erasable programmable read-only memory，
eeprom)、磁性存储器、磁盘、光盘等等。存储器402是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本技术实施例中的存储器402还可以是电路或者其它任意能够实现存储功能的装置/系统，用于存储程序指令和/或数据。
[0144]
通过对处理器401进行设计编程，可以将前述实施例中介绍的资源调度方法所对应的代码固化到芯片内，从而使芯片在运行时能够执行图2所示的实施例的资源调度方法的步骤。如何对处理器401进行设计编程为本领域技术人员所公知的技术，这里不再赘述。
[0145]
基于同一发明构思，本技术实施例还提供一种存储介质，该存储介质存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行前文论述资源调度方法。
[0146]
在一些可能的实施方式中，本技术提供的资源调度方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在装置上运行时，程序代码用于使该控制设备执行本说明书上述描述的根据本技术各种示例性实施方式的资源调度方法中的步骤。
[0147]
本领域内的技术人员应明白，本技术的实施例可提供为方法、装置/系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0148]
本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0149]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0150]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0151]
显然，本领域的技术人员可以对本技术进行各种改动和变型而不脱离本技术的精神和范围。这样，倘若本技术的这些修改和变型属于本技术权利要求及其等同技术的范围之内，则本技术也意图包含这些改动和变型在内。
技术特征：1.一种资源调度的方法，其特征在于，所述方法包括：响应于为每个待调度容器确定一个目标节点，得到m个待调度容器各自对应的目标节点；其中，m为大于0的整数，一个目标节点对应至少一个待调度容器；判断各个目标节点的当前可用资源是否能够处理所述各个目标节点对应的单个或多个待调度容器；若否，则从所述单个或多个待调度容器中确定至少一个待调度容器作为再调度容器；响应于未触发终止条件时，重新为每个再调度容器确定一个目标节点。2.如权利要求1所述的方法，其特征在于，所述触发终止条件，包括：所述各个目标节点的当前可用资源能够执行所述各个目标节点对应的m个待调度容器；或存在至少一个所述再调度容器，并且集群中的各个节点的当前可用资源都无法执行至少一个所述再调度容器。3.如权利要求1所述的方法，其特征在于，所述为每个待调度容器确定一个目标节点，包括：计算单个待调度容器调度至单个节点执行的节点综合评分，得到所述每个待调度容器调度至多个节点执行的多个节点综合评分；其中，一个节点综合评分对应一个节点；从所述多个节点综合评分中选取最大节点综合评分对应的节点作为所述每个待调度容器对应的目标节点。4.如权利要求2所述的方法，其特征在于，所述计算单个待调度容器调度至单个节点执行的节点综合评分，包括：计算第一系数与所述单个节点的cpu核数之间的第一乘积；其中，所述第一系数基于所述单个待调度容器的cpu核数确定；计算第二系数与所述单个节点的内存需求之间的第二乘积；其中，所述第二系数基于所述单个待调度容器的内存需求确定；基于所述第一乘积、所述第二乘积以及所述单个节点的网络速率，计算所述单个待调度容器调度至所述单个节点执行的节点性能评分；确定在所述单个待调度容器调度至所述单个节点执行后，所述单个节点的cpu空闲率、内存空闲率以及网络空闲率；基于所述单个节点的cpu空闲率、内存空闲率以及网络空闲率，计算所述单个待调度容器调度至所述单个节点执行的节点负载评分；对所述节点性能评分以及所述节点负载评分进行加权求和，得到所述单个待调度容器调度至所述单个节点执行的节点综合评分。5.如权利要求1所述的方法，其特征在于，在判断各个目标节点的当前可用资源是否能够处理所述各个目标节点对应的单个或多个待调度容器之后，还包括：若是，则将所述m个待调度容器作为所述同一目标节点对应的m个匹配容器；响应于触发所述终止条件，在将各个匹配容器调度至所述各个匹配容器各自对应的目标节点执行。6.如权利要求1所述的方法，其特征在于，所述从所述单个或多个待调度容器中确定至少一个待调度容器作为再调度容器，包括：
计算单个目标节点执行单个待调度容器的容器综合评分，得到所述各个目标节点各自执行所述单个或多个待调度容器的单个或多个容器综合评分；基于所述单个或多个容器综合评分按照数值大小进行排序，得到所述单个或多个待调度容器的优先级排序；基于所述优先级排序，依次添加待调度容器至所述各个目标节点上执行，直到所述各个目标节点的当前可用资源无法执行下一个待调度容器；将所述各个目标节点的当前可用资源无法执行的待调度容器作为再调度容器。7.如权利要求6所述的方法，其特征在于，所述计算单个目标节点执行单个待调度容器的容器综合评分，包括：确定所述目标节点执行所述单个待调度容器的实际执行时间以及所述单个待调度容器的预设执行时间；对所述实际执行时间以及所述预设执行时间作对数计算，得到时间维度的第一评分指数；对所述实际执行时间以及所述目标节点执行所述单个待调度容器的单位资源成本系数作乘积运算，得到资源维度的第二评分指数；计算所述单个待调度容器对应的执行资源代价与所述实际执行时间之间的比值，得到代价维度的第三评价指数；基于所述第一评分指数、所述第二评分指数以及所述第三评分指数，得到所述单个目标节点执行所述单个待调度容器的容器综合评分。8.一种资源调度的装置，其特征在于，所述装置包括：第一确定模块，响应于为每个待调度容器确定一个目标节点，得到m个待调度容器各自对应的目标节点；其中，m为大于0的整数，一个目标节点至少对应一个待调度容器；判断模块，判断各个目标节点的当前可用资源是否能够处理所述各个目标节点对应的单个或多个待调度容器；第二确定模块，若各个目标节点的当前可用资源无法执行所述各个目标节点对应的单个或多个待调度容器，则从所述单个或多个待调度容器中确定至少一个待调度容器作为再调度容器；第三确定模块，在未触发终止条件时，重新为每个再调度容器确定一个目标节点，直到触发所述终止条件。9.一种电子设备，其特征在于，包括：存储器，用于存放计算机程序；处理器，用于执行所述存储器上所存放的计算机程序时，实现权利要求1-7中任一项所述的方法步骤。10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1-7任一项所述的方法步骤。
技术总结本申请涉及边缘计算技术领域，具体涉及一种资源调度的方法、装置及电子设备，用于解决处理大量时延敏感的一次性任务存在的时延大的问题。该方法包括在M个待调度容器各自对应的目标节点后，判断各个目标节点的当前可用资源是否能够处理各个目标节点对应的单个或多个待调度容器：若是，则将M个待调度容器作为同一目标节点对应的M个匹配容器；若否，则从单个或多个待调度容器中确定至少一个待调度容器作为再调度容器；响应于未触发终止条件，重新为每个再调度容器确定一个目标节点；响应于触发终止条件，将各个匹配容器调度至所述各个匹配容器各自对应的目标节点执行。基于上述方法实现边缘计算场景的容器资源调度，提高资源的利用率。利用率。利用率。
技术研发人员：朱韦琳
受保护的技术使用者：天翼云科技有限公司
技术研发日：2022.07.15
技术公布日：2022/11/1
