CN112559164A - 一种资源共享方法及装置 - Google Patents

Abstract

一种资源共享方法，应用于Kubernetes集群，包括：在Kubernetes集群的任一节点上，根据容器或Pod对所述节点的GPU的共享使用需求，启动所述GPU对应的MPS Server Pod。本申请还提供一种资源共享装置。本申请可以在Kubernetes集群实现动态启动MPS Server Pod，实现Kubernetes容器或Pod对GPU的共享使用，从而提高集群资源的使用效率。

Description

一种资源共享方法及装置

技术领域

本申请实施例涉及但不限于计算机应用技术领域，尤指一种资源共享方法及装置。

背景技术

由于图像处理单元(GPU，Graphics Processing Unit)强大的算力，在深度学习和高性能计算领域得到广泛的使用，但在不同场景下对GPU的使用需求有所差异。以深度学习为例，在训练场景下需要将多个GPU聚合起来，提供更大的算力来加速模型训练；但是，在推理过程中则更希望将同一GPU在多个应用间共享，从而来分享单一应用使用GPU时过剩的算力。与此同时，随着容器技术的流行，越来越多的应用采用容器和容器云作为应用的编排调度以及应用间隔离的工具，而Kubernetes俨然已成为容器PaaS(Platform-as-a-Service)平台的事实标准。

Kubernetes是自动化容器操作的开源平台，提供了应用部署、规划、更新、维护的一种机制。在Kubernetes上共享GPU设备时，可以采用MPS(Multi-Process Service，多进程服务)技术(Nvidia提供的多进程间并发使用GPU的解决方案)。然而，直接通过静态方式启动MPS，会限制GPU的使用方式只能为共享。如此一来，在没有使用共享GPU的作业时会导致GPU资源的长期占用，造成资源浪费；而且，也无法自适应地管理GPU的共享或独占使用。

发明内容

本申请提供了一种资源共享方法及装置，可以实现在Kubernetes容器(Container)或Pod间高效共享GPU。

一方面，本申请提供一种资源共享方法，应用于Kubernetes集群，包括：在Kubernetes集群的任一节点上，根据容器或Pod对所述节点的GPU的共享使用需求，启动所述GPU对应的多进程服务(MPS)服务器(Server)Pod。

另一方面，本申请提供一种资源共享装置，应用于Kubernetes集群的节点，包括：Device Plugin组件和Kubelet组件；所述Device Plugin组件用于根据容器或Pod对所述节点的GPU的共享使用需求，触发所述Kubelet组件启动所述GPU对应的MPS Server Pod。

另一方面，本申请提供一种资源共享装置，包括：存储器和处理器，所述存储器存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的资源共享方法的步骤。

另一方面，本申请提供一种计算机可读存储介质，存储有计算机程序，所述计算机程序被执行时实现如上所述的资源共享方法的步骤。

在本申请中，在Kubernetes集群的任一节点上，根据容器或Pod对该节点的GPU的共享使用需求，启动GPU对应的MPS Server Pod。本申请在Kubernetes集群实现了动态启动MPS Server Pod，实现了Kubernetes容器或Pod对GPU的共享使用，从而提高了集群资源的使用效率。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本申请技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请的技术方案，并不构成对本申请技术方案的限制。

图1为本申请实施例的一种实施场景示例图；

图2为本申请实施例提供的一种资源共享方法的示例流程图；

图3为本申请实施例提供的一种资源共享装置的示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下文中将结合附图对本申请的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例提供一种资源共享方法及装置，在利用MPS(Multi-ProcessService，多进程服务)技术的基础上，通过MPS Server Pod的动态管理来支持GPU在Kubernetes容器(Container)或Pod间MPS共享，从而支持Kubernetes Pod或Container间高效共享GPU。

图1为本申请实施例的一种实施场景示例图。如图1所示，Kubernetes集群中包括主节点(master node)以及多个从节点(节点1至节点N，N为正整数)。其中，在任一从节点上，可以通过动态启动MPS Server Pod来实现Kubernetes Pod或Container间高效共享GPU。其中，Pod为可以创建和管理Kubernetes计算的最小可部署单元，一个Pod可以包括一个或者多个容器(Container)。

需要说明的是，为了支持GPU在Kubernetes Pod或Container间的高效共享，首先要解决GPU在Kubernetes上的共享调度问题；该问题可以采用以下任一解决方案：一、将待共享的物理GPU映射为多个虚拟GPU(vGPU)，通过vGPU的调度来完成对物理GPU的共享调度；二、将对GPU Device调度转化为对GPU Memory等资源的调度，从而将一个GPU分配给多个应用Pod；三、扩展Kubernetes各组件来使其支持对GPU的共享调度，其中，用户可以通过Pod的资源描述来请求共享或者独占使用GPU资源，Kubernetes系统可以提供统一的用户界面。上述各个方案的具体实现可以依据目前已知方式实现，故于此不再赘述。

假设Kubernetes集群系统已经拥有将多个Pod或Container调度在同一GPU上的能力的基础上，本申请实施例提供一种资源共享方法，通过动态启动MPS Server Pod来支持实现Kubernetes Pod或Container间高效共享GPU；以及通过将MPS配置隔离的方式来实现同一节点内GPU的共享和独占使用模式并存。

图2为本申请实施例提供的资源共享方法的流程示例图。如图2所示，本申请实施例提供的资源共享方法，应用于Kubernetes集群，包括：

S201、在Kubernetes集群的任一节点上，根据容器或Pod对所述节点的GPU的共享使用需求，启动该GPU对应的MPS Server Pod。

在一示例性实施方式中，本实施例的资源共享方法还可以包括：当设定时长内没有容器或Pod共享使用所述节点的所述GPU，则删除所述GPU对应的MPS Server Pod。

在本实施例中，Kubernetes集群系统在开工时并不启动MPS Server Pod，而是等到存在GPU的共享使用需求时再启动MPS Server Pod，并在没有容器或Pod使用共享GPU时，通过删除MPS Server Pod，及时释放MPS Server Pod所占用的资源。

在一示例性实施方式中，S201可以包括：当所述节点的Kubelet组件调用DevicePlugin组件的Allocate接口传递共享使用请求，且Device Plugin组件确定所述共享使用请求所指示的GPU未启动MPS Server Pod，则Device Plugin组件触发Kubelet组件启动所述GPU对应的MPS Server Pod。其中，共享使用请求可以携带请求共享使用的GPU的信息(比如，编号)；Device Plugin组件管理节点上的全部GPU，可以根据共享使用请求携带的GPU编号查看对应的GPU是否已启动MPS Server Pod，若已启动对应的MPS Server Pod，则可以直接利用已启动的MPS Server Pod，若尚未启动，则触发Kubelet组件启动对应的MPS ServerPod。

在一示例性实施方式中，S202可以包括：当节点的Device Plugin组件检测到设定时长内没有容器或Pod共享使用该节点的该GPU，则Device Plugin组件删除该GPU对应的MPS Server Pod。比如，Device Plugin组件可以周期性或定时检查节点上支持共享使用的GPU的使用情况(比如，根据Pod信息来检测)，当不再有使用该支持共享使用的GPU的Pod，则确定删除该GPU的MPS Server Pod。

在一示例性实施方式中，Device Plugin组件确定启动GPU对应的MPS Server Pod之后，可以添加DaemonSet配置信息，Kubelet组件实时检测到更新的DaemonSet配置信息后，可以根据更新的DaemonSet配置信息来实现MPS Server Pod的启动。Device Plugin组件确定删除GPU对应的MPS Server Pod之后，可以移除对应的DaemonSet配置信息，Kubelet组件实时检测DaemonSet配置信息的情况，根据移除的DaemonSet配置信息来实现对MPSServer Pod的删除。然而，本申请对此并不限定。在其他实现方式中，MPS Server Pod可以利用Kubernetes API来启动或删除。比如，Device Plugin组件确定启动或删除MPS ServerPod之后，可以将相关信息通过API发送给Kubelet组件，由Kubelet组件实现MPS ServerPod的启动或删除。关于MPS Server Pod的启动和删除过程的具体实现方式可以依据本领域常用技术手段实现，故于此不再赘述。

在本实施例中，通过将MPS Server(包含Controller和Server)Pod化，从而支持Pod或Container间共享使用GPU。而且，可以由Device Plugin组件实现MPS Server Pod的生命周期动态管理，从而实现GPU的共享使用，提高集群资源的使用效率。

在一示例性实施方式中，本实施例的资源共享方法还可以包括：当所述节点的Kubelet组件调用Device Plugin组件的Allocate接口传递共享使用请求，则所述DevicePlugin组件通过所述Allocate接口向所述Kubelet组件返回所述GPU对应的MPS ServerPod的MPS配置信息；所述Kubelet组件在启动共享使用所述GPU的容器或Pod时，将所述MPS配置信息传递给所述容器或Pod。其中，Device Plugin组件可以根据共享使用请求携带的请求共享使用的GPU的信息，查找该GPU对应的MPS Server Pod的MPS配置信息，并通过Allocate接口返回给Kubelet组件。

本示例性实施例中，Kubelet组件在共享使用GPU的Pod或Container启动时，可以将该GPU对应的MPS Server Pod的MPS配置信息作为启动命令或者环境变量传递给Docker组件，以支持Pod或Container启动时获取到MPS配置信息。

在一示例中，Device Plugin组件返回的信息可以采用以下实现方式(以json表示)：

在本示例性实施例中，通过Device Plugin组件来传递MPS配置信息，从而可以使用户层不感知GPU是共享使用还是独占使用。

在一示例性实施方式中，GPU对应的MPS Server Pod与共享该GPU的应用Pod处于相同的进程间通信(IPC，Inter-Process Communication)命名空间(Namespace)下。其中，对于Pre-Volta的GPU，为了保证MPS客户端(Client)和MPS Server间的IPC通信畅通，要求这些Pod必须处于同一IPC Namespace下。在一示例中，可以设置MPS Server Pod和共享GPU应用Pod的IPC Namespace统一为Host IPC来实现。比如，设置方式如下：

在一示例性实施方式中，节点上支持共享使用的不同GPU对应的MPS配置信息不同。在本示例性实施方式中，可以通过设置多个MPS配置信息(主要是MPS_PIPE目录与MPS_LOG目录配置信息)来实现独占与共享使用GPU的隔离。其中，非共享的GPU无需配置MPSServer；而多个共享GPU可以通过多个不同的MPS配置信息进行隔离，即不同的共享GPU对应不同的MPS配置信息。然而，本申请对此并不限定。多个共享GPU可以采用同一个MPSServer，则只需配置一个MPS Server即可。

在一示例中，共享GPU和非共享GPU的配置方式例如如下所示：

#共享GPU配置

CUDA_VISIBLE_DEVICES＝0#共享GPU ID号

CUDA_MPS_PIPE_DIRECTORY＝/tmp/nvidia-mps-share

CUDA_MPS_LOG_DIRECTORY＝/tmp/nvidia-log-share

#非共享GPU配置

CUDA_VISIBLE_DEVICES＝1#非共享GPU ID号

本申请实施例为Kubernetes集群引入了动态管理MPS Server Pod的方式，实现了GPU的共享使用，同时提高了集群资源的使用效率；而且，支持在Kubernetes集群上共享与独占使用GPU的并存。

下面基于图1通过一个实施示例进行说明。图1示意了一种Kubernetes集群中共享与独占GPU并存使用的场景示意图。如图1所示，一个Kubernetes集群节点中包含多个GPU，其中，部分GPU被作业(Job)Pod共享使用，而另外一些GPU则被Job Pod独占使用。其中，共享使用GPU的Pod均处于相同的HOST IPC namespace下。所有的GPU可以由扩展后的DevicePlugin组件管理。

本示例的实施环境如下：搭载Ubuntu16.04系统的Kubernetes集群，包含1个主节点，1个从节点；节点包含4个GTX 1080Ti GPU，CUDA驱动版本9.0，并安装nvidia-docker。

本示例的操作步骤如下：

步骤一、部署包含修改过的支持调度共享设备或资源的Kubernetes scheduler组件、Kubelet组件、以及本申请扩展的Device-plugin组件(配置共享GPU的最大共享数目为8)。

步骤二、集群部署完毕后，申请创建训练job，其中，yaml可描述如下：

步骤三、Pod创建成功后，在节点上通过nvidia-smi命令查看GPU使用情况，发现进程在两个GPU上执行(比如图1中的Job3 Pod和Job4 Pod)，表明独占模式GPU分配成功。需要注意的是，此时节点上并没有存在MPS Server Pod，因为无共享GPU的使用。

步骤四、申请创建推理job，此时在申请描述中根据所采取Kubernetes共享调度方案来申请1或2个GPU。

步骤五、Pod创建成功后，首先通过kubectl get pods命令查看pod运行情况，确认MPS Server Pod已被动态创建。然后，查看推理job pod(比如图1中的Job1 Pod和Job2Pod)创建成功，通过nvidia-smi命令来查看GPU进程使用情况如下：(1)两个GPU以独占模式运行，GPU上进程号为训练job pod内进程；(2)一个GPU以共享模式运行，GPU上进程号为nvidia-cuda-mps-server，同时观察此GPU的显存占用率为1/2左右。

本使用场景可以在满足多种job类型的基础上，最大程度地提升GPU的利用率，而且独占与共享模式的GPU可以同时并存于一个节点上。

本申请实施例还提供一种资源共享装置，包括：应用于Kubernetes集群的节点，包括：Device Plugin组件和Kubelet组件；所述Device Plugin组件用于根据容器或Pod对所述节点的图像处理单元GPU的共享使用需求，触发所述Kubelet组件启动所述GPU对应的多进程服务MPS服务器Server Pod。

在一示例性实施方式中，所述Device Plugin组件还用于当所述节点的Kubelet组件调用Device Plugin组件的Allocate接口传递共享使用请求，则通过所述Allocate接口向所述Kubelet组件返回所述GPU对应的MPS Server Pod的MPS配置信息；所述Kubelet组件用于在启动共享使用所述GPU的容器或Pod时，将所述MPS配置信息传递给所述容器或Pod。

关于本实施例提供的资源共享装置的相关说明可以参照上述方法实施例的描述，故于此不再赘述。

本申请实施例还提供一种资源共享装置，包括：存储器和处理器，所述存储器存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的资源共享方法的步骤。

如图3所示，在一个示例中，资源共享装置包括：处理器310、存储器320、总线系统330和收发器340，其中，处理器310、存储器320和收发器340通过该总线系统330相连，存储器320用于存储指令，处理器310用于执行存储器320存储的指令，以控制收发器340发送信号。

应理解，处理器310可以是中央处理单元(Central Processing Unit，简称为“CPU”)，处理器310还可以是其他通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器320可以包括只读存储器和随机存取存储器，并向处理器310提供指令和数据。存储器320的一部分还可以包括非易失性随机存取存储器。例如，存储器320还可以存储设备类型的信息。

总线系统330除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图3中将各种总线都标为总线系统330。

在实现过程中，上述装置所执行的处理可以通过处理器310中的硬件的集成逻辑电路或者软件形式的指令完成。即本申请实施例所公开的方法的步骤可以体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等存储介质中。该存储介质位于存储器320，处理器310读取存储器320中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。

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

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

Claims (10)

1.一种资源共享方法，应用于Kubernetes集群，包括：

在Kubernetes集群的任一节点上，根据容器或Pod对所述节点的图像处理单元GPU的共享使用需求，启动所述GPU对应的多进程服务MPS服务器Server Pod。

2.根据权利要求1所述的资源共享方法，其特征在于，所述在Kubernetes集群的任一节点上，根据容器或Pod对所述节点的GPU的共享使用需求，启动所述GPU对应的MPS ServerPod，包括：

当所述节点的Kubelet组件调用Device Plugin组件的Allocate接口传递共享使用请求，且所述Device Plugin组件确定所述共享使用请求所指示的GPU未启动MPS ServerPod，则所述Device Plugin组件触发所述Kubelet组件启动所述GPU对应的MPS ServerPod。

3.根据权利要求1所述的资源共享方法，其特征在于，所述资源共享方法还包括：当设定时长内没有容器或Pod共享使用所述节点的所述GPU，则删除所述GPU对应的MPS ServerPod。

4.根据权利要求2所述的资源共享方法，其特征在于，所述资源共享方法还包括：

当所述节点的Kubelet组件调用Device Plugin组件的Allocate接口传递共享使用请求，则所述Device Plugin组件通过所述Allocate接口向所述Kubelet组件返回所述GPU对应的MPS Server Pod的MPS配置信息；

所述Kubelet组件在启动共享使用所述GPU的容器或Pod时，将所述MPS配置信息传递给所述容器或Pod。

5.根据权利要求4所述的资源共享方法，其特征在于，所述GPU对应的MPS Server Pod与共享所述GPU的应用Pod处于相同的进程间通信IPC命名空间Namespace下。

6.根据权利要求4所述的资源共享方法，其特征在于，所述节点上支持共享使用的不同GPU对应的MPS配置信息不同。

7.一种资源共享装置，其特征在于，应用于Kubernetes集群的节点，包括：DevicePlugin组件和Kubelet组件；所述Device Plugin组件用于根据容器或Pod对所述节点的图像处理单元GPU的共享使用需求，触发所述Kubelet组件启动所述GPU对应的多进程服务MPS服务器Server Pod。

8.根据权利要求7所述的资源共享装置，其特征在于，所述Device Plugin组件还用于当所述节点的Kubelet组件调用Device Plugin组件的Allocate接口传递共享使用请求，则通过所述Allocate接口向所述Kubelet组件返回所述GPU对应的MPS Server Pod的MPS配置信息；

所述Kubelet组件用于在启动共享使用所述GPU的容器或Pod时，将所述MPS配置信息传递给所述容器或Pod。

9.一种资源共享装置，其特征在于，包括：存储器和处理器，所述存储器存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至6中任一项所述的资源共享方法的步骤。

10.一种计算机可读存储介质，其特征在于，存储有计算机程序，所述计算机程序被执行时实现如权利要求1至6中任一项所述的资源共享方法的步骤。

Images