CN111880936A - 资源调度方法、装置、容器集群、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种资源调度方法、装置、容器集群、计算机设备和存储介质。所述方法包括：获取Pod配置文件，所述Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；基于所述GPU资源份额以及各所述子节点中的GPU剩余资源份额，从各所述子节点中确定目标子节点，并从所述目标子节点包括的GPU中确定为所述目标容器提供计算服务的目标GPU；根据所述目标子节点和所述目标GPU更新所述Pod配置文件，得到更新后的Pod配置文件，所述更新后的Pod配置文件用于指示所述目标子节点创建所述目标容器，并按照所述GPU资源份额为所述目标容器分配处理资源。采用本方法能够提升容器集群中子节点的GPU的利用率。

Description

资源调度方法、装置、容器集群、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种资源调度方法、装置、容器集群、计算机设备和存储介质。

背景技术

容器集群是为容器化的应用程序创建和部署的集群。以Kubernetes为例，Kubernetes是一个开源的、用于自动部署、扩展和管理容器化应用程序的集群，Kubernetes集群目前缺省支持CPU、内存两种资源。

GPU(Graphics Processing Unit，图形处理器)作为显卡的核心，不仅可以实现图像加速以及实时处理功能，而且已发展成为一种高度可编程的并行处理组件。得益于GPU高效的处理能力，在实际应用中能够快速进行大量计算密集型任务，例如训练神经网络等。目前，Kubernetes集群支持对子节点上的GPU进行管理，每个容器能够占用一个或者多个GPU。

但是，上述一个容器单独占用一个GPU的方式，只有在该容器生命周期结束后，其它容器才可以使用该GPU的资源，这就导致GPU的利用率低，造成GPU资源的浪费。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提升容器集群中子节点的GPU的利用率的资源调度方法、装置、容器集群、计算机设备和存储介质。

第一方面，本申请实施例提供一种资源调度方法，应用于容器集群中的主节点，所述容器集群还包括至少一个部署有GPU的子节点，所述方法包括：

获取Pod配置文件，所述Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；

基于所述GPU资源份额以及各所述子节点中的GPU剩余资源份额，从各所述子节点中确定目标子节点，并从所述目标子节点包括的GPU中确定为所述目标容器提供计算服务的目标GPU；

根据所述目标子节点和所述目标GPU更新所述Pod配置文件，得到更新后的Pod配置文件，所述更新后的Pod配置文件用于指示所述目标子节点创建所述目标容器，并按照所述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更新所述Pod配置文件，得到更新后的Pod配置文件，包括：

将所述目标子节点的节点标识和所述目标GPU的GPU标识添加至所述Pod配置文件中，得到所述更新后的Pod配置文件。

在其中一个实施例中，所述Pod配置文件包括resources字段，所述resources字段包括处理资源份额申请信息，所述处理资源份额申请信息表征所述目标容器所需占用的所述GPU资源份额。

第二方面，本申请实施例提供一种资源调度方法，应用于容器集群中的目标子节点，所述目标子节点部署有GPU，所述容器集群还包括主节点，所述方法包括：

获取更新后的Pod配置文件，所述更新后的Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；

按照所述更新后的Pod配置文件的指示，创建所述目标容器，并通过所述目标子节点的GPU中的目标GPU，为所述目标容器提供与所述GPU资源份额对应的处理资源。

在其中一个实施例中，所述更新后的Pod配置文件包括所述目标GPU的GPU标识，所述按照所述更新后的Pod配置文件的指示，创建所述目标容器，并通过所述目标子节点的GPU中的目标GPU，为所述目标容器提供与所述GPU资源份额对应的处理资源，包括：

在所述更新后的Pod配置文件中添加环境变量字段，并将所述环境变量的值设置为所述目标GPU的GPU标识，得到目标Pod配置文件；

根据所述目标Pod配置文件创建所述目标容器，并根据所述GPU标识从所述目标子节点的GPU中确定所述目标GPU，通过所述目标GPU为所述目标容器提供与所述GPU资源份额对应的处理资源。

第三方面，本申请实施例提供一种资源调度装置，设置于容器集群中的主节点，所述容器集群还包括至少一个部署有GPU的子节点，所述装置包括：

获取模块，用于获取Pod配置文件，所述Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；

调度模块，用于基于所述GPU资源份额以及各所述子节点中的GPU剩余资源份额，从各所述子节点中确定目标子节点，并从所述目标子节点包括的GPU中确定为所述目标容器提供计算服务的目标GPU；

绑定模块，用于根据所述目标子节点和所述目标GPU更新所述Pod配置文件，得到更新后的Pod配置文件，所述更新后的Pod配置文件用于指示所述目标子节点创建所述目标容器，并按照所述GPU资源份额为所述目标容器分配处理资源。

第四方面，本申请实施例提供一种资源调度装置，设置于容器集群中的目标子节点，所述目标子节点部署有GPU，所述容器集群还包括主节点，所述装置包括：

获取模块，用于获取更新后的Pod配置文件，所述更新后的Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；

创建模块，用于按照所述更新后的Pod配置文件的指示，创建所述目标容器，并通过所述目标子节点的GPU中的目标GPU，为所述目标容器提供与所述GPU资源份额对应的处理资源。

第五方面，本申请实施例提供一种容器集群，所述容器集群包括主节点和至少一个部署有GPU的子节点；

所述主节点，用于执行上述第一方面的资源调度方法的步骤；

所述子节点，用于执行上述第二方面的资源调度方法的步骤。

第六方面，本申请实施例提供一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面的方法的步骤，或者，所述处理器执行所述计算机程序时实现如上述第二方面的方法的步骤。

第七方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面的方法的步骤，或者，所述计算机程序被处理器执行时实现如上述第二方面的方法的步骤。

本申请实施例提供的技术方案带来的有益效果至少包括：

容器集群中的主节点获取Pod配置文件，该Pod配置文件包括待创建的目标容器所需占用的GPU资源份额，主节点基于GPU资源份额以及各子节点中的GPU剩余资源份额，从各子节点中确定目标子节点，并从目标子节点包括的GPU中确定为目标容器提供计算服务的目标GPU，主节点根据目标子节点和目标GPU更新Pod配置文件，得到更新后的Pod配置文件，该更新后的Pod配置文件用于指示目标子节点创建目标容器，并按照GPU资源份额为目标容器分配处理资源。由此，主节点可以按照目标容器所需占用的GPU资源份额，对子节点的GPU的处理资源进行份额调度，即目标容器可以通过GPU资源份额的形式申请一个GPU的部分处理资源，这样，即使目标容器还在运行，其它容器也可以申请这个GPU剩余的处理资源，从而避免了GPU处理资源的浪费，提升了GPU的利用率。

附图说明

图1为一个实施例中资源调度方法的应用环境图；

图2为一个实施例中资源调度方法的流程示意图；

图3为另一个实施例中步骤S200的部分流程示意图；

图4为另一个实施例中步骤S200的部分流程示意图；

图5为另一个实施例中资源调度方法的流程示意图；

图6为另一个实施例中资源调度方法的流程示意图；

图7为一种示例性的Kubernetes集群的主节点和目标子节点的内部结构示意图；

图8为一个实施例中资源调度装置的结构框图；

图9为一个实施例中资源调度装置的结构框图；

图10为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

容器集群是为容器化的应用程序创建和部署的集群。以Kubernetes为例，Kubernetes是一个用于管理容器化应用程序的集群。在Kubernetes集群中，主节点(Master节点)是集群的控制节点，负责整个集群的管理和控制。针对集群执行的控制命令都是发送给主节点的。子节点(Node节点)是集群中的工作负载节点，子节点上的工作负载由主节点分配。

Kubernetes集群目前缺省支持CPU和内存两种资源。为了满足用户需求，实现其他硬件类型资源的调度分配，Kubernetes集群实现了插件框架(Devide Plugin Framework)来用于其他类型的资源集成。

GPU(Graphics Processing Unit，图形处理单元)作为显卡的核心，不仅可以实现图像加速以及实时处理功能，而且已发展成为一种高度可编程的并行处理组件。得益于GPU高效的处理能力，在实际应用中能够快速进行大量计算密集型任务，例如训练神经网络等，因此，用户对GPU的需求越来越强烈。目前Kubernetes集群支持对子节点上的GPU进行管理调度，每个容器能够占用一个或者多个GPU。

然而，上述一个容器单独占用一个GPU的方式，只有在该容器生命周期结束后，其它容器才可以使用该GPU的处理资源，这就导致GPU的利用率低，造成GPU资源的浪费。

考虑到以上情况，本申请实施例提供了一种资源调度方法、装置、容器集群、计算机设备和存储介质。在该方法中，容器集群中的主节点获取Pod配置文件，该Pod配置文件包括待创建的目标容器所需占用的GPU资源份额，主节点基于GPU资源份额以及各子节点中的GPU剩余资源份额，从各子节点中确定目标子节点，并从目标子节点包括的GPU中确定为目标容器提供计算服务的目标GPU，主节点根据目标子节点和目标GPU更新Pod配置文件，得到更新后的Pod配置文件，该更新后的Pod配置文件用于指示目标子节点创建目标容器，并按照GPU资源份额为目标容器分配处理资源。由此，主节点可以按照目标容器所需占用的GPU资源份额，对子节点的GPU的处理资源进行份额调度，即目标容器可以通过GPU资源份额的形式申请一个GPU的部分处理资源，这样，即使目标容器还在运行，其它容器也可以申请这个GPU剩余的处理资源，从而避免了GPU处理资源的浪费，提升了GPU的利用率。

下面，将对本申请实施例提供的资源调度方法所涉及到的实施环境进行简要说明。

如图1所示，该实施环境可以包括主节点102和至少一个部署有GPU的子节点104，其中，GPU(Graphics Processing Unit)为图形处理单元。主节点102可以通过网络与各子节点104通信，各子节点104也均可以通过网络与主节点102进行通信。

其中，主节点102和子节点104均可以是服务器。服务器可以是塔式服务器、机架服务器、刀片式服务器、高密度服务器、单路服务器、双路服务器或者多路服务器等，本申请实施例对服务器的类型不作具体限定。

在一个实施例中，如图2所示，提供了一种资源调度方法，以该方法应用于图1中的主节点为例进行说明，该方法包括步骤S100、步骤S200以及步骤S300：

步骤S100，主节点获取Pod配置文件。

Pod是容器集群中定义的一种资源，Pod是一个环境(包括容器、存储、ip地址:端口号、容器配置)，Pod中可以运行容器，容器可以是容器化的应用。

本申请实施例中，Pod配置文件可以是开发人员在主节点创建的Pod的yaml文件。该Pod配置文件可以包括Pod的名称和定义的待创建的目标容器的名称，该Pod配置文件还可以包括该待创建的目标容器所需占用的GPU资源份额，等等。

在一种可能的实施方式中，该Pod配置文件可以包括resources(资源)字段，该resources字段包括处理资源份额申请信息，该处理资源份额申请信息表征目标容器所需占用的GPU资源份额。

例如，假设一个GPU的总处理资源可以划分为8份，即一个GPU的总处理资源份额为8份，Pod配置文件例如包括字段“resources:yy.com/gpulot:4”，其中“yy.com/gpulot:4”即为处理资源份额申请信息，该处理资源份额申请信息“yy.com/gpulot:4”表征该Pod配置文件中定义的目标容器所需占用的GPU资源份额为4份，即1/2个GPU。

需要说明的是，上述举例是为了对本申请实施例的实施方式进行更容易理解的说明，其并不构成对本申请实施例的限制。在其它可能的实施方式中，处理资源份额申请信息的形式并不局限于上述举例的形式。

步骤S200，主节点基于GPU资源份额以及各子节点中的GPU剩余资源份额，从各子节点中确定目标子节点，并从目标子节点包括的GPU中确定为目标容器提供计算服务的目标GPU。

本申请实施例中，各子节点会上报自身的资源信息至主节点，供主节点调度，例如可以是在子节点启动时上报。资源信息可以包括子节点的GPU的总处理资源份额。例如，若一个子节点中部署有4个GPU，预设的资源份额粒度为8，即一个GPU的总处理资源划分为8份，则该子节点上报其GPU的总处理资源份额为4*8＝32份。主节点在份额调度过程中，根据缓存的各个子节点已被占用的GPU的处理资源份额，即可确定各子节点中的GPU剩余资源份额。

主节点获取Pod配置文件后，则基于GPU资源份额以及各子节点中的GPU剩余资源份额进行份额调度，从各子节点中选取能够提供该GPU资源份额对应的处理资源的目标子节点。

例如，Pod配置文件包括的GPU资源份额为2份，主节点若根据各子节点中的GPU剩余资源份额，确定其中一个子节点中的某个GPU还剩余2份的处理资源份额，则将该子节点确定为目标子节点以及将该GPU确定为目标GPU。

在一种可能的实施方式中，主节点可以调用基于Kubernetes的Device Plugin扩展机制扩展的份额调度插件，主节点通过主节点中的Kubernetes默认调度器(Kube-scheduler)和该份额调度插件实现步骤S200的过程，在此不做具体限制。

步骤S300，主节点根据目标子节点和目标GPU更新Pod配置文件，得到更新后的Pod配置文件。

主节点根据目标容器所需占用的GPU资源份额，即目标容器申请的GPU资源份额，进行子节点的过滤，确定目标子节点以及目标子节点包括的GPU中的目标GPU后，将Pod与该目标子节点绑定。

在一种可能的实施方式中，主节点可以将目标子节点的节点标识和目标GPU的GPU标识添加至Pod配置文件中，得到更新后的Pod配置文件，实现Pod与目标子节点绑定。该更新后的Pod配置文件用于指示目标子节点创建目标容器，并按照GPU资源份额为目标容器分配处理资源。

作为一种实施方式，目标子节点的节点标识可以是目标子节点的节点名称，目标GPU可以是主节点筛选的该目标子节点中能够为目标容器提供计算服务的GPU，目标GPU的GPU标识可以是该目标GPU的***。主节点可以将该目标子节点的节点标识添加在Pod配置文件的状态字段下，将目标GPU的***添加在Pod配置文件的注解字段下，则得到更新后的Pod配置文件。

目标子节点获取该更新后的Pod配置文件，目标子节点按照更新后的Pod配置文件的指示，创建目标容器，并通过目标子节点的GPU中的目标GPU，为目标容器提供与GPU资源份额对应的处理资源，由此，实现了主节点对子节点的GPU的处理资源的份额调度。

本实施例主节点获取Pod配置文件，该Pod配置文件包括待创建的目标容器所需占用的GPU资源份额，主节点基于GPU资源份额以及各子节点中的GPU剩余资源份额，从各子节点中确定目标子节点，并从目标子节点包括的GPU中确定为目标容器提供计算服务的目标GPU，主节点根据目标子节点和目标GPU更新Pod配置文件，得到更新后的Pod配置文件，该更新后的Pod配置文件用于指示目标子节点创建目标容器，并按照GPU资源份额为目标容器分配处理资源。由此，主节点可以按照目标容器所需占用的GPU资源份额，对子节点的GPU的处理资源进行份额调度，即目标容器可以通过GPU资源份额的形式申请一个GPU的部分处理资源，这样，即使目标容器还在运行，其它容器也可以申请这个GPU剩余的处理资源，从而避免了GPU处理资源的浪费，提升了GPU的利用率。

例如，以目标容器为容器化的推理服务为例，一个推理服务往往无法充分利用一个GPU，本实施例通过上述实施方式，能够按照GPU资源份额为一个推理服务调度一个GPU的部分处理资源，从而该GPU剩余的处理资源还可以用于其它容器的调度使用，大大提升了GPU的利用率，实现了GPU资源的精细化调度。

在一个实施例中，基于上述图2所示的实施例，本实施例涉及的是主节点如何基于GPU资源份额以及各子节点中的GPU剩余资源份额，从各子节点中确定目标子节点的过程。如图3所示，该过程可以包括步骤S201和步骤S202：

步骤S201，主节点检测各子节点中的GPU剩余资源份额是否小于GPU资源份额。

本申请实施例中，主节点检测各子节点中的GPU剩余资源份额是否小于GPU资源份额，从而对于GPU剩余资源份额小于GPU资源份额的子节点进行滤除。

在一种可能的实施方式中，主节点可以通过主节点中的Kubernetes默认调度器(Kube-scheduler)检测各子节点中的GPU剩余资源份额是否小于GPU资源份额。

步骤S202，主节点将各子节点中的GPU剩余资源份额不小于GPU资源份额的子节点确定为候选子节点，并从各候选子节点中确定目标子节点。

主节点根据步骤S201的检测结果，将各子节点中的GPU剩余资源份额不小于GPU资源份额的子节点确定为候选子节点，例如，Pod配置文件包括的GPU资源份额为4份，主节点则将子节点中的GPU剩余资源份额大于或者等于4份的子节点确定为候选子节点。

主节点进一步从各候选子节点中确定目标子节点，在一种可能的实施方式中，主节点可以执行如下步骤A1、步骤A2和步骤A3实现从各候选子节点中确定目标子节点的过程：

步骤A1，主节点检测GPU资源份额是否小于一个GPU对应的总处理资源份额。

例如，一个GPU的总处理资源份额为8份，GPU资源份额例如是申请4份的GPU的处理资源份额，主节点则可以确定该GPU资源份额小于一个GPU对应的总处理资源份额。

步骤A2，若GPU资源份额小于总处理资源份额，主节点则检测各候选子节点中是否存在包括至少一个候选GPU的候选子节点。

其中，候选GPU为候选子节点中GPU剩余资源份额不小于GPU资源份额的GPU。

主节点检测每个候选子节点中的每个GPU剩余的处理资源份额是否不小于GPU资源份额，例如，GPU资源份额是4份，主节点则检测每个候选子节点中的每个GPU剩余的处理资源份额是否不小于4份。

若一个候选子节点的一个GPU剩余的处理资源份额等于4份或者大于4份，则该GPU可以作为候选GPU，而若一个候选子节点部署有两个GPU，且每个GPU剩余的处理资源份额均为2份，但这两个GPU均不能作为候选GPU，这样，将小于一个GPU对应的总处理资源份额的GPU资源份额分配至同一个GPU上，可以确保容器运行的稳定性。

步骤A3，若存在包括至少一个候选GPU的候选子节点，主节点则确定包括至少一个候选GPU的候选子节点为目标子节点。

主节点若检测到存在包括至少一个候选GPU的候选子节点，主节点则确定包括至少一个候选GPU的候选子节点为目标子节点。在一种可能的实施方式中，若检测到存在不止一个包括至少一个候选GPU的候选子节点，主节点则将其中负载最小的候选子节点确定为目标子节点。

作为一种实施方式，主节点可以通过http协议调用基于Kubernetes的DevicePlugin扩展机制扩展的份额调度插件，实现上述步骤A1、步骤A2和步骤A3的过程。

在一个实施例中，在上述图3所示的实施例的基础上，本实施例涉及的是主节点如何从目标子节点包括的GPU中确定为目标容器提供计算服务的目标GPU的过程。如图4所示，该过程可以包括步骤S203和步骤S204：

步骤S203，主节点从目标子节点包括的各候选GPU中，确定GPU剩余资源份额最小的候选GPU。

步骤S204，主节点将GPU剩余资源份额最小的候选GPU确定为目标GPU。

本申请实施例中，主节点确定包括至少一个候选GPU的候选子节点为目标子节点，若该目标子节点中存在多个候选GPU的GPU剩余资源份额均不小于GPU资源份额，主节点则从该多个候选GPU中，确定GPU剩余资源份额最小的候选GPU为目标GPU。

例如，GPU资源份额为4份，目标子节点的两个GPU中，GPU1剩余4份的处理资源份额，GPU2剩余6份的处理资源份额，主节点则将该GPU1确定为目标GPU，由此，可以对GPU进行最大化利用，提升GPU的利用率。

本实施通过上述方式，主节点可以按照目标容器所需占用的GPU资源份额，对子节点的GPU的处理资源进行份额调度，从而提升了GPU的处理资源利用率。

在一个实施例中，如图5所示，提供了一种资源调度方法，以该方法应用于图1中多个子节点中的目标子节点为例进行说明，该目标子节点部署有GPU，该方法包括步骤S10和步骤S20：

步骤S10，目标子节点获取更新后的Pod配置文件。

本申请实施例中，目标子节点监听主节点的Pod变化信息，若监听到更新后的Pod配置文件中包括的节点标识为目标子节点的节点标识，目标子节点则从主节点获取该更新后的Pod配置文件，该更新后的Pod配置文件包括待创建的目标容器所需占用的GPU资源份额。

例如，目标子节点获取更新后的Pod配置文件后，目标子节点检测到更新后的Pod配置文件包括字段“resources:yy.com/gpulot:4”，则确定该Pod配置文件中定义的目标容器所需占用的GPU资源份额为4份，假设一个GPU的总处理资源份额为8份，目标子节点则确定目标容器需要占用1/2个GPU的处理资源。

步骤S20，目标子节点按照更新后的Pod配置文件的指示，创建目标容器，并通过目标子节点的GPU中的目标GPU，为目标容器提供与GPU资源份额对应的处理资源。

在一种可能的实施方式中，更新后的Pod配置文件还可以包括目标GPU的GPU标识，目标子节点可以通过执行如下步骤B1和B2实现步骤S20的过程：

步骤B1，目标子节点在更新后的Pod配置文件中添加环境变量字段，并将环境变量的值设置为目标GPU的GPU标识，得到目标Pod配置文件。

本申请实施例中，目标子节点检测到更新后的Pod配置文件包括待创建的目标容器所需占用的GPU资源份额，则在该更新后的Pod配置文件中添加环境变量字段，并将环境变量的值设置为目标GPU的GPU标识，得到目标Pod配置文件。

例如，目标GPU的GPU标识为2，目标子节点则在更新后的Pod配置文件中添加环境变量字段NVIDIA_VISIBLE_DEVICES，并将该环境变量的值设置为2，GPU标识“2”可以是目标GPU的***，从而得到目标Pod配置文件。

在一种可能的实施方式中，主节点可以调用基于Kubernetes的Device Plugin扩展机制扩展的份额设备插件，实现步骤B1的过程。

步骤B2，目标子节点根据目标Pod配置文件创建目标容器，并根据GPU标识从目标子节点的GPU中确定目标GPU，通过目标GPU为目标容器提供与GPU资源份额对应的处理资源。

目标子节点通过Nvidia Docker来创建目标容器，由于目标容器中指定了环境变量NVIDIA_VISIBLE_DEVICES的值，目标子节点通过Nvidia Docker创建目标容器时会把该环境变量的值对应的目标GPU暴露给目标容器，则目标容器在运行时目标子节点即可通过该目标GPU为目标容器提供与GPU资源份额对应的处理资源。由此，实现了目标子节点根据更新后的Pod配置文件中的份额调度结果，提供与GPU资源份额对应的处理资源运行目标容器，提升了GPU的利用率。

在一个实施例中，请参考图6，其示出了本申请实施例提供的一种示例性的资源调度方法的流程图，该方法可以应用于图1所示实施环境中。如图6所示，该方法可以包括以下步骤：

步骤S1001，主节点获取Pod配置文件。

参见图7，图7为一种示例性的Kubernetes集群的主节点和目标子节点的内部结构示意图。如图7所示，本实施例中，主节点上运行的主要组件包括：

Kube-apiserver：kube-apiserver是集群控制的入口；Kube-controller-manager：是Kubernetes集群的管理控制中心；Kube-scheduler：Kubernetes默认调度器；份额调度插件：本申请实施例中基于Kubernetes的Device Plugin扩展机制扩展的用于GPU份额调度的插件。

主节点通过kube-apiserver获取开发人员创建的Pod的yaml文件，即Pod配置文件，该Pod配置文件包括该待创建的目标容器所需占用的GPU资源份额等。

作为一种实施方式，本实施例中，该Pod配置文件可以包括resources(资源)字段，该resources字段包括处理资源份额申请信息，例如，Pod配置文件包括字段“resources:yy.com/gpulot:4”，其中“yy.com/gpulot:4”即为处理资源份额申请信息，该处理资源份额申请信息“yy.com/gpulot:4”表征该Pod配置文件中定义的目标容器所需占用的GPU资源份额为4份，假设一个GPU的总处理资源可以划分为8份，即一个GPU的总处理资源份额为8份，即该目标容器申请1/2个GPU。

步骤S1002，主节点基于GPU资源份额以及各子节点中的GPU剩余资源份额，从各子节点中确定目标子节点，并从目标子节点包括的GPU中确定为目标容器提供计算服务的目标GPU。

作为一种实施方式，各子节点会向kube-apiserver上报自身的资源信息，供主节点调度，例如可以是在子节点启动时上报。资源信息可以包括子节点的GPU的总处理资源份额，例如，若一个子节点中部署有4个GPU，预设的资源份额粒度为8，即一个GPU的总处理资源划分为8份，则该子节点上报其GPU的总处理资源份额为4*8＝32份。主节点在份额调度过程中，根据缓存的各个子节点已被占用的GPU的处理资源份额，即可确定各子节点中的GPU剩余资源份额。

作为一种实施方式，步骤S1002中主节点基于GPU资源份额以及各子节点中的GPU剩余资源份额，从各子节点中确定目标子节点的过程，可以通过执行如下步骤a和步骤b实现：

步骤a，主节点检测各子节点中的GPU剩余资源份额是否小于GPU资源份额。

作为一种实施方式，主节点可以通过图7中的Kube-scheduler检测各子节点中的GPU剩余资源份额是否小于GPU资源份额。

步骤b，主节点将各子节点中的GPU剩余资源份额不小于GPU资源份额的子节点确定为候选子节点，并从各候选子节点中确定目标子节点。

主节点根据步骤a的检测结果，将各子节点中的GPU剩余资源份额不小于GPU资源份额的子节点确定为候选子节点，如Pod配置文件包括的GPU资源份额为4份，主节点则将子节点中GPU剩余的处理资源份额大于或者等于4份的子节点确定为候选子节点。

主节点进一步从各候选子节点中确定目标子节点，作为一种实施方式，主节点通过http协议调用份额调度插件执行下述步骤b1-b3，实现从各候选子节点中确定目标子节点的过程：

步骤b1，主节点检测GPU资源份额是否小于一个GPU对应的总处理资源份额。

假设一个GPU的总处理资源份额为8份，GPU资源份额为4份，主节点通过份额调度插件则可以确定该GPU资源份额小于一个GPU对应的总处理资源份额。

步骤b2，若GPU资源份额小于总处理资源份额，主节点则检测各候选子节点中是否存在包括至少一个候选GPU的候选子节点。

其中，候选GPU为候选子节点中GPU剩余资源份额不小于GPU资源份额的GPU。主节点通过份额调度插件检测每个候选子节点中的每个GPU的GPU剩余资源份额是否不小于GPU资源份额，如检测每个候选子节点中的每个GPU的GPU剩余资源份额是否不小于4份。

若一个候选子节点的一个GPU剩余的处理资源份额等于4份或者大于4份，则该GPU可以作为候选GPU，而若一个候选子节点部署有两个GPU，且每个GPU剩余的处理资源份额均为2份，这两个GPU均不能作为候选GPU，这样，将小于一个GPU对应的总处理资源份额的GPU资源份额分配至同一个GPU上，可以确保容器运行的稳定性。

步骤b3，若存在包括至少一个候选GPU的候选子节点，主节点则确定包括至少一个候选GPU的候选子节点为目标子节点。

主节点通过份额调度插件若检测到存在包括至少一个候选GPU的候选子节点，主节点则确定包括至少一个候选GPU的候选子节点为目标子节点。在一种可能的实施方式中，主节点通过份额调度插件若检测到存在不止一个包括至少一个候选GPU的候选子节点，主节点则将其中负载最小的候选子节点确定为目标子节点。

作为一种实施方式，步骤S1002中，主节点从目标子节点包括的GPU中确定为目标容器提供计算服务的目标GPU的过程，可以通过执行如下步骤c和步骤d实现：

步骤c，主节点从目标子节点包括的各候选GPU中，确定GPU剩余资源份额最小的候选GPU。

步骤d，主节点将GPU剩余资源份额最小的候选GPU确定为目标GPU。

例如，GPU资源份额为4份，目标子节点的四个GPU中，GPU0和GPU1剩余0份处理资源份额，GPU2剩余4份的处理资源份额，GPU3剩余6份的处理资源份额，主节点则将该GPU2确定为目标GPU，由此，可以对GPU进行最大化利用，提升GPU的利用率。

步骤S1003，主节点根据目标子节点和目标GPU更新Pod配置文件，得到更新后的Pod配置文件。

作为一种实施方式，主节点可以将目标子节点的节点标识和目标GPU的GPU标识添加至Pod配置文件中，得到更新后的Pod配置文件，实现Pod与目标子节点绑定。该更新后的Pod配置文件用于指示目标子节点创建目标容器，并按照GPU资源份额为目标容器分配处理资源。

例如，目标子节点的节点标识可以是目标子节点的节点名称，目标GPU可以是主节点筛选的该目标子节点中能够为目标容器提供计算服务的GPU，目标GPU的GPU标识可以是该目标GPU的***。主节点可以将该目标子节点的节点标识添加在Pod配置文件的状态字段下，将目标GPU的***添加在Pod配置文件的注解字段下，则得到更新后的Pod配置文件。

步骤S1004，目标子节点获取更新后的Pod配置文件。

如图7所示，本实施例中，目标子节点上运行的主要组件包括：

Kubelet：与主节点协作，实现目标子节点管理的基本功能；Nvidia Docker：用于目标容器的创建；份额设备插件：本申请实施例中基于Kubernetes的Device Plugin扩展机制扩展的用于根据更新后的Pod配置文件中的份额调度结果，执行目标子节点上GPU份额的分配，份额设备插件还用于向Kubelet上报目标子节点中的GPU的总处理资源份额。

目标子节点通过Kubelet捕捉到主节点的更新后的Pod配置文件，该更新后的Pod配置文件包括待创建的目标容器所需占用的GPU资源份额。

例如，目标子节点通过Kubelet获取更新后的Pod配置文件后，检测到更新后的Pod配置文件包括字段“resources:yy.com/gpulot:4”，则确定该Pod配置文件中定义的目标容器所需占用的GPU资源份额为4份，即1/2个GPU。

步骤S1005，目标子节点按照更新后的Pod配置文件的指示，创建目标容器，并通过目标子节点的GPU中的目标GPU，为目标容器提供与GPU资源份额对应的处理资源。

在一种可能的实施方式中，更新后的Pod配置文件还可以包括目标GPU的GPU标识，目标子节点通过份额设备插件在更新后的Pod配置文件中添加环境变量字段，并将环境变量的值设置为目标GPU的GPU标识，得到目标Pod配置文件。

例如，如图7所示，目标子节点部署有4个GPU(GPU0、GPU1、GPU2和GPU3)，目标子节点上已经运行了两个Pod：Pod1和Pod2，Pod内运行有容器，其中Pod1对应的容器申请了16份的GPU资源份额，被绑定在0号和1号GPU上；Pod2对应的容器申请了4份的GPU资源份额，被绑定在2号GPU上，即2号GPU还剩余4份的GPU资源份额。

假设，更新后的Pod配置文件中包括的GPU资源份额为4份，更新后的Pod配置文件对应Pod3，更新后的Pod配置文件中GPU的***为2，目标子节点通过份额设备插件在更新后的Pod配置文件中添加环境变量字段NVIDIA_VISIBLE_DEVICES，并将该环境变量的值设置为2，从而得到目标Pod配置文件。

目标子节点通过Nvidia Docker来创建目标容器，由于目标容器中指定了环境变量NVIDIA_VISIBLE_DEVICES的值，目标子节点通过Nvidia Docker创建目标容器时会把该环境变量的值对应的GPU的***暴露给目标容器，即Pod3被绑定在2号GPU上，Pod3内的目标容器在运行时目标子节点即可通过该2号GPU为目标容器提供与GPU资源份额对应的处理资源。

由此，主节点可以按照目标容器所需占用的GPU资源份额，对子节点的GPU的处理资源进行份额调度，即目标容器可以通过处理资源份额的形式申请一个GPU的部分处理资源，目标子节点根据更新后的Pod配置文件中的份额调度结果，提供与GPU资源份额对应的GPU处理资源运行目标容器，这样，即使目标容器还在运行，其它容器也可以申请这个GPU剩余的处理资源，从而避免了GPU资源的浪费，提升了GPU的利用率。

以目标容器为容器化的推理服务为例，一个推理服务往往无法充分利用一个GPU，本实施例通过上述实施方式，能够按照GPU资源份额为一个推理服务调度一个GPU的部分处理资源份额，从而该GPU剩余的处理资源还可以用于其它容器的调度使用，大大提升了GPU的利用率，实现了GPU资源的精细化调度。

应该理解的是，虽然图2-6的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-6中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图8所示，提供了一种资源调度装置，设置于容器集群中的主节点，所述容器集群还包括至少一个部署有GPU的子节点，所述装置包括：

获取模块10，用于获取Pod配置文件，所述Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；

调度模块20，用于基于所述GPU资源份额以及各所述子节点中的GPU剩余资源份额，从各所述子节点中确定目标子节点，并从所述目标子节点包括的GPU中确定为所述目标容器提供计算服务的目标GPU；

绑定模块30，用于根据所述目标子节点和所述目标GPU更新所述Pod配置文件，得到更新后的Pod配置文件，所述更新后的Pod配置文件用于指示所述目标子节点创建所述目标容器，并按照所述GPU资源份额为所述目标容器分配处理资源。

可选地，所述调度模块20，包括：

检测单元，用于检测各所述子节点中的GPU剩余资源份额是否小于所述GPU资源份额；

第一确定单元，用于将各所述子节点中的GPU剩余资源份额不小于所述GPU资源份额的子节点确定为候选子节点，并从各所述候选子节点中确定所述目标子节点。

可选地，所述第一确定单元具体用于检测所述GPU资源份额是否小于一个GPU对应的总处理资源份额；若所述GPU资源份额小于所述总处理资源份额，则检测各所述候选子节点中是否存在包括至少一个候选GPU的候选子节点，所述候选GPU为候选子节点中GPU剩余资源份额不小于所述GPU资源份额的GPU；若存在所述包括至少一个候选GPU的候选子节点，则确定所述包括至少一个候选GPU的候选子节点为所述目标子节点。

可选地，所述调度模块20，包括：

第二确定单元，用于从所述目标子节点包括的各所述候选GPU中，确定GPU剩余资源份额最小的候选GPU；

第三确定单元，用于将所述GPU剩余资源份额最小的候选GPU确定为所述目标GPU。

可选地，所述绑定模块30具体用于将所述目标子节点的节点标识和所述目标GPU的GPU标识添加至所述Pod配置文件中，得到所述更新后的Pod配置文件。

可选地，所述Pod配置文件包括resources字段，所述resources字段包括处理资源份额申请信息，所述处理资源份额申请信息表征所述目标容器所需占用的所述GPU资源份额。

关于资源调度装置的具体限定可以参见上文中对于应用于主节点的资源调度方法的限定，在此不再赘述。上述资源调度装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，如图9所示，提供了一种资源调度装置，设置于容器集群中的目标子节点，所述目标子节点部署有GPU，所述容器集群还包括主节点，所述装置包括：

获取模块100，用于获取更新后的Pod配置文件，所述更新后的Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；

创建模块200，用于按照所述更新后的Pod配置文件的指示，创建所述目标容器，并通过所述目标子节点的GPU中的目标GPU，为所述目标容器提供与所述GPU资源份额对应的处理资源。

可选地，所述创建模块200，包括：

添加单元，用于在所述更新后的Pod配置文件中添加环境变量字段，并将所述环境变量的值设置为所述目标GPU的GPU标识，得到目标Pod配置文件；

创建单元，用于根据所述目标Pod配置文件创建所述目标容器，并根据所述GPU标识从所述GPU中确定所述目标GPU，通过所述目标GPU为所述目标容器提供与所述GPU资源份额对应的处理资源。

关于资源调度装置的具体限定可以参见上文中对于应用于目标子节点的资源调度方法的限定，在此不再赘述。上述资源调度装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种容器集群，所述容器集群包括主节点和至少一个部署有GPU的子节点。

所述主节点，用于执行上述方法实施例中主节点所执行的方法；

所述子节点，用于执行上述方法实施例中子节点所执行的方法。

关于主节点和子节点的具体限定可以参见上文中对于应用于主节点的资源调度方法的限定以及应用于目标子节点的资源调度方法的限定，在此不再赘述。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图10所示。该计算机设备包括通过***总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作***、计算机程序和数据库。该内存储器为非易失性存储介质中的操作***和计算机程序的运行提供环境。该计算机设备的数据库用于存储资源调度数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种资源调度方法。

本领域技术人员可以理解，图10中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：

获取Pod配置文件，所述Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；

基于所述GPU资源份额以及各所述子节点中的GPU剩余资源份额，从各所述子节点中确定目标子节点，并从所述目标子节点包括的GPU中确定为所述目标容器提供计算服务的目标GPU；

根据所述目标子节点和所述目标GPU更新所述Pod配置文件，得到更新后的Pod配置文件，所述更新后的Pod配置文件用于指示所述目标子节点创建所述目标容器，并按照所述GPU资源份额为所述目标容器分配处理资源。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

检测各所述子节点中的GPU剩余资源份额是否小于所述GPU资源份额；

将各所述子节点中的GPU剩余资源份额不小于所述GPU资源份额的子节点确定为候选子节点，并从各所述候选子节点中确定所述目标子节点。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

检测所述GPU资源份额是否小于一个GPU对应的总处理资源份额；

若所述GPU资源份额小于所述总处理资源份额，则检测各所述候选子节点中是否存在包括至少一个候选GPU的候选子节点，所述候选GPU为候选子节点中GPU剩余资源份额不小于所述GPU资源份额的GPU；

若存在所述包括至少一个候选GPU的候选子节点，则确定所述包括至少一个候选GPU的候选子节点为所述目标子节点。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

从所述目标子节点包括的各所述候选GPU中，确定GPU剩余资源份额最小的候选GPU；

将所述GPU剩余资源份额最小的候选GPU确定为所述目标GPU。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

将所述目标子节点的节点标识和所述目标GPU的GPU标识添加至所述Pod配置文件中，得到所述更新后的Pod配置文件。

在一个实施例中，所述Pod配置文件包括resources字段，所述resources字段包括处理资源份额申请信息，所述处理资源份额申请信息表征所述目标容器所需占用的所述GPU资源份额。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：

获取更新后的Pod配置文件，所述更新后的Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；

按照所述更新后的Pod配置文件的指示，创建所述目标容器，并通过所述目标子节点的GPU中的目标GPU，为所述目标容器提供与所述GPU资源份额对应的处理资源。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

在所述更新后的Pod配置文件中添加环境变量字段，并将所述环境变量的值设置为所述目标GPU的GPU标识，得到目标Pod配置文件；

根据所述目标Pod配置文件创建所述目标容器，并根据所述GPU标识从所述目标子节点的GPU中确定所述目标GPU，通过所述目标GPU为所述目标容器提供与所述GPU资源份额对应的处理资源。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

获取Pod配置文件，所述Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；

基于所述GPU资源份额以及各所述子节点中的GPU剩余资源份额，从各所述子节点中确定目标子节点，并从所述目标子节点包括的GPU中确定为所述目标容器提供计算服务的目标GPU；

根据所述目标子节点和所述目标GPU更新所述Pod配置文件，得到更新后的Pod配置文件，所述更新后的Pod配置文件用于指示所述目标子节点创建所述目标容器，并按照所述GPU资源份额为所述目标容器分配处理资源。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

检测各所述子节点中的GPU剩余资源份额是否小于所述GPU资源份额；

将各所述子节点中的GPU剩余资源份额不小于所述GPU资源份额的子节点确定为候选子节点，并从各所述候选子节点中确定所述目标子节点。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

检测所述GPU资源份额是否小于一个GPU对应的总处理资源份额；

若所述GPU资源份额小于所述总处理资源份额，则检测各所述候选子节点中是否存在包括至少一个候选GPU的候选子节点，所述候选GPU为候选子节点中GPU剩余资源份额不小于所述GPU资源份额的GPU；

若存在所述包括至少一个候选GPU的候选子节点，则确定所述包括至少一个候选GPU的候选子节点为所述目标子节点。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

从所述目标子节点包括的各所述候选GPU中，确定GPU剩余资源份额最小的候选GPU；

将所述GPU剩余资源份额最小的候选GPU确定为所述目标GPU。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

将所述目标子节点的节点标识和所述目标GPU的GPU标识添加至所述Pod配置文件中，得到所述更新后的Pod配置文件。

在一个实施例中，所述Pod配置文件包括resources字段，所述resources字段包括处理资源份额申请信息，所述处理资源份额申请信息表征所述目标容器所需占用的所述GPU资源份额。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

获取更新后的Pod配置文件，所述更新后的Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；

按照所述更新后的Pod配置文件的指示，创建所述目标容器，并通过所述目标子节点的GPU中的目标GPU，为所述目标容器提供与所述GPU资源份额对应的处理资源。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

在所述更新后的Pod配置文件中添加环境变量字段，并将所述环境变量的值设置为所述目标GPU的GPU标识，得到目标Pod配置文件；

根据所述目标Pod配置文件创建所述目标容器，并根据所述GPU标识从所述目标子节点的GPU中确定所述目标GPU，通过所述目标GPU为所述目标容器提供与所述GPU资源份额对应的处理资源。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (13)

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

获取Pod配置文件，所述Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；

基于所述GPU资源份额以及各所述子节点中的GPU剩余资源份额，从各所述子节点中确定目标子节点，并从所述目标子节点包括的GPU中确定为所述目标容器提供计算服务的目标GPU；

根据所述目标子节点和所述目标GPU更新所述Pod配置文件，得到更新后的Pod配置文件，所述更新后的Pod配置文件用于指示所述目标子节点创建所述目标容器，并按照所述GPU资源份额为所述目标容器分配处理资源。

2.根据权利要求1所述的方法，其特征在于，所述基于所述GPU资源份额以及各所述子节点中的GPU剩余资源份额，从各所述子节点中确定目标子节点，包括：

检测各所述子节点中的GPU剩余资源份额是否小于所述GPU资源份额；

将各所述子节点中的GPU剩余资源份额不小于所述GPU资源份额的子节点确定为候选子节点，并从各所述候选子节点中确定所述目标子节点。

3.根据权利要求2所述的方法，其特征在于，所述从各所述候选子节点中确定所述目标子节点，包括：

检测所述GPU资源份额是否小于一个GPU对应的总处理资源份额；

若所述GPU资源份额小于所述总处理资源份额，则检测各所述候选子节点中是否存在包括至少一个候选GPU的候选子节点，所述候选GPU为候选子节点中GPU剩余资源份额不小于所述GPU资源份额的GPU；

若存在所述包括至少一个候选GPU的候选子节点，则确定所述包括至少一个候选GPU的候选子节点为所述目标子节点。

4.根据权利要求3所述的方法，其特征在于，所述从所述目标子节点包括的GPU中确定为所述目标容器提供计算服务的目标GPU，包括：

从所述目标子节点包括的各所述候选GPU中，确定GPU剩余资源份额最小的候选GPU；

将所述GPU剩余资源份额最小的候选GPU确定为所述目标GPU。

5.根据权利要求1所述的方法，其特征在于，所述根据所述目标子节点和所述目标GPU更新所述Pod配置文件，得到更新后的Pod配置文件，包括：

将所述目标子节点的节点标识和所述目标GPU的GPU标识添加至所述Pod配置文件中，得到所述更新后的Pod配置文件。

6.根据权利要求1所述的方法，其特征在于，所述Pod配置文件包括resources字段，所述resources字段包括处理资源份额申请信息，所述处理资源份额申请信息表征所述目标容器所需占用的所述GPU资源份额。

7.一种资源调度方法，其特征在于，应用于容器集群中的目标子节点，所述目标子节点部署有GPU，所述容器集群还包括主节点，所述方法包括：

获取更新后的Pod配置文件，所述更新后的Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；

按照所述更新后的Pod配置文件的指示，创建所述目标容器，并通过所述目标子节点的GPU中的目标GPU，为所述目标容器提供与所述GPU资源份额对应的处理资源。

8.根据权利要求7所述的方法，其特征在于，所述更新后的Pod配置文件包括所述目标GPU的GPU标识，所述按照所述更新后的Pod配置文件的指示，创建所述目标容器，并通过所述目标子节点的GPU中的目标GPU，为所述目标容器提供与所述GPU资源份额对应的处理资源，包括：

在所述更新后的Pod配置文件中添加环境变量字段，并将所述环境变量的值设置为所述目标GPU的GPU标识，得到目标Pod配置文件；

根据所述目标Pod配置文件创建所述目标容器，并根据所述GPU标识从所述目标子节点的GPU中确定所述目标GPU，通过所述目标GPU为所述目标容器提供与所述GPU资源份额对应的处理资源。

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

获取模块，用于获取Pod配置文件，所述Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；

调度模块，用于基于所述GPU资源份额以及各所述子节点中的GPU剩余资源份额，从各所述子节点中确定目标子节点，并从所述目标子节点包括的GPU中确定为所述目标容器提供计算服务的目标GPU；

绑定模块，用于根据所述目标子节点和所述目标GPU更新所述Pod配置文件，得到更新后的Pod配置文件，所述更新后的Pod配置文件用于指示所述目标子节点创建所述目标容器，并按照所述GPU资源份额为所述目标容器分配处理资源。

10.一种资源调度装置，其特征在于，设置于容器集群中的目标子节点，所述目标子节点部署有GPU，所述容器集群还包括主节点，所述装置包括：

获取模块，用于获取更新后的Pod配置文件，所述更新后的Pod配置文件包括待创建的目标容器所需占用的GPU资源份额；

创建模块，用于按照所述更新后的Pod配置文件的指示，创建所述目标容器，并通过所述目标子节点的GPU中的目标GPU，为所述目标容器提供与所述GPU资源份额对应的处理资源。

11.一种容器集群，其特征在于，所述容器集群包括主节点和至少一个部署有GPU的子节点；

所述主节点，用于执行如权利要求1至6任一项所述的资源调度方法；

所述子节点，用于执行如权利要求7或8所述的资源调度方法。

12.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6中任一项所述的方法的步骤，或者，所述处理器执行所述计算机程序时实现权利要求7至8中任一项所述的方法的步骤。

13.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的方法的步骤，或者，所述计算机程序被处理器执行时实现权利要求7至8中任一项所述的方法的步骤。

Images