CN111930525B - Gpu资源使用方法、电子设备及计算机可读介质 - Google Patents

Abstract

根据本发明实施例提供的GPU资源使用方法、电子设备及计算机可读介质：工作区与GPU分离，工作区虚拟容器对象组件通过远程请求指令请求远程的GPU对工作区虚拟容器对象组件中的应用数据进行处理，用户在工作区虚拟容器对象组件中准备数据的时候并不会占用GPU资源，避免了现有技术中用户在GPU虚拟容器对象组件中准备数据占用GPU资源的情形；且在利用GPU虚拟容器对象组件执行完远程请求指令所请求的操作，并返回操作结果后，释放了GPU虚拟容器对象组件占用的GPU资源，被释放的该GPU资源可以继续分配给其它工作区虚拟容器对象组件进行应用数据处理使用，GPU的利用率得到提高。

Description

GPU资源使用方法、电子设备及计算机可读介质

技术领域

本发明实施例涉及计算机技术领域，尤其涉及一种GPU资源使用方法、电子设备及计算机可读介质。

背景技术

目前在许多领域，大量的计算任务均会使用到GPU（图形处理器）进行处理，以便利用GPU的高处理性能加快运行速度。然而，由于GPU是十分重要的算力资源且售价十分昂贵，如何提高GPU的利用率是目前各大厂商的重点研究课题。

为此，GPU共享技术应运而生，在一种GPU共享技术中，将GPU作为扩展资源从而实现GPU资源的拆分。其通过一个GPU同时与多个pod（一种虚拟容器对象组件）绑定，来达到共享GPU的目的。但是，该技术中与GPU绑定的pod会持续占用可调度的GPU资源，即使没有GPU资源使用需求，与其绑定的那部分GPU资源也无法调度给其他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的利用率得到提高。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1为根据本发明实施例一的一种GPU资源使用方法的步骤流程图；

图2为根据本发明实施例一的一种GPU资源使用方法流程图；

图3为根据本发明实施例一的另一种GPU资源使用方法的步骤流程图；

图4为根据本发明实施例二的一种GPU资源使用方法的流程图；

图5为根据本发明实施例三的一种电子设备的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅配置为解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

实施例一

参照图1，示出了根据本发明实施例一的一种GPU资源使用方法的步骤流程图。

本实施例的GPU资源使用方法包括以下步骤：

步骤101、接收工作区虚拟容器对象组件发送的、用于请求GPU对工作区虚拟容器对象组件中的应用数据进行处理的远程请求指令。

在本实施例中，虚拟容器对象组件为包含至少一个虚拟容器对象的控件，如pod等。虚拟容器对象中可以运行一个或多个应用程序，上述应用数据可以为应用程序的数据，或者通过应用程序运行的数据，再或者应用程序处理的数据等，本实施例不做限制。上述远程请求指令用于请求GPU对工作区虚拟容器对象组件（可表示为cpu-pod）中的应用数据进行处理，可以理解，远程请求指令可以根据用户实际需求进行编写，示例性的，远程请求指令可以为@ python pin.py，表示用python执行pin.py文件。

示例性的，如图2所示，图中左边的cpu-pod可以理解为上述工作区虚拟容器对象组件，其运行在某台设备的CPU上，用户可以在工作区虚拟容器对象组件，即cpu-pod中进行数据准备，在数据准备好以后，可以发送远程请求指令。与传统的用户在gpu-pod中准备数据不同，传统的用户在gpu-pod中准备数据的过程中会占用gpu-pod所绑定的GPU资源，用户准备数据的过程中实际不需要利用GPU资源但却占用了GPU资源，造成GPU资源的浪费，本发明实施例中，通过如图2中所示的axer-server代理组件对远程请求指令进行处理，其在接收到该远程请求指令后，可以请求任意空闲的GPU，进而通过创建的GPU虚拟容器对象组件对工作区虚拟容器对象组件中的应用数据进行处理，因此，避免了在用户准备数据过程中对GPU资源的占用。

在本实施例中，用户可以在CPU侧，通过命令行工具cli创建gpu-pod的配置参数，作为一种示例，配置参数可以包括以下：

ID：99f002b1-5730-4054-8df0-6bc814067c9f

镜像：nvidia/cuda:10.1-cudnn7-devel-ubuntu18.04

GPU类型：GTX1080TI

GPU卡数：2块

内存：8G

当用户想要使用GPU执行命令时，可以在cpu-pod中执行“axer use 99f002b1-5730-4054-8df0-6bc814067c9f”，其中axer可以指示命令行工具，标识后续的GPU操作将使用此ID中的配置参数。当用户想要利用GPU执行任意执行远程操作时，例如执行@ nvidia-smi 时，当检测到@符号时，cpu-pod会自动将上述cli中创建的配置参数与该远程请求指令一起发送到axer-server，然后通过axer-server找到上述ID对应的gpu-pod，并使得与GPU绑定的gpu-pod完成对应的远程操作。

可以理解，通过代理组件axer-server可以确保接收的远程请求指令发送到对应ID的gpu-pod中，需要说明的是，代理组件axer-server还可以负责pod的启动和关闭。

本实施例提供的上述方法可以应用于具有GPU集群的调度管理系统中，GPU集群是一个计算机集群，其中每个计算机节点均可以配备有一个或者多个GPU。例如，Kubernetes调度管理集群等，Kubernetes是一个开源的容器管理系统，为容器化的应用提供部署运行、资源调度等功能。但不限于此，其它形式的GPU集群系统也同样适用。

以Kubernetes集群为例，其主要包括管理节点Master和工作节点Node，各节点之间可以相互通信，这里的节点可以指集群中的服务器或其它形式的电子设备，但不限于物理设备。其中，管理节点负责管理和控制集群中的工作节点，管理节点上运行api-server、以及scheduler等进程。工作节点为集群中的工作负载节点，管理节点会将工作负载分配给工作节点，工作节点上运行kubelet、kube-proxy等进程。以上构成Kubernetes系统的各进程的具体功能可以参考相关技术，这里不作具体阐述。

在本实施例中，以Kubernetes为例，工作区虚拟容器对象组件（即cpu-pod）可以通过代理组件axer-server向Kubernetes下发指令，其中，指令可以是通过“.yaml”的配置文件编写的。

具体地，如图3所示，步骤101可以包括以下：

步骤1011、向管理节点Master中的api-server发起请求消息。

在本实施例中，所述请求消息中可以包括用于请求GPU对工作区虚拟容器对象组件中的应用数据进行处理的远程请求指令以及gpu-pod的配置参数。结合图4，图4中client可以理解为用户工作区，用户工作区中包含工作区虚拟容器对象组件即cpu-pod。用户可以从cpu-pod向管理节点Master中的api-server发起请求消息，其中，api-server可用于对核心对象例如Pod的增删改查操作，同时也是集群内模块之间数据交换的枢纽，api-server还可以实现常用的访问（权限）控制，注册，信息存储等功能。

步骤1012、api-server接收工作区虚拟容器对象组件发送的请求消息，生成一个包含上述请求消息的yaml文件，将该文件记录并存储在ETCD中。

其中，ETCD是一种数据仓库，可以保存集群中各个节点、Pod、容器的信息。

步骤1013、scheduler（简称为schd）监听上述api-server，其中，监听到的请求消息的请求内容中包含有预设的远程请求指令符号。

在本实施例中，cpu-pod会将带有远程请求指令符号的请求消息发送给代理组件，代理组件再将该请求消息发送给api-server，调度器scheduler（简称为schd）可以监听api-server，并将获取到的请求消息分配给调度器扩展插件（图4中schd-extender）去进行下一步的处理。其中，预设的远程请求指令符号可以根据实际情况进行设置，例如可以设置为@符号，即该@符号能够表示远程请求指令需要放到远端有GPU的环境执行。

步骤1014、scheduler根据远程请求指令符号获得用于请求GPU对工作区虚拟容器对象组件中的应用数据进行处理的远程请求指令。

在本实施例中，可以将请求消息的请求内容中@符号所对应的指令，作为用于请求GPU对工作区虚拟容器对象组件中的应用数据进行处理的远程请求指令。

上述实施例中，通过设置远程请求指令符号，使得用户工作区发出的指令能够通过该远程请求指令符号判断是否需要远端有GPU环境的节点去执行，对算力要求较高的数据处理，可以通过添加远程请求指令符号，将其分配给远端的GPU去执行。

步骤102、根据GPU的当前空闲资源的信息，确定可用GPU空闲资源。

在本实施例中，可以将已经被使用的GPU标记为“已占用”，未被使用的，即完全空闲的GPU的状态标记未“空闲”，可以理解，上述仅为示例性说明，也可以将已经被使用的GPU标记为“1”，未被使用的，即完全空闲的GPU的状态标记未“0”等其他形式，本实施例不做限制，结合图4，可以利用图4中的gpu-monitor监控插件来获取GPU的当前空闲资源的信息。

可选地，在一种实施方式中，可以获取每个GPU的当前时段空闲资源的信息，然后根据每个GPU的当前时段空闲资源的信息，为远程请求指令所请求的操作确定可用GPU空闲资源。

在本实施例中，当前时段可以是用户需要执行远程请求指令的时间段，可以由用户根据实际需求进行设置，例如，若用户A将上述时间段设置为5点10分——5点20分，则可以获取该时间段内所有标记为“空闲”或者“0”的GPU的信息，选择用户A所需的GPU，确定为远程请求指令所请求的操作的可用GPU空闲资源。

上述实施例中，由于确定的可用GPU空闲资源在5点10分——5点20分这个时间段内才会被用户A占用，也即，除非在5点10分——5点20分这个时间段内，用户A均不会占用上述确定的可用GPU空闲资源。因此上述确定的可用GPU空闲资源在其他时间段可以被其他工作区用户使用，即通过“分时复用”的方式减少了GPU的空闲时间，提高了GPU的利用率。

可选地，在另一种实施方式中，可以获取被占用GPU的当前时段资源利用信息；然后根据每个GPU的当前时段资源利用信息，将资源利用率低于预设阈值的GPU中未被利用的资源，确定为可用GPU空闲资源。

在本实施例中，若集群中的GPU均被占用，即没有完全空闲的GPU，则可以获取所有标记为“已占用”或者“1”的GPU的信息，得到每个GPU的资源利用率。在本实施例中，可以按照每个GPU的资源利用率的高低，从低到高选择用户需要的GPU资源；也可以设置一个预设阈值，例如设置为50%，则可以选择资源利用率低于50%的GPU中未被利用的资源，将其确定为可用GPU空闲资源。本领域技术人员应当明了的是，50%仅为示例性说明，在实际应用中，可以由本领域技术人员根据实际需求设定为任意适当的数值。

上述实施例中，可以将已经被占用的GPU中的未被利用的GPU资源，分享给用户继续使用，即，若一个GPU当前的资源利用率为40%，则表明该GPU中还有60%的GPU资源未被利用，可以将该60%的GPU资源继续分配给其它工作区虚拟容器对象组件进行应用数据处理使用，以提高GPU的利用率。

可选地，上述GPU的资源类型可以是新的资源类型，即在集群中首次出现的资源类型；可以通过指定设备插件对所述预设资源类型进行预先注册，示例性的，新的资源类型的GPU可以注册为AxerGPU。该资源类型的GPU资源具有本发明实施例中的非绑定、可复用特性。

进一步的，可以根据预设资源类型的GPU的当前空闲资源的信息，确定可用GPU空闲资源。

在本实施例中，若预设的资源类型的GPU为AxerGPU，则可以通过监控组件获取所有AxerGPU的当前空闲资源的信息，再从中选取用户所需的AxerGPU作为可用GPU空闲资源。

上述实施例中，通过预先注册新的资源类型的GPU——AxerGPU，使得集群中的各个模块在接收到与AxerGPU相关的指令时，能够识别出该AxerGPU，并正确完成与AxerGPU相关的数据处理，避免了不能识别新的资源类型的GPU的情况。

可选地，在本实施例中，可以获取GPU配置信息，根据GPU配置信息和GPU的当前空闲资源的信息，从GPU的当前空闲资源中确定可用GPU空闲资源。

以前述ID为99f002b1-5730-4054-8df0-6bc814067c9f对应的配置参数为例，可以根据该ID中的配置信息，从GPU的当前空闲资源中找到类型为GTX1080TI的GPU，作为可用GPU空闲资源。

步骤103、使用可用GPU空闲资源创建GPU虚拟容器对象组件，并根据工作区虚拟容器对象组件的执行环境参数初始化GPU虚拟容器对象组件的执行环境参数。

以Kubernetes集群为例，GPU虚拟容器对象组件可以用gpu-pod表示，gpu-pod的执行环境参数与上述工作区虚拟容器对象组件（即cpu-pod）的执行环境参数保持一致，可以在创建gpu-pod时，把cpu-pod的执行环境参数都存在一个文件中，在启动gpu-pod时把该文件中的执行环境参数初始化，以保证两者的执行环境参数一致。其中。执行环境参数可以是对上述应用数据执行远程请求指令所请求的操作时所挂载的路径或者目录，使得gpu-pod在指定的目录下去执行远程请求指令所请求的操作。需要说明的是，gpu-pod与cpu-pod可以使用相同的docker镜像以保证安装软件一致，可以挂载相同的数据盘以保证两者的数据一致。

具体地，可以通过指定设备插件对上述预设资源类型的GPU进行预先注册，即上述可用GPU空闲资源可以是通过指定设备插件预先注册的预设资源类型的GPU——AxerGPU，进一步地，可以通过指定设备插件对上述预设资源类型的GPU的资源类型以及GPU的数量进行注册声明；如图4中所示，指定设备插件为device plugin，device-plugin是定制的插件，通过它可以预先注册新的可调度GPU的资源类型，并可以声明在当前节点中有多少数量的GPU资源。

由于GPU不是k8s默认的调度资源，如果没有device-plugin预先注册，k8s无法对GPU资源进行调度。可以理解，通过device plugin预先注册GPU资源类型，可以使得k8s中各个模块都能识别该GPU资源类型，通过声明GPU的数量，可以使得节点中的GPU资源得到合理的分配。

进一步地，使用可用GPU空闲资源创建GPU虚拟容器对象组件，包括：

若监测到根据远程请求指令生成的GPU虚拟容器对象组件创建消息，则通过指定调度器扩展插件将确定的可用GPU空闲资源分配给待创建的GPU虚拟容器对象组件，并将待创建的GPU虚拟容器对象组件与分配的可用GPU空闲资源进行绑定；并发送绑定完成消息，以使拥有可用GPU空闲资源的GPU节点根据绑定完成消息、待创建的GPU虚拟容器对象组件的信息，和，可用GPU空闲资源的信息，创建GPU虚拟容器对象组件。

在本实施例中，同样以Kubernetes为例，若系统中的调度器scheduler监测到服务器api-server中有根据远程请求指令生成的GPU虚拟容器对象组件创建消息，则通过指定调度器扩展插件schd-extender为GPU虚拟容器对象组件分配预设资源类型的可用GPU空闲资源，然后将待创建的GPU虚拟容器对象组件与分配的预设资源类型的可用GPU空闲资源进行绑定。可以理解，本实施例中的预设资源类型为上述AxerGPU。

在调度器扩展插件schd-extender将待创建的GPU虚拟容器对象组件与分配的预设资源类型的可用GPU空闲资源进行绑定之后，scheduler向aip-server发送绑定完成消息，以使拥有可用GPU空闲资源的工作节点（GPU节点）根据绑定完成消息、待创建的GPU虚拟容器对象组件的信息，和，分配的可用GPU空闲资源的信息，创建GPU虚拟容器对象组件即gpu-pod。

在本实施例中，图4中的kublete位于工作节点（GPU节点）中，假设该工作节点中的GPU为上述确定的可用GPU空闲资源，当该工作节点中的kublete监听到上述绑定完成消息后，可以创建GPU虚拟容器对象组件gpu-pod并启动容器，例如docker容器，并在docker容器启动前向device-plugin发送容器绑定请求，device-plugin根据当前节点上的GPU资源情况，向kublete返回GPU的环境变量如可用的GPU资源的信息等，然后kublete在启动容器过程中将得到的GPU的环境变量输入容器，进而完成AxerGPU和docker容器的绑定。

上述实施例通过创建docker容器并将其与AxerGPU进行绑定，使得GPU的资源使用通过docker容器进行区分，使得GPU的资源分配细粒度更高。

步骤104、通过初始化后的GPU虚拟容器对象组件，对应用数据执行远程请求指令所请求的操作。

在所述初始化后，GPU虚拟容器对象组件和工作区虚拟容器对象组件具有相同的执行环境，从而可以保证在GPU虚拟容器对象组件中也可正常运行基于工作区虚拟容器对象组件中的虚拟容器对象而运行的应用，该应用在GPU虚拟容器对象组件中的虚拟容器对象中的运行与在工作区虚拟容器对象组件的虚拟容器对象中一样。

在本实施例中，通过前述步骤，完成了GPU与gpu-pod的绑定，也完成了GPU与gpu-pod中容器的绑定，因此，可以启动并初始化gpu-pod，使其利用与其绑定的GPU的资源，对应用数据执行远程请求指令所请求的操作。

步骤105、在向工作区虚拟容器对象组件返回操作的操作结果后，销毁GPU虚拟容器对象组件并释放GPU虚拟容器对象组件占用的GPU资源。

在本实施例中，可选地，在一种实施方式中，当执行完远程请求指令所请求的操作并返回操作结果后，可以直接销毁gpu-pod并释放gpu-pod占用的GPU资源，成为空闲资源，且更新GPU空闲资源的信息。在另一种实施方式中，也可以预先设置一个时长阈值，在向工作区虚拟容器对象组件返回操作的操作结果后，若在上述预设时长阈值内没有接收到下一条远程请求指令，则再销毁gpu-pod并释放gpu-pod占用的GPU资源，成为空闲资源，且更新GPU空闲资源的信息。

上述实施例通过设置时长阈值，可以避免在短时间内有多个执行操作需要GPU处理时，需要重新创建gpu-pod的问题，节省了处理流程。

因工作区与GPU分离，因此，本实施例中，在通过GPU虚拟容器对象组件对所述应用数据进行处理后，还需要向工作区GPU虚拟容器对象组件返回操作结果，工作区虚拟容器对象组件会基于该结果进行后续操作，如展示给用户或发送给其它设备或参与其它处理等，就如同该应用数据是在工作区虚拟容器对象组件中被处理一样。

在返回操作结果后，GPU虚拟容器对象组件所占用的资源会被释放，以供新的工作区虚拟容器对象组件或者其它应用或程序使用。

通过上述实施例，工作区与GPU分离，工作区虚拟容器对象组件通过远程请求指令请求远程的GPU对工作区虚拟容器对象组件中的应用数据进行处理，用户在工作区虚拟容器对象组件中准备数据的时候并不会占用GPU资源，避免了现有技术中用户在GPU虚拟容器对象组件中准备数据占用GPU资源的情形；并且，在利用GPU虚拟容器对象组件执行完远程请求指令所请求的操作，并返回操作结果后，销毁了GPU虚拟容器对象组件且释放了GPU虚拟容器对象组件占用的GPU资源，被释放的该GPU资源可以继续分配给其它工作区虚拟容器对象组件进行应用数据处理使用，而不会与某一工作区虚拟容器对象组件绑定，并被该工作区虚拟容器对象组件持续占用，因此使得GPU的利用率得到提高。

实施例二

基于实施例一中的步骤101--步骤105，其对应的另一种可行实现示例如图4所示。参见图4，本实施例对图4中的处理过程进行详细描述：

步骤1011、向管理节点Master中的api-server发起请求消息。

在本实施例中，device plugin插件启动后会向kubelet注册新的GPU资源类型，kubelet 会继续向上一层api-server注册该新的GPU资源类型，使得API服务器（图中用aip-server表示）能够识别该新的GPU资源类型。其中，图4中的client可以理解为用户工作区，用户工作区中包含工作区虚拟容器对象组件cpu-pod，用户可以从cpu-pod通过代理组件向管理节点Master中的API服务器发送请求消息，请求消息中包括远程请求指令，若远程请求指令为“create pod”，API服务器接收到创建pod的指令。

步骤1012、api-server接收工作区虚拟容器对象组件发送的请求消息，生成一个包含上述请求消息的yaml文件，将该文件记录并存储在ETCD中。

在本实施例中，API服务器接收到创建pod的指令后，可以生成一个包含创建信息的yaml文件，并将其记录到数据库ETCD中进行存储。当数据库ETCD接受上述yaml文件以后，可以返回API服务器已存储的创建pod事件。

步骤1013、scheduler（简称为schd）监听上述api-server，根据监听到的请求消息获得用于请求GPU对工作区虚拟容器对象组件中的应用数据进行处理的远程请求指令。

步骤103、使用可用GPU空闲资源创建GPU虚拟容器对象组件，并根据工作区虚拟容器对象组件的执行环境参数初始化GPU虚拟容器对象组件的执行环境参数。

在本实施例中，由于调度器（图4中schd）可以实时监听API服务器，当监听到上述创建pod事件后，且当通过请求消息判断出该pod需要与上述新的资源类型的可用GPU空闲资源进行绑定时，调度器会将上述远程请求指令发送到调度器扩展插件（图4中schd-extender），并利用调度器扩展插件将pod与上述新的资源类型的可用GPU空闲资源进行绑定。其中，可用GPU空闲资源的确定可以如实施例一所述，此处不再赘述。

在本实施例中，调度器扩展插件的绑定策略（或称为调度策略）可以根据实际需求进行规划，例如：可以首先通过监测模块如gpu-monitor监测每个工作节点中GPU的使用情况，优先选择未被使用的GPU与上述pod进行绑定，若集群中不存在未被使用的GPU，则选择使用率较低的GPU与上述pod进行绑定，该绑定信息会写入数据库ETCD中。

需要说明的是，若没有schd-extender，则可以通过调度器schd基于k8s中默认的调度策略进行GPU资源的调度。即通过调度器schd基于k8s中默认的调度策略选择合适的可用GPU资源，与pod进行绑定。

步骤104、通过初始化后的GPU虚拟容器对象组件，对应用数据执行远程请求指令所请求的操作。

在本实施例中，工作节点（GPU节点）中的进程例如kubelet进程监听到上述绑定信息后，可以根据待创建的pod的信息，和可用GPU空闲资源的信息，创建pod并启动虚拟容器对象例如docker容器，然后在docker容器启动阶段完成AxerGPU和docker容器的绑定，最后创建的pod利用与其绑定的AxerGPU对应用数据执行远程请求指令所请求的操作。

上述实施例中，通过利用定制的device plugin插件，可以预先注册新的GPU资源类型，使得aip-server能够识别该新的GPU资源类型，并且通过利用schd-extender，使得能够按照用户预定的调度策略对上述GPU以及上述pod进行调度。

本实施例的GPU资源使用方法可以由任意适当的具有数据处理能力的电子设备执行，包括但不限于：服务器、移动终端（如手机、PAD等）和PC机等。

实施例三

图5为本发明实施例三中电子设备的硬件结构；如图5所示，该电子设备可以包括：处理器(processor)301、通信接口(Communications Interface)302、存储器(memory)303、以及通信总线304。

其中：

处理器301、通信接口302、以及存储器303通过通信总线304完成相互间的通信。

通信接口302，用于与其它电子设备或服务器进行通信。

处理器301，用于执行程序305，具体可以执行上述GPU资源使用方法实施例中的相关步骤。

具体地，程序305可以包括程序代码，该程序代码包括计算机操作指令。

处理器301可能是中央处理器CPU，或者是特定集成电路ASIC（ApplicationSpecific Integrated Circuit），或者是被配置成实施本发明实施例的一个或多个集成电路。智能设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器303，用于存放程序305。存储器303可能包含高速RAM存储器，也可能还包括非易失性存储器（non-volatile memory），例如至少一个磁盘存储器。

程序305具体可以用于使得处理器301执行以下操作：接收工作区虚拟容器对象组件发送的、用于请求图形处理器GPU对所述工作区虚拟容器对象组件中的应用数据进行处理的远程请求指令；根据所述GPU的当前空闲资源的信息，确定可用GPU空闲资源；使用所述可用GPU空闲资源创建GPU虚拟容器对象组件，并根据所述工作区虚拟容器对象组件的执行环境参数初始化所述GPU虚拟容器对象组件的执行环境参数；通过初始化后的所述GPU虚拟容器对象组件，对所述应用数据执行所述远程请求指令所请求的操作；在向所述工作区虚拟容器对象组件返回所述操作的操作结果后，销毁所述GPU虚拟容器对象组件并释放所述GPU虚拟容器对象组件占用的GPU资源。

在一种可选的实施方式中，程序305还用于使得处理器301在根据所述GPU的当前空闲资源的信息，确定可用GPU空闲资源时：获取每个GPU的当前时段空闲资源的信息；根据每个所述GPU的当前时段空闲资源的信息，为所述远程请求指令所请求的操作确定可用GPU空闲资源。

在一种可选的实施方式中，程序305还用于使得处理器301在根据所述GPU的当前空闲资源的信息，确定可用GPU空闲资源时：获取被占用GPU的当前时段资源利用信息；根据每个所述GPU的当前时段资源利用信息，将资源利用率低于预设阈值的GPU中未被利用的资源，确定为所述可用GPU空闲资源。

在一种可选的实施方式中，程序305还用于使得处理器301在根据所述GPU的当前空闲资源的信息，确定可用GPU空闲资源时：根据预设资源类型的GPU的当前空闲资源的信息，确定可用GPU空闲资源。

在一种可选的实施方式中，程序305还用于使得处理器301在所述根据预设资源类型的GPU的当前空闲资源的信息，确定可用GPU空闲资源之前，通过指定设备插件对所述预设资源类型的GPU进行预先注册。

在一种可选的实施方式中，程序305还用于使得处理器301在通过指定设备插件对所述预设资源类型的GPU进行预先注册时：通过指定设备插件对所述预设资源类型的GPU的资源类型以及GPU的数量进行注册声明。

在一种可选的实施方式中，程序305还用于使得处理器301在使用所述可用GPU空闲资源创建GPU虚拟容器对象组件时：若监测到所述根据所述远程请求指令生成的GPU虚拟容器对象组件创建消息，则通过指定调度器扩展插件将确定的所述可用GPU空闲资源分配给待创建的所述GPU虚拟容器对象组件，并将待创建的所述GPU虚拟容器对象组件与分配的所述可用GPU空闲资源进行绑定；并发送绑定完成消息，以使拥有所述可用GPU空闲资源的GPU节点根据所述绑定完成消息、所述待创建的GPU虚拟容器对象组件的信息，和，所述可用GPU空闲资源的信息，创建所述GPU虚拟容器对象组件。

在一种可选的实施方式中，程序305还用于使得处理器301在在向所述工作区虚拟容器对象组件返回所述操作的操作结果后，销毁所述GPU虚拟容器对象组件并释放所述GPU虚拟容器对象组件占用的GPU资源时：在向所述工作区虚拟容器对象组件返回所述操作的操作结果后，若在预设时间段内没有接收到新的远程请求指令，则销毁所述GPU虚拟容器对象组件，并释放所述GPU虚拟容器对象组件占用的GPU资源。

程序305中各步骤的具体实现可以参见上述GPU资源使用方法实施例中的相应步骤中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。

通过本实施例的电子设备，由于工作区虚拟容器对象组件通过远程请求指令请求GPU对工作区虚拟容器对象组件中的应用数据进行处理，故工作区虚拟容器组件与GPU是分离的，因此用户在工作区虚拟容器对象组件中准备数据的时候并不会占用GPU资源，避免了现有技术中用户在GPU虚拟容器对象组件中准备数据占用GPU资源的情形；并且，在利用GPU虚拟容器对象组件执行完远程请求指令所请求的操作，并返回操作结果后，销毁了GPU虚拟容器对象组件且释放了GPU虚拟容器对象组件占用的GPU资源，被释放的该GPU资源可以继续被利用，因此使得GPU的利用率得到提高。

特别地，根据本发明的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含配置为执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分从网络上被下载和安装，和/或从可拆卸介质被安装。在该计算机程序被中央处理单元（CPU）执行时，执行本发明实施例中的方法中限定的上述功能。需要说明的是，本发明实施例所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读介质例如可以但不限于是电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储介质（RAM）、只读存储介质（ROM）、可擦式可编程只读存储介质（EPROM或闪存）、光纤、便携式紧凑磁盘只读存储介质（CD-ROM）、光存储介质件、磁存储介质件、或者上述的任意合适的组合。在本发明实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明实施例中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输配置为由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写配置为执行本发明实施例的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络：包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机（例如利用因特网服务提供商来通过因特网连接）。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个配置为实现规定的逻辑功能的可执行指令。上述具体实施例中有特定先后关系，但这些先后关系只是示例性的，在具体实现的时候，这些步骤可能会更少、更多或执行顺序有调整。即在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括接入模块和发送模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定。

作为另一方面，本发明实施例还提供了一种计算机可读介质，其上存储有计算机程序，该程序被处理器执行时实现如上述实施例中所描述的GPU资源使用方法。

作为另一方面，本发明实施例还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的装置中所包含的；也可以是单独存在，而未装配入该装置中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该装置执行时，使得该装置：接收工作区虚拟容器对象组件发送的、用于请求图形处理器GPU对所述工作区虚拟容器对象组件中的应用数据进行处理的远程请求指令；根据所述GPU的当前空闲资源的信息，确定可用GPU空闲资源；使用所述可用GPU空闲资源创建GPU虚拟容器对象组件，并根据所述工作区虚拟容器对象组件的执行环境参数初始化所述GPU虚拟容器对象组件的执行环境参数；通过初始化后的所述GPU虚拟容器对象组件，对所述应用数据执行所述远程请求指令所请求的操作；在向所述工作区虚拟容器对象组件返回所述操作的操作结果后，销毁所述GPU虚拟容器对象组件并释放所述GPU虚拟容器对象组件占用的GPU资源。

在本发明的各种实施方式中所使用的表述“第一”、“第二”、“所述第一”或“所述第二”可修饰各种部件而与顺序和/或重要性无关，但是这些表述不限制相应部件。以上表述仅配置为将元件与其它元件区分开的目的。

以上描述仅为本发明的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本发明实施例中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本发明实施例中公开的（但不限于）具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (10)

1.一种GPU资源使用方法，其特征在于，所述方法包括：

接收CPU中的工作区虚拟容器对象组件发送的、用于请求图形处理器GPU对所述工作区虚拟容器对象组件中的应用数据进行处理的远程请求指令，其中，所述远程请求指令中设置有远程请求指令符号，所述远程请求指令符号用于指示需要远端GPU对所述CPU中的工作区虚拟容器对象组件中的应用数据进行处理；

根据所述GPU的当前空闲资源的信息，确定可用GPU空闲资源；

使用所述可用GPU空闲资源创建GPU虚拟容器对象组件，并根据所述工作区虚拟容器对象组件的执行环境参数初始化所述GPU虚拟容器对象组件的执行环境参数；

通过初始化后的所述GPU虚拟容器对象组件，对所述应用数据执行所述远程请求指令所请求的操作；

在向所述工作区虚拟容器对象组件返回所述操作的操作结果后，销毁所述GPU虚拟容器对象组件并释放所述GPU虚拟容器对象组件占用的GPU资源。

2.根据权利要求1所述的方法，其特征在于，所述根据所述GPU的当前空闲资源的信息，确定可用GPU空闲资源，包括：

获取每个GPU的当前时段空闲资源的信息；

根据每个所述GPU的当前时段空闲资源的信息，为所述远程请求指令所请求的操作确定可用GPU空闲资源。

3.根据权利要求1所述的方法，其特征在于，所述根据所述GPU的当前空闲资源的信息，确定可用GPU空闲资源，包括：

获取被占用GPU的当前时段资源利用信息；

根据每个所述GPU的当前时段资源利用信息，将资源利用率低于预设阈值的GPU中未被利用的资源，确定为所述可用GPU空闲资源。

4.根据权利要求2或3所述的方法，其特征在于，所述根据所述GPU的当前空闲资源的信息，确定可用GPU空闲资源，包括：

根据预设资源类型的GPU的当前空闲资源的信息，确定可用GPU空闲资源。

5.根据权利要求4所述的方法，其特征在于，在所述根据预设资源类型的GPU的当前空闲资源的信息，确定可用GPU空闲资源之前，所述方法还包括：

通过指定设备插件对所述预设资源类型的GPU进行预先注册。

6.根据权利要求4所述的方法，其特征在于，所述使用所述可用GPU空闲资源创建GPU虚拟容器对象组件，包括：

若监测到根据所述远程请求指令生成的GPU虚拟容器对象组件创建消息，则通过指定调度器扩展插件将确定的所述可用GPU空闲资源分配给待创建的所述GPU虚拟容器对象组件，并将待创建的所述GPU虚拟容器对象组件与分配的所述可用GPU空闲资源进行绑定；

并发送绑定完成消息，以使拥有所述可用GPU空闲资源的GPU节点根据所述绑定完成消息、所述待创建的GPU虚拟容器对象组件的信息、和所述可用GPU空闲资源的信息，创建所述GPU虚拟容器对象组件。

7.根据权利要求1所述的方法，其特征在于，所述在向所述工作区虚拟容器对象组件返回所述操作的操作结果后，销毁所述GPU虚拟容器对象组件并释放所述GPU虚拟容器对象组件占用的GPU资源，包括：

在向所述工作区虚拟容器对象组件返回所述操作的操作结果后，若在预设时间段内没有接收到新的远程请求指令，则销毁所述GPU虚拟容器对象组件，并释放所述GPU虚拟容器对象组件占用的GPU资源。

8.根据权利要求1所述的方法，其特征在于，所述根据所述GPU的当前空闲资源的信息，确定可用GPU空闲资源，包括：

获取GPU配置信息，根据所述GPU配置信息和所述GPU的当前空闲资源的信息，从所述GPU的当前空闲资源中确定可用GPU空闲资源。

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

一个或多个处理器；

计算机可读介质，配置为存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-8中任一项所述的GPU资源使用方法。

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

Images