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

Abstract

本公开提供了一种资源调度方法、装置、电子设备以及计算机可读存储介质，其中，该方法包括：获取资源请求端发送的资源调度请求；响应于资源调度请求，获取针对资源请求端的资源分组信息；资源分组信息用于指示每个工作节点所属的资源分组，以及部署在工作节点中的GPU资源与每个工作节点的绑定关系；基于GPU资源需求量和资源分组信息所指示的资源分组的GPU资源剩余量确定用于创建目标容器的工作节点和目标容器所需的GPU资源。本公开实施例通过该资源分组信息对工作节点和GPU资源进行分组部署的方式，可以灵活对工作节点中部署的GPU资源进行调度，减少GPU资源碎片，从而提高GPU资源的利用率。

Description

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

技术领域

本公开涉及计算机技术领域，具体而言，涉及一种资源调度方法、装置、电子设备以及计算机可读存储介质。

背景技术

目前，随着云计算和容器编排的流行，越来越多的服务使用容器集群中容器运行，容器集群是为容器化的应用程序创建和部署的集群，例如，Kubernetes集群。在Kubernetes集群中使用图形处理器(Graphics Processing Unit，缩写GPU)可以有效的提升服务的并行计算能力。在当前Kubernetes集群中，在调度GPU资源时，可以按照机器分组的方式调度GPU资源。但是，按照机器分组的调度方式，需要按照机器的分组对GPU进行调度。一般情况下，按照机器分组的调度方式会将部署在相同的机器上的GPU资源调配给资源请求端。如果机器上GPU数量较多，或者机器数量较少，则无法实现灵活对机器中的GPU资源进行调度，从而容易造成机器上较多的GPU资源出现资源浪费，例如，未被分配给资源请求端的GPU资源。

发明内容

本公开实施例至少提供一种资源调度方法、装置、电子设备以及计算机可读存储介质。

第一方面，本公开实施例提供了一种资源调度方法，应用于容器集群的主节点，所述容器集群还包含至少一个部署有GPU的工作节点，包括：获取资源请求端发送的资源调度请求；所述资源调度请求中包含待创建的目标容器的GPU资源需求量；响应于所述资源调度请求，获取针对所述资源请求端的资源分组信息；所述资源分组信息用于指示每个工作节点所属的资源分组，以及部署在工作节点中的GPU资源与每个工作节点的绑定关系；基于所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息；所述资源调度信息包括：用于创建所述目标容器的工作节点和所述目标容器所需的GPU资源。

在本公开实施例中，首先，获取资源请求端发送的资源调度请求，并响应于资源调度请求，获取针对资源请求端的资源分组信息，进而基于GPU资源需求量和资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息。通过上述描述可知，预先为资源请求端对应设置了资源分组信息，通过该资源分组信息对工作节点和GPU资源进行分组部署的方式，可以灵活对工作节点中部署的GPU资源进行调度，减少GPU资源碎片，从而提高GPU资源的利用率。

一种可选的实施方式中，若所述资源分组的数量为多个，则多个资源分组中任意两个资源分组中所包含的GPU资源部分相同或者完全不相同，所述多个资源分组中任意两个资源分组所对应的工作节点相同或者不同，且所述资源分组中与每个工作节点相绑定的GPU资源为部署在该工作节点中的GPU资源。

在本公开实施例中，通过上述处理方式，可以提高工作节点中部署的GPU资源的利用率，减小GPU资源碎片，并避免资源分组之间出现冲突的分组，以提高资源调度的可靠性和准确性。

一种可选的实施方式中，基于所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息，包括：获取所述资源分组所对应的容器标识，其中，所述容器标识用于指示每个资源分组所对应的目标容器；根据所述容器标识在所述资源分组中确定与所述目标容器相匹配的资源分组；若所述相匹配的资源分组的GPU资源剩余量大于或者等于所述GPU资源需求量，则根据所述相匹配的资源分组确定所述资源调度信息。

通过上述描述可知，在本公开实施例中，通过容器标识来确定资源调度信息的方式，可以能够快速的为目标容器确定出与之相匹配的工作节点和GPU资源，还可以减少GPU资源碎片，从而提高GPU资源的利用率。

一种可选的实施方式中，所述方法还包括：获取所述目标容器所需GPU资源的目标类型信息；基于所述GPU资源需求量和资源分组的GPU资源剩余量确定资源调度信息，包括：在所述资源分组中确定包含类型信息为所述目标类型信息的GPU资源的备选资源分组；基于所述GPU资源需求量和所述资源分组的GPU资源剩余量在所述备选资源分组中确定目标资源分组；根据所述目标资源分组确定所述资源调度信息。

通过上述描述可知，在本公开实施例中，结合GPU资源的目标类型信息来确定目标资源分组的方式，可以得到与目标容器匹配度更高的资源分组，从而提高了目标容器和GPU资源之间的亲和性，同时还可以避免GPU碎片的产生。

一种可选的实施方式中，所述GPU资源包括以下类型的资源：物理GPU资源和/或虚拟GPU资源，其中，所述虚拟GPU资源为通过对所述工作节点中的物理GPU资源虚拟化之后得到的GPU资源。

在本公开实施例中，通过设置GPU资源包括物理GPU资源和/或虚拟GPU资源的方式，能够丰富GPU资源的类型，满足用户的多元化需求。

一种可选的实施方式中，所述方法还包括通过以下步骤确定所述资源分组信息：获取所述容器集群中的工作节点列表；其中，所述工作节点列表中包含所述容器集群中所包含的至少一个工作节点的节点信息；获取所述容器集群的工作节点中部署的GPU资源的GPU资源列表；所述GPU资源列表中包含工作节点中部署的GPU资源的资源状态信息；基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息。

通过上述描述可知，在本公开实施例中，在设置资源分组信息时，能够以工作节点中的GPU资源为调度单位进行调度，从而进一步提高调度灵活性，从而实现用户服务与GPU资源的匹配度，提高服务性能。

一种可选的实施方式中，基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息，包括：获取目标分组参数，其中，所述目标分组参数包括以下至少之一：GPU资源的类型信息、GPU资源的估计需求量；按照所述目标分组参数确定所述至少一个工作节点所属的资源分组，以及确定与所属于每个资源分组中的工作节点具有绑定关系的GPU资源，从而得到所述资源分组信息。

在本公开实施例中，通过目标分组参数对工作节点和GPU资源进行分组的方式，能够为资源请求端所涉及的业务(或者服务)调度匹配度最高的GPU资源，从而提高了资源请求端所涉及业务(或者服务)与GPU资源之间的亲和度。

一种可选的实施方式中，所述方法还包括：在基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息之后，获取所述资源请求端发送的资源分组信息的更新信息；按照所述更新信息对所述资源分组信息进行更新。

在本公开实施例中，通过目标分组参数对工作节点和GPU资源进行分组的方式，可以提高资源分组信息的分组效率，缩短资源分组信息的分组时间。在此基础上，通过设置资源请求端对资源分组信息进行修改更新的方式，还可以进一步提高资源请求端所涉及业务(或者服务)与GPU资源之间的亲和度，从而实现个性化定制每个资源请求端的资源分组信息。

一种可选的实施方式中，基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息，包括：获取所述资源请求端发送的分组指示信息，其中，所述分组指示信息用于指示每个工作节点所属的资源分组，以及指示所述GPU资源列表中的每个GPU资源和每个工作节点之间的绑定关系；按照所述分组指示信息对所述工作节点和所述工作节点内部署的GPU资源进行分组，得到所述资源分组信息。

一种可选的实施方式中，在基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息之前，所述方法还包括：按照分组权限信息对所述工作节点列表中的工作节点和/或所述GPU资源列表中的GPU资源进行过滤；其中，所述分组权限信息用于指示所述资源请求端对每个工作节点和/或每个工作节点中部署的GPU资源的操作权限；基于过滤之后的所述工作节点列表和过滤之后的所述GPU资源列表确定所述资源分组信息。

通过上述描述可知，在本公开实施例中，通过分组权限信息对工作节点列表中的工作节点和/或GPU资源列表中的GPU资源进行过滤的方式，可以过滤掉资源请求端不具备分组权限的工作节点或者GPU资源，从而提高工作节点和GPU资源的分组效率。

一种可选的实施方式中，基于所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息，包括：获取预先为所述资源请求端设定的GPU资源的资源上限值，并获取所述资源请求端的已分配GPU资源的数量；基于所述资源上限值和所述已分配GPU资源的数量确定GPU的实际调度数量；按照所述实际调度数量、所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定所述资源调度信息。

通过上述描述可知，在本公开实施例中，通过为Kubernetes容器集群中的工作节点(Node)增加资源分组信息的方式，可以使Kubernetes容器集群在调度GPU资源时，能够感知资源分组信息，并针对资源分组信息调整调度策略。

第二方面，本公开实施例提供了一种资源调度方法，应用于容器集群的中部署有GPU的工作节点，包括：获取资源请求端所请求的资源调度信息；所述资源调度信息包括：用于创建目标容器的目标工作节点和所述目标容器所需的GPU资源；所述资源调度信息为通过上述第一方面中任一项所述的方法确定出的信息；按照所述资源调度信息中的指示，在所述目标工作节点上创建所述目标容器，并基于所述资源调度信息中指示的GPU资源为所述目标容器提供相应的处理资源。

一种可选的实施方式中，所述GPU资源包括以下类型的资源：物理GPU资源和/或虚拟GPU资源，其中，所述虚拟GPU资源为通过对所述工作节点中的物理GPU资源虚拟化之后得到的GPU资源。

第三方面，本公开实施例提供了一种资源调度装置，设置于容器集群的主节点，所述容器集群还包含至少一个部署有GPU的工作节点，包括：第一获取单元，用于获取资源请求端发送的资源调度请求；所述资源调度请求中包含待创建的目标容器的GPU资源需求量；第二获取单元，用于响应于所述资源调度请求，获取针对所述资源请求端的资源分组信息；所述资源分组信息用于指示每个工作节点所属的资源分组，以及部署在工作节点中的GPU资源与每个工作节点的绑定关系；确定单元，用于基于所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定目标资源分组，并基于所述目标资源分组确定资源调度信息；所述资源调度信息包括：用于创建所述目标容器的工作节点和所述目标容器所需的GPU资源。

第四方面，本公开实施例提供了一种资源调度装置，设置于容器集群的中部署有GPU的工作节点，包括：第三获取单元，用于获取资源请求端所请求的资源调度信息；所述资源调度信息包括：用于创建目标容器的目标工作节点和所述目标容器所需的GPU资源；所述资源调度信息为通过上述第一方面中任一项所述的方法确定出的信息；创建单元，用于按照所述资源调度信息中的指示，在所述目标工作节点上创建所述目标容器，并基于所述资源调度信息中指示的GPU资源为所述目标容器提供相应的处理资源。

第五方面，本公开实施例提供了一种电子设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如上述第一方面或第二方面任一所述的资源调度方法的步骤。

第六方面，本公开实施例提供了一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如上述第一方面或第二方面任意一项所述的资源调度方法的步骤。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，此处的附图被并入说明书中并构成本说明书中的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本公开实施例所提供的一种资源调度方法的流程图；

图2示出了本公开实施例所提供的一种基于Kubernetes容器集群的资源调度方法的流程图；

图3示出了本公开实施例所提供的资源调度方法中，确定资源分组信息具体方法的流程图；

图4示出了本公开实施例所提供的另一种资源调度方法的流程图；

图5示出了本公开实施例所提供的又一种资源调度方法的流程图；

图6示出了本公开实施例所提供的另一种资源调度方法的流程图；

图7示出了本公开实施例所提供的一种资源调度装置的示意图；

图8示出了本公开实施例所提供的另一种资源调度装置的示意图；

图9示出了本公开实施例所提供的一种电子设备的示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

经研究发现，按照机器分组的调度方式，需要按照机器(例如，工作节点)的分组对GPU资源进行调度。一般情况下，按照机器分组的调度方式会将部署在相同机器上的GPU资源调配给资源请求端。如果机器上GPU数量较多，或者机器数量较少，则无法实现灵活对机器中的GPU资源进行调度，从而容易造成浪费机器上较多的GPU资源，例如，浪费的资源可以为无法分配给资源请求端的GPU资源。

基于上述研究，本公开提供了一种资源调度方法、装置、电子设备以及计算机可读存储介质，通过该资源调度方法，可以实现对工作节点和GPU资源进行分组部署，进而可以灵活对工作节点中部署的GPU资源进行调度，减少GPU资源碎片，从而提高GPU资源的利用率。

针对以上方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案，都应该是发明人在本公开过程中对本公开做出的贡献。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

为便于对本实施例进行理解，首先对本公开实施例所公开的一种资源调度方法进行详细介绍，本公开实施例所提供的资源调度方法的执行主体一般为具有一定计算能力的电子设备，该电子设备可以为容器集群的主节点。在一些可能的实现方式中，该资源调度方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。

下面以执行主体为终端设备为例对本公开实施例提供的资源调度方法加以说明。

实施例一

参见图1所示，为本公开实施例提供的一种资源调度方法的流程图。该资源调度方法可以应用在容器集群的主节点中，其中，该容器集群还可以包含至少一个部署有GPU资源的工作节点。

在本公开实施例中，该容器集群可以为Kubernetes容器集群，在该Kubernetes容器集群中包含主节点Master node和至少一个工作节点Work node，在每个工作节点上部署有对应的GPU资源。本公开实施所提供的方法可以应用在主节点Master node中，具体地，所述方法包括步骤S101～S105，其中：

S101：获取资源请求端发送的资源调度请求；所述资源调度请求中包含待创建的目标容器的GPU资源需求量。

在本公开实施例中，资源请求端可以为发送资源调度请求的用户，其中，该用户通过终端设备发送该资源调度请求，该终端设备可以为容器集群中的任意一个工作节点，还可以为除了主节点和工作节点之外的其他终端设备，本公开对此不作具体限定。

在一个可选的实施方式中，资源请求端编辑Pod配置文件，以通过该Pod配置文件中所包含的信息指示资源请求端所请求创建的目标容器的GPU资源需求量，其中，该GPU资源可以为物理GPU资源，还可以为虚拟GPU资源，其中，虚拟GPU资源为通过虚拟化技术对工作节点中的物理GPU资源虚拟化之后得到的GPU资源。

应理解的是，Pod是Kubernetes集群中的最小可部署单元。一个Pod代表着Kubernetes集群中运行的一个进程。Pod由一个或者多个容器组成(例如Docker容器)。

S103：响应于所述资源调度请求，获取针对所述资源请求端的资源分组信息；所述资源分组信息用于指示每个工作节点所属的资源分组，以及部署在工作节点中的GPU资源与每个工作节点的绑定关系。

在本公开实施例中，资源分组信息是用户预先设置的工作节点和GPU资源的分组信息。该资源分组信息用于指示每个工作节点所属的资源分组，以及部署在工作节点中的GPU资源与每个工作节点的绑定关系，其中，每个资源分组中对应工作节点所绑定的GPU资源的数量与资源请求端预先为目标容器设置的GPU资源的估计需求量相关联。

例如，在云计算场景中，假设，上述用户涉及多个容器的业务，此时，该用户为每个容器预先估计其所需要的GPU资源的数量，也即GPU资源的估计需求量，然后，根据该估计需求量对工作节点和GPU资源进行分组，从而得到至少一个资源分组，其中，每个资源分组中的GPU资源用于为一个或多个目标容器提供相应的GPU资源。

在本公开实施例中，若所述资源分组的数量为多个，则所述多个资源分组中任意两个资源分组中所包含的GPU资源部分相同或者完全不相同，且所述多个资源分组中任意两个资源分组所对应的工作节点相同或者不同，每个所述资源分组中与每个工作节点相绑定的GPU资源为部署在该工作节点中的GPU资源。

应理解的是，若资源请求端所请求创建的目标容器为多个，那么可以将每个资源分组中的GPU资源调度给一个或多个目标容器。

在本公开实施例中，多个资源分组中任意两个资源分组所对应的工作节点相同或者不同，一般情况下，为了避免为多个业务所调度的GPU资源出现冲突，可以设置资源分组中与每个工作节点相绑定的GPU资源为该工作节点内部署的GPU资源，其中，该冲突表示为每个业务分配的GPU资源部署在不同的工作节点上所导致的冲突。

如果工作节点中部署的GPU资源无法满足资源需求端的需求量，可以设置多个资源分组之间共享GPU资源，即多个资源分组中任意两个资源分组中所包含的GPU资源部分相同。

在本公开实施例中，通过上述处理方式，可以提高工作节点中部署的GPU资源的利用率，减小GPU资源碎片，并避免资源分组之间出现冲突的分组，以提高资源调度的可靠性和准确性。

S105：基于所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息；所述资源调度信息包括：用于创建所述目标容器的工作节点和所述目标容器所需的GPU资源。

下面将结合图2和图3对本公开实施例所提供的资源调度方法进行介绍。下面先结合图2介绍一种现有技术中基于Kubernetes容器集群的资源调度方法，该资源调度方法的具体执行过程描述如下：

首先，用户通过Pod配置文件请求使用配备有GPU资源的容器。Kubernetes容器集群的主节点检测该Pod配置文件中的信息，以根据该Pod配置文件确定用户是否在至少一个工作节点中选择了指定工作节点。若选择了指定工作节点，则Kubernetes容器集群的主节点查询该指定工作节点的GPU使用状态，其中，该GPU使用状态可以为该指定工作节点中GPU的剩余资源情况。

之后，根据资源请求端所请求的GPU资源用量和该指定工作节点中GPU的剩余资源情况，调度指定工作节点中的GPU资源。但是，采用上述调度GPU资源的方式，会产生GPU资源碎片。

例如，如图2所示的两个工作节点中，分别部署了4张GPU显卡。若用户所涉及的容器的数量为4个，且4个容器分别需要的GPU资源使用量分别为：2张卡，1张卡，2张卡，3张卡。此时，在为4个容器分配资源时，将产生如图2所示的资源分配结果。图2中位于“(1)”内的两个GPU卡调度给需求2张卡的容器，图2中位于“(2)”内的两个GPU卡调度给需求1张卡的容器，图2中位于“(3)”内的两个GPU卡调度给另一个需求2张卡的容器，图2所示的两个机器中，共剩余的GPU卡的数量为3张，其中，两张GPU卡位于一个工作节点内，另外一张GPU卡位于另外一个工作节点内。需要说明的是，由于部署在不同工作节点内的GPU无法满足调度需求，且要求分配给同一个容器的GPU卡部署在相同的工作节点中，因此，如图2所示，两个工作节点的剩余资源分别为1张卡和2张卡。此时，剩余的1张卡和2张卡无法满足需求3张卡的容器，那么剩余1张卡和2张卡即为上述所描述的GPU资源碎片。

在按照上述所描述的方式调度工作节点中的GPU资源之后，就可以根据Kubernetes容器集群中主节点的调度结果，为该容器分配相应的工作节点和GPU资源。

通过上述描述可知，上述所描述的按照机器分组进行资源调度方式，需要按照机器的分组对GPU资源进行调度，该资源调度方式并未考虑每个工作节点中所部署的GPU资源的信息。如果机器上部署的GPU数量较多，或者机器的数量较少，那么上述所描述的资源调度方法则无法实现灵活对机器中部署的GPU资源进行调度，从而容易造成机器上较多的GPU资源出现资源浪费的现象。

基于此，在本公开实施例中，提供了一种资源调度方法，该方法首先，获取资源请求端发送的资源调度请求，并响应于该资源调度请求，获取针对资源请求端的资源分组信息，进而基于GPU资源需求量和资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息。通过上述描述可知，预先为资源请求端对应设置了资源分组信息，通过该资源分组信息对工作节点和GPU资源进行分组部署的方式，可以灵活对工作节点中部署的GPU资源进行调度，减少GPU资源碎片，从而提高GPU资源的利用率。

通过上述描述可知，在本公开实施例中，资源分组信息为资源请求端预先设置的分组信息，其中，可以通过下述所描述的方式确定所述资源分组信息，如图3所示，具体包括如下过程：

步骤S301，获取所述容器集群中的工作节点列表；其中，所述工作节点列表中包含所述容器集群中所包含的至少一个工作节点的节点信息；

步骤S302，获取所述容器集群的工作节点中部署的GPU资源的GPU资源列表；所述GPU资源列表中包含工作节点中部署的GPU资源的资源状态信息；

步骤S303，基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息。

在本公开实施例中，资源请求端向容器集群的主节点发送节点列表查询请求。容器集群的主节点在获取到该节点列表查询请求之后，通过容器集群的主节点中的Kubernetes API(Application Programming Interface，应用程序编程接口)模块获取容器集群中的工作节点信息。其中，Kubernetes API模块是容器集群中的重要组成部分，Kubernetes容器集群中各种资源(对象)的数据通过Kubernetes API模块所提供的API接口提交到后端的持久化存储(etcd)中，例如，其他设备可以通过API接口查询或修改数据。通过API接口能直接操作etcd，etcd是Kubernetes容器集群中提供的默认存储系统，用于保存容器集群中所有的数据，在使用etcd时需要为etcd数据提供备份计划。因此，在本公开实施例中，Kubernetes API模块可以在etcd中获取该容器集群中的至少一个工作节点的节点信息。

在获取到该工作节点列表之后，可以继续获取在容器集群的工作节点中部署的GPU资源的GPU资源列表。具体地，可以在资源请求端上安装Nvidia工具，进而通过该Nvidia工具获取在该工作节点上部署的GPU资源的资源状态信息，其中，Nvidia工具是显卡检测和超频软件，能够支持用户检测GPU资源的名称，CPI(Clock Per Instruction，每条指令执行的时钟周期数)，渲染器、总线接口、总线宽度、显存大小、显存类型等各项信息，Nvidia工具还可以协助用户监控NVIDIA显卡的cup温度、PCB(Printed Circuit Board，印刷电路板)、电压、GPU负载、风扇等各项参数。在获取到GPU资源的资源状态信息之后，可以向容器集群的主节点反馈该GPU资源的资源状态信息，从而得到GPU资源列表。之后，就可以根据工作节点列表和所述GPU资源列表确定所述资源分组信息。

通过上述描述可知，在本公开实施例中，在设置资源分组信息时，能够以工作节点中的GPU资源为调度单位进行调度，从而进一步提高调度灵活性，从而实现用户服务与GPU资源的匹配度，提高服务性能。

在本公开实施例中，在基于工作节点列表和GPU资源列表确定资源分组信息时，可以通过自动方式确定资源分组信息，还可以通过手动方式确定资源分组信息，下面对这两种确定方式进行介绍。

方式一：自动方式。

在方式一中，步骤S303基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息，包括如下过程：

首先，获取目标分组参数，其中，所述目标分组参数包括以下至少之一：GPU资源的类型信息、GPU资源的估计需求量；

然后，按照所述目标分组参数确定所述至少一个工作节点所属的资源分组，以及确定与所属于每个资源分组中的工作节点具有绑定关系的GPU资源，从而得到所述资源分组信息。

在本公开实施例中，容器集群的Kubernetes API模块在获取到工作节点列表和GPU资源列表之后，可以获取资源请求端预先设定的目标分组参数，并根据该目标分组参数确定容器集群中每个工作节点所属的资源分组，并为该工作节点增加分组名，其中，该分组名为对应资源分组的名称。在为该工作节点增加分组名之后，可以继续根据目标分组参数建立工作节点和GPU资源之间的绑定关系。

具体地，上述GPU资源的类型信息可以为GPU资源的型号信息，还可以为GPU资源的形态信息(例如，物理GPU资源，或者，虚拟GPU资源)。

如果资源请求端所涉及的业务(或者服务)不同，那么该业务(或者服务)所需求的GPU资源的型号也可能是不相同的，且该业务(或者服务)对GPU资源的需求量也是不相同的。基于此，可以将GPU资源的类型信息和/或估计需求量作为目标分组参数，对工作节点和GPU资源进行分组得到资源分组信息。通过目标分组参数对工作节点和GPU资源进行分组的方式，能够为资源请求端所涉及的业务(或者服务)调度匹配度最高的GPU资源，从而提高了资源请求端所涉及业务(或者服务)与GPU资源之间的亲和度。

在本公开实施例中，在按照上述所描述的方式一得到资源分组信息之后，可以将该资源分组信息推送至资源请求端，以使资源请求端对该资源分组信息进行确认。在确认的过程中，资源请求端可以对该资源分组信息进行修改，因此，在本公开实施例中，在基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息之后，还可以获取所述资源请求端发送的资源分组信息的更新信息；并按照所述更新信息对所述资源分组信息进行更新，从而得到更新之后的资源分组信息。

在本公开实施例中，通过目标分组参数对工作节点和GPU资源进行分组的方式，可以提高资源分组信息的分组效率，缩短资源分组信息的分组时间。在此基础上，通过设置资源请求端对资源分组信息进行修改更新的方式，还可以进一步提高资源请求端所涉及业务(或者服务)与GPU资源之间的亲和度，从而实现个性化定制每个用户的资源分组信息。

方式二：手动方式。

在方式二中，步骤S303基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息，具体包括如下过程：

首先，获取所述资源请求端发送的分组指示信息，其中，所述分组指示信息用于指示每个工作节点所属的资源分组，以及指示所述GPU资源列表中的每个GPU资源和每个工作节点之间的绑定关系；

然后，按照所述分组指示信息对所述工作节点和所述工作节点内部署的GPU资源进行分组，得到所述资源分组信息。

在本公开实施例中，用户可以向容器集群的Kubernetes API模块发送相应的分组指示信息，其中，该分组指示信息中可以包含对应工作节点的分组名(即，所属资源分组的名称信息)，以及与该工作节点具有绑定关系的GPU资源的资源信息等。

容器集群的Kubernetes API模块在获取到该分组指示信息之后，就可以为对应的工作节点增加对应的分组名，并建立该工作节点与对应的GPU资源之间的绑定关系。

通过上述描述可知，在本公开实施例中，通过上述所描述的用户自定义资源分组信息的方式，可以为用户所涉及的业务(或者服务)调度匹配度最高的GPU资源，从而提高了资源请求端所涉及业务(或者服务)与GPU资源之间的亲和度。

在本公开实施例中，在容器集群的至少一个工作节点中，资源请求端对部分工作节点(或者工作节点中的部分GPU资源)具有修改权限，其中，若资源请求端对该工作节点(或者工作节点中的部分GPU资源)具有修改权限，则资源请求端对该工作节点具有分组权限，否则，资源请求端对该工作节点不具备分组权限。

基于此，在本公开实施例中，在基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息之前，还可以按照分组权限信息对所述工作节点列表中的工作节点和/或所述GPU资源列表中的GPU资源进行过滤；其中，所述分组权限信息用于指示所述资源请求端对每个工作节点和/或每个工作节点中部署的GPU资源的操作权限。

在本公开实施例中，可以过滤至少一个工作节点中资源请求端不具备修改权限的工作节点。除此之外，在本公开实施例中，还可以过滤每个工作节点中资源请求端不具备修改权限的GPU资源，从而得到过滤之后的工作节点列表和过滤之后的GPU资源列表。之后，就可以基于过滤之后的所述工作节点列表和过滤之后的所述GPU资源列表确定所述资源分组信息。

在基于过滤之后的所述工作节点列表和过滤之后的所述GPU资源列表确定资源分组信息时，可以按照上述所描述的方式一或者方式二所描述的方式确定资源分组信息，本公开实施不再详细赘述。

通过上述描述可知，在本公开实施例中，通过分组权限信息对工作节点列表中的工作节点和/或GPU资源列表中的GPU资源进行过滤的方式，可以过滤掉资源请求端不具备分组权限的工作节点或者GPU资源，从而提高工作节点和GPU资源的分组效率。

在本公开实施例中，在按照上述所描述的方式确定资源分组信息之后，容器集群的Kubernetes API模块可以查询扩展调度器Scheduler Extender中是否包含该资源请求端的历史资源分组信息。若包含，则通过Informer机制将历史资源分组信息覆盖为上述确定出的资源分组信息，若不包含，则在扩展调度器Scheduler Extender中保存上述确定出的资源分组信息。

在本公开实施例中，在扩展调度器Scheduler Extender中更新或者保存该资源分组信息之后，资源请求端可以编辑Pod配置文件，其中，Pod配置文件中可以指示资源请求端所请求的目标容器的GPU资源需求量。之后，资源请求端就可以在Kubernetes容器集群的Label或者Annotation处加入资源分组信息，其中，Label或者Annotation表示为键值对，该键值对中的关键字表示资源请求端的身份信息，该键值对中的数值表示该资源分组信息的标识信息。

在编辑得到Pod配置文件，并在Label或者Annotation处加入资源分组信息之后，资源请求端就可以向Kubernetes容器集群发送资源调度请求，Kubernetes容器集群的Kubernetes API模块在获取到该资源调度请求之后，将该资源调度请求转发至Kubernetes容器集群的Kubernetes默认调度器，以使Kubernetes默认调度器转发该资源调度请求至扩展调度器Scheduler Extender。扩展调度器Scheduler Extender在获取到该资源调度请求之后，就可以基于所述GPU资源需求量和所述资源分组信息所指示的至少一个资源分组的GPU资源剩余量确定资源调度信息。之后，扩展调度器Scheduler Extender将资源调度信息反馈至Kubernetes默认调度器，从而Kubernetes默认调度器为目标容器分配工作节点和GPU资源。

在一个可选的实施方式中，步骤S105，基于所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息，包括如下过程：

根据所述GPU资源剩余量大于或者等于所述GPU资源需求量的资源分组确定资源调度信息。

具体地，在本公开实施例中，可以在至少一个资源分组中确定GPU资源剩余量大于或者等于GPU资源需求量的资源分组，并根据该资源分组确定资源调度信息。

除此之外，还可以为每个资源分组设置对应的容器标识，其中，该容器标识用于指示每个资源分组所对应的目标容器。在获取到该资源调度请求之后，可以根据该容器标识查询与目标容器相匹配的资源分组，并在确定出该资源分组中GPU资源剩余量大于或者等于所述GPU资源需求量的情况下，将根据该资源分组确定资源调度信息。

需要说明的是，如果至少一个资源分组中包含多个GPU资源剩余量大于或者等于所述GPU资源需求量的资源分组，则可以在多个资源分组中确定GPU资源剩余量与GPU资源需求量之间差距最小的资源分组，进而根据该差距最小的资源分组确定资源调度信息。

通过上述描述可知，在本公开实施例中，根据GPU资源剩余量大于或者等于GPU资源需求量的资源分组确定资源调度信息的方式，能够快速的为目标容器确定出与之相匹配的工作节点和GPU资源，还可以减少GPU资源碎片，从而提高GPU资源的利用率。

在另一个可选的实施方式中，该方法还包括：获取所述目标容器所需GPU资源的目标类型信息。进而，在所述资源分组中确定包含类型信息为所述目标类型信息的GPU资源的备选资源分组；基于所述GPU资源需求量和资源分组的GPU资源剩余量在所述备选资源分组中确定所述目标资源分组；根据所述目标资源分组确定所述资源调度信息。

通过上述描述可知，可以按照目标分组参数对工作节点和GPU进行分组，其中，所述目标分组参数包括GPU资源的类型信息。因此，在按照目标分组参数分组得到资源分组信息之后，每个资源分组都包含对应的GPU资源的类型信息，其中，该类型信息可以为GPU的型号信息，还可以为GPU资源的形态信息(例如，物理GPU资源，或者，虚拟GPU资源)。

因此，在本公开实施例中，可以在确定资源调度信息之前，获取目标容器所需GPU资源的目标类型信息，例如，目标型号信息，或者，目标形态信息。在确定出目标类型信息之后，可以在至少一个资源分组中确定包含类型信息为目标类型信息的GPU资源的资源分组，并将确定出的资源分组作为备选资源分组。之后，就可以在备选资源分组中确定目标资源分组，例如，可以将备选资源分组中GPU资源剩余量大于或者等于所述GPU资源需求量的资源分组为目标资源分组，最后，就可以根据该目标资源分组确定资源调度信息。

除此之外，还可以为每个资源分组设置对应的容器标识，其中，该容器标识用于指示每个资源分组所对应的目标容器。在获取到该资源调度请求之后，可以根据该容器标识查询与目标容器相匹配的资源分组，然后，在相匹配的资源分组中确定包含类型信息为目标类型信息的GPU资源的资源分组，并将确定出的资源分组作为备选资源分组。进而，在备选资源分组中确定目标资源分组，例如，可以将备选资源分组中GPU资源剩余量大于或者等于所述GPU资源需求量的资源分组为目标资源分组，最后，就可以根据该目标资源分组确定资源调度信息。

通过上述描述可知，在本公开实施例中，通过结合GPU资源的目标类型信息来确定目标资源分组的方式，可以得到与目标容器匹配度更高的资源分组，从而提高了目标容器和GPU资源之间的亲和性，同时还可以避免GPU碎片的产生，并提高资源利用率。

在一个可选的实施方式中，步骤S105，基于所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息，包括如下过程：

(1)、获取预先为所述资源请求端设定的GPU资源的资源上限值，并获取所述资源请求端的已分配GPU资源的数量；

(2)、基于所述资源上限值和所述已分配GPU资源的数量确定GPU的实际调度数量；

(3)、按照所述实际调度数量、所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定所述资源调度信息。

在本公开实施例中，Kubernetes容器集群预先为资源请求端设置其所能使用GPU资源的资源上限值。在确定资源调度信息时，可以首先获取该资源上限值，并获取已经为该资源请求端调度的GPU资源的数量(即，上述已分配GPU资源的数量)。之后，就可以根据该资源上限值和已分配GPU资源的数量，确定为该资源请求端调度的GPU资源的实际调度数量，例如，可以将资源上限值减去已分配GPU资源的数量，从而得到实际调度数量，之后，就可以按照实际调度数量确定资源调度信息，从而调整针对该目标容器的调度策略。

通过上述描述可知，在本公开实施例中，通过为Kubernetes容器集群中的工作节点(Node)增加资源分组信息的方式，可以使Kubernetes容器集群在调度GPU资源时，能够感知资源分组信息，并针对资源分组信息调整调度策略。

实施例二

下面将结合如4和图5对上述资源调度方法进行介绍，如图4和图5所示，该方法包括如下过程：

1、用户通过Kubernetes API查询得到工作节点列表；其中，用户向容器集群的主节点发送节点列表查询请求。容器集群的主节点在获取到该节点列表查询请求之后，通过容器集群的Kubernetes API模块获取容器集群中的工作节点信息。其中，Kubernetes API模块是容器集群中的重要组成部分，Kubernetes容器集群中各种资源(对象)的数据通过Kubernetes API模块所提供的API接口提交到后端的持久化存储(etcd)中，例如，其他设备可以通过API接口查询或修改数据。通过API接口能直接操作etcd，etcd是Kubernetes容器集群中提供的默认存储系统，用于保存容器集群中所有的数据，在使用etcd时需要为etcd数据提供备份计划。因此，在本公开实施例中，Kubernetes API模块可以在etcd中获取该容器集群中的至少一个工作节点的节点信息。

2、用户通过Nvidia工具查询得到GPU资源列表；具体地，还可以在资源请求端上安装Nvidia工具，进而通过该Nvidia工具获取该工作节点上部署的GPU资源的资源状态信息，其中，Nvidia工具是显卡检测和超频软件，能够支持用户检测GPU资源的名称，CPI，渲染器、总线接口、总线宽度、显存大小、显存类型等各项信息，Nvidia工具还可以协助用户监控NVIDIA显卡的cup温度、PCB、电压、GPU负载、风扇等各项参数。在获取到GPU资源的资源状态信息之后，可以向容器集群的主节点反馈该GPU资源的资源状态信息，从而得到GPU资源列表。

3、用户通过Kubernetes API模块为工作节点列表中的工作节点增加分组名和GPU资源绑定关系，得到资源分组信息。

4、容器集群的Kubernetes API模块可以查询扩展调度器Scheduler Extender中是否包含该资源请求端的历史资源分组信息。若包含，则通过Informer机制将历史资源分组信息覆盖为上述确定出的资源分组信息，若不包含，则在扩展调度器SchedulerExtender中保存上述确定出的资源分组信息。

5、用户编辑Pod配置文件，其中，Pod配置文件中可以指示资源请求端所请求创建的目标容器的GPU资源需求量。之后，用户就可以在Kubernetes容器集群的Label或者Annotation处加入资源分组信息，其中，Label或者Annotation是键值对，该键值对中的关键字表示资源请求端的身份信息，该键值对中的数值表示该资源分组信息的标识信息。

6、用户向Kubernetes容器集群发送资源调度请求，Kubernetes容器集群的Kubernetes API模块在获取到该资源调度请求之后，将该资源调度请求转发至Kubernetes容器集群中的Kubernetes默认调度器。

7、Kubernetes默认调度器转发该资源调度请求至扩展调度器SchedulerExtender。

8、扩展调度器Scheduler Extender在获取到该资源调度请求之后，就可以基于所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息。

9、Kubernetes默认调度器根据扩展调度器Scheduler Extender返回的资源调度信息，为目标容器分配工作节点和GPU资源。

通过上述描述可知，在本公开实施例中，资源请求端能够以工作节点上的GPU资源为调度单位进行容器调度，进一步提高了调度的灵活性，从而提高了资源请求端的服务与GPU资源的亲和性，并提高服务性能；资源请求端还能够通过设置资源分组信息的方式规划GPU资源的用量，最大可能的利用每个工作节点中GPU资源的全部资源，进一步提高资源利用率，降低成本。

本公开实施例所提供的资源调度信息可以应用在云计算场景中。例如，在云计算场景中的一台宿主机包含有多张不同型号的GPU卡，采用本公开实施例所提供的方法确定资源调度信息，可以在多张不同型号的GPU卡中为容器调度型号最匹配的GPU资源。又例如，在云计算场景中，用户所涉及的多个业务可以共享Kubernetes容器集群中的GPU资源，采用本公开实施例所提供的方法，以GPU资源为调度单位进行容器调度，能够避免GPU资源在调度时出现资源冲突，从而实现对不同业务的容器进行隔离的目的。又例如，在云计算场景中，采用本公开实施例所提供的方法，还可以将关联密切或者GPU资源占用率低的服务运行在同一个工作节点上，从而提高性能，降低成本。

实施例三：

参见图6所示，为本公开实施例提供的另一种资源调度方法的流程图。该资源调度方法可以应用于容器集群的中部署有GPU的工作节点，包括如下步骤：

步骤S601，获取资源请求端所请求的资源调度信息；所述资源调度信息包括：用于创建目标容器的目标工作节点和所述目标容器所需的GPU资源；其中，GPU资源包括以下类型的资源：物理GPU资源和/或虚拟GPU资源，其中，所述虚拟GPU资源为通过对所述工作节点中的物理GPU资源虚拟化之后得到的GPU资源。所述资源调度信息为通过上述实施例一中任一项所述的方法确定出的信息。

步骤S603，按照所述资源调度信息中的指示，在所述目标工作节点上创建所述目标容器，并基于所述资源调度信息中指示的GPU资源为所述目标容器提供相应的处理资源。

通过上述描述可知，通过该资源分组信息对工作节点和GPU资源进行分组部署的方式，可以灵活对工作节点中部署的GPU资源进行调度，减少GPU资源碎片，从而提高GPU资源的利用率。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

基于同一发明构思，本公开实施例中还提供了与资源调度方法对应的资源调度装置，由于本公开实施例中的装置解决问题的原理与本公开实施例上述资源调度方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

实施例四：

参照图7所示，为本公开实施例提供的一种资源调度装置的架构示意图，所述装置包括：第一获取单元71、第二获取单元72、确定单元73；其中，

第一获取单元71，用于获取资源请求端发送的资源调度请求；所述资源调度请求中包含待创建的目标容器的GPU资源需求量；

第二获取单元72，用于响应于所述资源调度请求，获取针对所述资源请求端的资源分组信息；所述资源分组信息用于指示每个工作节点所属的资源分组，以及部署在工作节点中的GPU资源与每个工作节点的绑定关系；

确定单元73，用于基于所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息；所述资源调度信息包括：用于创建所述目标容器的工作节点和所述目标容器所需的GPU资源。

在本公开实施例中，首先，获取资源请求端发送的资源调度请求，并响应于资源调度请求，获取针对资源请求端的资源分组信息，进而基于GPU资源需求量和资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息。通过上述描述可知，预先为资源请求端对应设置了资源分组信息，通过该资源分组信息对工作节点和GPU资源进行分组部署的方式，可以灵活对工作节点中部署的GPU资源进行调度，减少GPU资源碎片，从而提高GPU资源的利用率。

一种可能的实施方式中，若所述资源分组的数量为多个，则所述多个资源分组中任意两个资源分组中所包含的GPU资源部分相同或者完全不相同，所述多个资源分组中任意两个资源分组所对应的工作节点相同或者不同，且所述资源分组中与每个工作节点相绑定的GPU资源为部署在该工作节点中的GPU资源。

一种可能的实施方式中，确定单元，用于：获取所述资源分组所对应的容器标识，其中，所述容器标识用于指示每个资源分组所对应的目标容器；根据所述容器标识在所述资源分组中确定与所述目标容器相匹配的资源分组；若所述相匹配的资源分组的GPU资源剩余量大于或者等于所述GPU资源需求量，则根据所述相匹配的资源分组确定所述资源调度信息。

一种可能的实施方式中，该装置还用于：获取所述目标容器所需GPU资源的目标类型信息；确定单元，还用于：在所述资源分组中确定包含类型信息为所述目标类型信息的GPU资源的备选资源分组；基于所述GPU资源需求量和所述资源分组的GPU资源剩余量在所述备选资源分组中确定目标资源分组；根据所述目标资源分组确定所述资源调度信息。

一种可能的实施方式中，所述GPU资源包括以下类型的资源：物理GPU资源和/或虚拟GPU资源，其中，所述虚拟GPU资源为通过对所述工作节点中的物理GPU资源虚拟化之后得到的GPU资源。

一种可能的实施方式中，该装置还用于通过以下步骤确定所述资源分组信息：获取所述容器集群中的工作节点列表；其中，所述工作节点列表中包含所述容器集群中所包含的至少一个工作节点的节点信息；获取所述容器集群的工作节点中部署的GPU资源的GPU资源列表；所述GPU资源列表中包含工作节点中部署的GPU资源的资源状态信息；基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息。

一种可能的实施方式中，该装置还用于：获取目标分组参数，其中，所述目标分组参数包括以下至少之一：GPU资源的类型信息、GPU资源的估计需求量；按照所述目标分组参数确定所述至少一个工作节点所属的资源分组，以及确定与所属于每个资源分组中的工作节点具有绑定关系的GPU资源，从而得到所述资源分组信息。

一种可能的实施方式中，该装置还用于在基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息之后，获取所述资源请求端发送的资源分组信息的更新信息；按照所述更新信息对所述资源分组信息进行更新。

一种可能的实施方式中，该装置还用于获取所述资源请求端发送的分组指示信息，其中，所述分组指示信息用于指示每个工作节点所属的资源分组，以及指示所述GPU资源列表中的每个GPU资源和每个工作节点之间的绑定关系；按照所述分组指示信息对所述工作节点和所述工作节点内部署的GPU资源进行分组，得到所述资源分组信息。

一种可能的实施方式中，该装置还用于在基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息之前，按照分组权限信息对所述工作节点列表中的工作节点和/或所述GPU资源列表中的GPU资源进行过滤；其中，所述分组权限信息用于指示所述资源请求端对每个工作节点和/或每个工作节点中部署的GPU资源的操作权限；基于过滤之后的所述工作节点列表和过滤之后的所述GPU资源列表确定所述资源分组信息。

一种可能的实施方式中，确定单元，还用于：获取预先为所述资源请求端设定的GPU资源的资源上限值，并获取所述资源请求端的已分配GPU资源的数量；基于所述资源上限值和所述已分配GPU资源的数量确定GPU的实际调度数量；按照所述实际调度数量、所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定所述资源调度信息。

实施例五：

参照图8所示，为本公开实施例提供的一种资源调度装置的架构示意图，所述装置包括：第三获取单元81、创建单元82；其中，

第三获取单元81，用于获取资源请求端所请求的资源调度信息；所述资源调度信息包括：用于创建目标容器的目标工作节点和所述目标容器所需的GPU资源；所述资源调度信息为通过上述实施例一中任一项所述的方法确定出的信息；

创建单元82，用于按照所述资源调度信息中的指示，在所述目标工作节点上创建所述目标容器，并基于所述资源调度信息中指示的GPU资源为所述目标容器提供相应的处理资源。

通过上述描述可知，通过该资源分组信息对工作节点和GPU资源进行分组部署的方式，可以灵活对工作节点中部署的GPU资源进行调度，减少GPU资源碎片，从而提高GPU资源的利用率。

一种可能的实施方式中，所述GPU资源包括以下类型的资源：物理GPU资源和/或虚拟GPU资源，其中，所述虚拟GPU资源为通过对所述工作节点中的物理GPU资源虚拟化之后得到的GPU资源。

实施例六：

基于同一技术构思，本公开实施例还提供了一种电子设备。参照图9所示，为本公开实施例提供的电子设备900的结构示意图，包括处理器901、存储器902、和总线903。其中，存储器902用于存储执行指令，包括内存9021和外部存储器9022；这里的内存9021也称内存储器，用于暂时存放处理器901中的运算数据，以及与硬盘等外部存储器9022交换的数据，处理器901通过内存9021与外部存储器9022进行数据交换，当电子设备900运行时，处理器901与存储器902之间通过总线903通信，使得处理器901在执行以下指令：

获取资源请求端发送的资源调度请求；所述资源调度请求中包含待创建的目标容器的GPU资源需求量；响应于所述资源调度请求，获取针对所述资源请求端的资源分组信息；所述资源分组信息用于指示每个工作节点所属的资源分组，以及部署在工作节点中的GPU资源与每个工作节点的绑定关系；基于所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确资源调度信息；所述资源调度信息包括：用于创建所述目标容器的工作节点和所述目标容器所需的GPU资源。

本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例中所述的资源调度方法的步骤。其中，该存储介质可以是易失性或非易失的计算机可读取存储介质。

本公开实施例所提供的资源调度方法的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行上述方法实施例中所述的资源调度方法的步骤，具体可参见上述方法实施例，在此不再赘述。

本公开实施例还提供一种计算机程序，该计算机程序被处理器执行时实现前述实施例的任意一种方法。该计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software DevelopmentKit，SDK)等等。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台电子设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应所述以权利要求的保护范围为准。

Claims (17)

1.一种资源调度方法，其特征在于，应用于容器集群的主节点，所述容器集群还包含至少一个部署有GPU的工作节点，包括：

获取资源请求端发送的资源调度请求；所述资源调度请求中包含待创建的目标容器的GPU资源需求量；

响应于所述资源调度请求，获取针对所述资源请求端的资源分组信息；所述资源分组信息用于指示每个工作节点所属的资源分组，以及部署在工作节点中的GPU资源与每个工作节点的绑定关系；

基于所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息；所述资源调度信息包括：用于创建所述目标容器的工作节点和所述目标容器所需的GPU资源。

2.根据权利要求1所述的方法，其特征在于，若所述资源分组的数量为多个，则多个资源分组中任意两个资源分组中所包含的GPU资源部分相同或者完全不相同，所述多个资源分组中任意两个资源分组所对应的工作节点相同或者不同，且所述资源分组中与每个工作节点相绑定的GPU资源为部署在该工作节点中的GPU资源。

3.根据权利要求1或2所述的方法，其特征在于，基于所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息，包括：

获取所述资源分组所对应的容器标识，其中，所述容器标识用于指示每个资源分组所对应的目标容器；

根据所述容器标识在所述资源分组中确定与所述目标容器相匹配的资源分组；

若所述相匹配的资源分组的GPU资源剩余量大于或者等于所述GPU资源需求量，则根据所述相匹配的资源分组确定所述资源调度信息。

4.根据权利要求1至3中任一项所述的方法，其特征在于，

所述方法还包括：获取所述目标容器所需GPU资源的目标类型信息；

基于所述GPU资源需求量和资源分组的GPU资源剩余量确定资源调度信息，包括：在所述资源分组中确定包含类型信息为所述目标类型信息的GPU资源的备选资源分组；基于所述GPU资源需求量和所述GPU资源剩余量在所述备选资源分组中确定目标资源分组；根据所述目标资源分组确定所述资源调度信息。

5.根据权利要求1至4中任一项所述的方法，其特征在于，所述GPU资源包括以下类型的资源：物理GPU资源和/或虚拟GPU资源，其中，所述虚拟GPU资源为通过对所述工作节点中的物理GPU资源虚拟化之后得到的GPU资源。

6.根据权利要求1至5中任一项所述的方法，其特征在于，所述方法还包括通过以下步骤确定所述资源分组信息：

获取所述容器集群中的工作节点列表；其中，所述工作节点列表中包含所述容器集群中所包含的至少一个工作节点的节点信息；

获取所述容器集群的工作节点中部署的GPU资源的GPU资源列表；所述GPU资源列表中包含工作节点中部署的GPU资源的资源状态信息；

基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息。

7.根据权利要求6所述的方法，其特征在于，基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息，包括：

获取目标分组参数，其中，所述目标分组参数包括以下至少之一：GPU资源的类型信息、GPU资源的估计需求量；

按照所述目标分组参数确定所述至少一个工作节点所属的资源分组，以及确定与所属于每个资源分组中的工作节点具有绑定关系的GPU资源，从而得到所述资源分组信息。

8.根据权利要求6或7所述的方法，其特征在于，所述方法还包括：

在基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息之后，获取所述资源请求端发送的资源分组信息的更新信息；

按照所述更新信息对所述资源分组信息进行更新。

9.根据权利要求6所述的方法，其特征在于，基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息，包括：

获取所述资源请求端发送的分组指示信息，其中，所述分组指示信息用于指示每个工作节点所属的资源分组，以及指示所述GPU资源列表中的每个GPU资源与每个工作节点之间的绑定关系；

按照所述分组指示信息对所述工作节点和所述工作节点内部署的GPU资源进行分组，得到所述资源分组信息。

10.根据权利要求6或9所述的方法，其特征在于，在基于所述工作节点列表和所述GPU资源列表确定所述资源分组信息之前，所述方法还包括：

按照分组权限信息对所述工作节点列表中的工作节点和/或所述GPU资源列表中的GPU资源进行过滤；其中，所述分组权限信息用于指示所述资源请求端对每个工作节点和/或每个工作节点中部署的GPU资源的操作权限；

基于过滤之后的所述工作节点列表和过滤之后的所述GPU资源列表确定所述资源分组信息。

11.根据权利要求1所述的方法，其特征在于，基于所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息，包括：

获取预先为所述资源请求端设定的GPU资源的资源上限值，并获取所述资源请求端的已分配GPU资源的数量；

基于所述资源上限值和所述已分配GPU资源的数量确定GPU的实际调度数量；

按照所述实际调度数量、所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定所述资源调度信息。

12.一种资源调度方法，其特征在于，应用于容器集群的中部署有GPU的工作节点，包括：

获取资源请求端所请求的资源调度信息；所述资源调度信息包括：用于创建目标容器的目标工作节点和所述目标容器所需的GPU资源；所述资源调度信息为通过上述权利要求1至11中任一项所述的方法确定出的信息；

按照所述资源调度信息中的指示，在所述目标工作节点上创建所述目标容器，并基于所述资源调度信息中指示的GPU资源为所述目标容器提供相应的处理资源。

13.根据权利要求12所述的方法，其特征在于，所述GPU资源包括以下类型的资源：物理GPU资源和/或虚拟GPU资源，其中，所述虚拟GPU资源为通过对所述工作节点中的物理GPU资源虚拟化之后得到的GPU资源。

14.一种资源调度装置，其特征在于，设置于容器集群的主节点，所述容器集群还包含至少一个部署有GPU的工作节点，包括：

第一获取单元，用于获取资源请求端发送的资源调度请求；所述资源调度请求中包含待创建的目标容器的GPU资源需求量；

第二获取单元，用于响应于所述资源调度请求，获取针对所述资源请求端的资源分组信息；所述资源分组信息用于指示每个工作节点所属的资源分组，以及部署在工作节点中的GPU资源与每个工作节点的绑定关系；

确定单元，用于基于所述GPU资源需求量和所述资源分组信息所指示的资源分组的GPU资源剩余量确定资源调度信息；所述资源调度信息包括：用于创建所述目标容器的工作节点和所述目标容器所需的GPU资源。

15.一种资源调度装置，其特征在于，设置于容器集群的中部署有GPU的工作节点，包括：

第三获取单元，用于获取资源请求端所请求的资源调度信息；所述资源调度信息包括：用于创建目标容器的目标工作节点和所述目标容器所需的GPU资源；所述资源调度信息为通过上述权利要求1至11中任一项所述的方法确定出的信息；

创建单元，用于按照所述资源调度信息中的指示，在所述目标工作节点上创建所述目标容器，并基于所述资源调度信息中指示的GPU资源为所述目标容器提供相应的处理资源。

16.一种电子设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1至13任一所述的资源调度方法的步骤。

17.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至13任意一项所述的资源调度方法的步骤。

Images