CN113296950A

CN113296950A - 处理方法、装置、电子设备及可读存储介质

Info

Publication number: CN113296950A
Application number: CN202110594696.5A
Authority: CN
Inventors: 李学辉
Original assignee: Chongqing Unisinsight Technology Co Ltd
Current assignee: Chongqing Unisinsight Technology Co Ltd
Priority date: 2021-05-28
Filing date: 2021-05-28
Publication date: 2021-08-24
Anticipated expiration: 2041-05-28
Also published as: CN113296950B

Abstract

本申请提出一种处理方法、装置、电子设备及可读存储介质，涉及计算机技术领域。该方法包括：根据第一容器和设置有虚拟机的第二容器的对应关系，建立第一容器和第二容器的通信连接，其中，第一容器被分配的图形处理器GPU资源所在的GPU为第三容器可直接访问的GPU，第二容器没有被分配GPU资源；在第二容器内的虚拟机需要使用GPU资源的情况下，控制第二容器内的虚拟机通过第一容器与第二容器的通信连接，访问第一容器对应的GPU，以调用该第一容器被分配的GPU资源。由此，可以使第二容器内的虚拟机与第三容器在同一时刻使用同一块GPU，提高GPU的使用率。

Description

处理方法、装置、电子设备及可读存储介质

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种处理方法、装置、电子设备及可读存储介质。

背景技术

随着AI技术的发展，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的使用率。

附图说明

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

图1为本申请实施例提供的电子设备的方框示意图；

图2为本申请实施例提供的处理方法的流程示意图之一；

图3为本申请实施例提供的处理方法的流程示意图之二；

图4为本申请实施例提供的容器内虚拟机与容器的通信示意图；

图5为本申请实施例提供的处理方法的流程示意图之三；

图6为图5中步骤S110包括的一种子步骤的流程示意图；

图7为本申请实施例提供的统一管理框图；

图8为图5中步骤S110包括的另一种子步骤的流程示意图；

图9为本申请实施例提供的处理装置的方框示意图之一；

图10为本申请实施例提供的处理装置的方框示意图之二。

图标：100-电子设备；110-存储器；120-处理器；130-通信单元；200-处理装置；210-调度管理模块；220-通信模块；230-处理模块。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，术语“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

随着Docker和Kubernetes生态圈的发展，云计算领域用容器来构建云平台的厂商越来越多。容器技术为应用程序提供了隔离的运行空间，每个容器内都包含一个独享的完整用户环境空间，容器内的变动不会影响其他容器的运行环境。但是容器之间共享同一个系统内核，这就意味着对于不同内核或操作系统需求的应用是不可能部署在一起的。相对应的虚拟机技术则是虚拟了一个完整的操作系统，为用户提供了不依赖宿主机内核的运行环境，另外在隔离性和安全性方面都有容器技术不可比拟的优势。

因此容器和虚拟机融合，在同一个云平台中提供，整合容器和虚拟机各自的优势，弥补双方的不足，是云计算领域的一个发展方向。Kubernetes强大的调度能力和灵活的扩展方式是目前容器领域的标准化存在。容器内跑虚拟机，即容器内运行可以创建虚拟机的libvirt和qemu等进程，在Linux操作系统中虚拟机本质上就是一个操作系统进程，应该是可以运行在容器内部的。容器内虚拟机可以做到虚拟机和容器真正的统一调度和管理，又可以充分利用Kubernetes的故障发现、滚动升级等管理机制。目前Redhat开源的Kubevirt和Mirantis开源的virtlet都提供了以容器方式运行虚拟机的方案。

以Kubevirt为例，虚拟机作为一种CRD(Custom Resources Definition，用户自定义资源)资源，其定制controller(控制器)会将虚拟机CRD转换为POD。POD是kubernetes最基本的执行单元(最小、最简单的单元)，POD表示在集群上运行的进程；POD封装了应用程序容器(某些情况下多个容器)，存储资源、唯一网络IP、以及控制器该如何运行的选项。一个POD运行一个容器是kubernetes最常见的。

POD内管理libevirt和qemu等进程，POD内虚拟机运行后，POD的网络会通过网桥的方式(或者NAT(Network Address Translation，网络地址转换)方式)，将虚拟机的网络和POD的网络连接起来，虚拟机对外的IP即为POD的IP，虚拟机的网络出POD后，和其他POD的网络同等的传输方式和优先级。

随着AI技术的发展，GPU(Graphics Processing Unit，图形处理器)的功能不只在图形方面，在深度学习、大数据计算方面发挥着越来越重要的作用。由于GPU的价格较高，对学习和工作中的使用都产生了较高的门槛。GPU共享或虚拟化的使用也探索出了较多方法，但都是集中在虚拟机之间共享GPU或者容器之间共享GPU。容器化虚拟机推出之后，虚拟机和容器在同一个集群内统一调度和管理，GPU也需要一种通用的调度和使用方法。

目前针对容器内虚拟机，NVIDIA推出了基于vfio的GPU直通和vGPU的方案，但该方法也是基于虚拟机之间共享GPU或虚拟机独占GPU的思想。在这两个方案中，首先要做的是将物理机上的GPU被nvidia驱动识别到前，将GPU绑定到vfio的驱动，基于vfio的pcipassthrough方式将GPU直通给容器内虚拟机。绑定了nvidia驱动的GPU，除非卸载掉nvidia的驱动，不然无法绑定vfio的驱动，在无法绑定vfio的驱动的情况下，容器内虚拟机无法直接使用GPU。容器内虚拟机和集群内的容器无法共同使用同一块GPU；并且，在使用不同的GPU时，GPU的驱动也不一样(容器为nvidia的GPU驱动，虚拟机为vfio的驱动)，且对不同驱动的安装顺序和使用都提出了很多限制。这对生产环境中，业务扩展和升级提出了非常高的要求，这和云计算集群弹性扩展和平滑升级的思想不相符。

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

针对以上情况，容器内虚拟机使用GPU和容器使用GPU的底层实现方法不兼容、不能共享、不能统一调度，对容器内虚拟机的推广和使用产生了较多限制。故，本申请实施例提供了一种处理方法、装置、电子设备及可读存储介质，使得容器内虚拟机和容器可共享GPU及统一调度，提高GPU的使用率，降低容器内虚拟机使用GPU的复杂度，发挥容器内虚拟机和容器统一调度和管理的优势。

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。

请参照图1，图1为本申请实施例提供的电子设备100的方框示意图。所述电子设备100可以是，但不限于，服务器、集群服务器等。比如，该电子设备100可以是Kubernetes集群，该Kubernetes集群中包括多个主机NODE。所述电子设备100可以包括存储器110、处理器120及通信单元130。所述存储器110、处理器120以及通信单元130各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。

其中，存储器110用于存储程序或者数据。所述存储器110可以是，但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-Only Memory，PROM)，可擦除只读存储器(ErasableProgrammable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric ErasableProgrammable Read-Only Memory，EEPROM)等。

处理器120用于读/写存储器110中存储的数据或程序，并执行相应地功能。比如，存储器110中存储有处理装置200，所述处理装置200包括至少一个可以软件或固件(firmware)的形式存储于所述存储器110中的软件功能模块。所述处理器120通过运行存储在存储器110内的软件程序以及模块，如本申请实施例中的处理装置200，从而执行各种功能应用以及数据处理，即实现本申请实施例中的处理方法。

通信单元处理用于通过网络建立所述电子设备100与其它通信终端之间的通信连接，并用于通过所述网络收发数据。

应当理解的是，图1所示的结构仅为电子设备100的结构示意图，所述电子设备100还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。图1中所示的各组件可以采用硬件、软件或其组合实现。

请参照图2，图2为本申请实施例提供的处理方法的流程示意图之一。所述方法可应用于上述电子设备100。下面对处理方法的具体流程进行详细阐述。该处理方法可以包括步骤S120～步骤S130。

步骤S120，根据第一容器和设置有虚拟机的第二容器的对应关系，建立所述第一容器和第二容器的通信连接。

在本实施例，可预先保存建立好的第一容器和第二容器的对应关系。所述第一容器和第二容器的容器类型不同。所述第一容器的容器类型为辅助容器，辅助容器被分配有GPU资源，也即第一容器被分配有GPU资源。该第一容器可以跑RCUDA(Remot ComputeUnified Device Architecture，远程计算统一设备架构)的Server，将CUDA的能力以API的形式提供出来。所述第一容器分配的GPU资源所在的GPU为第三容器可直接访问的GPU。

所述第二容器的容器类型为基本容器，基本容器没有被分配GPU资源，也即该第二容器没有被分配GPU资源。该第二容器内设置有虚拟机，该第二容器内的虚拟机(即容器内虚拟机)可以跑RCUDA的Client。

可选地，可以在建立所述第一容器及所述第二容器之后，就建立该第一容器和第二容器的通信连接；也可以是在所述第二容器内的虚拟机需要使用GPU资源的情况下，建立第一容器和第二容器的通信连接。其中，所述第一容器和第二容器可以在同一个主机内，也可以在不同的主机内。当在不同的主机内时，第二容器内的虚拟机和第一容器的连接通信方式可以采用TCP(Transmission Control Protocol，传输控制协议)等网络方式或RDMA(Remote Direct Memory Access，远程直接数据存取)等远程访问的方式。

步骤S130，在第二容器内的虚拟机需要使用GPU资源的情况下，控制所述第二容器内的虚拟机通过所述第一容器与所述第二容器的通信连接，访问所述第一容器对应的GPU，以调用该第一容器被分配的GPU资源。

在所述第二容器内的虚拟机需要使用GPU资源时，该第二容器内的虚拟机可以通过该第二容器和该第二容器所对应的第一容器之间的通信连接，与该第一容器进行数据通信(比如传递相关的API和数据)，从而访问该第一容器对应的GPU，以调用该第一容器被分配的GPU资源。

所述第二容器内的虚拟机可以跑正常CUDA基础上的应用(比如TensorFlow)，但是应用的请求根据不同的类别，分给对应的代理来处理，代理将请求和数据通过上一步中建立的连接和对应的第一容器进行通信，进而达到访问GPU的目的。其中，此处访问的GPU是第一容器被分配的GPU资源所在的GPU，也即是第三容器可直接访问的GPU，也就是说，第二容器内虚拟机与第三容器可以同时使用同一块GPU。

请参照图3，图3为本申请实施例提供的处理方法的流程示意图之二。所述方法还可以包括步骤S140。

步骤S140，在第三容器要使用GPU资源的情况下，控制所述第三容器访问对应的GPU，以使用该第三容器被分配的GPU资源。

所述第三容器的容器类型为普通容器，若普通容器需要使用GPU资源，则该普通容器可以被分配有GPU资源，也即该第三容器可以被分配有GPU资源。普通容器可直接使用GPU跑业务。普通容器直接可以跑CUDA基础上的应用(比如TensorFlow)。在分配有GPU资源的该第三容器要使用GPU资源的情况下，该第三容器可以直接访问自身对应的GPU，以使用该第三容器被分配的GPU资源。其中，该第三容器及上述第一容器被分配的GPU资源在同一块GPU上。

可以理解的是，此GPU共享方案有多种实现方式，且基本都能做到显存和算力隔离。主要分为用户态API层面的转发和隔离，或者内核态的流量劫持和转发。本申请对此不做限制，主要表达的是GPU共享基础上的容器和容器内虚拟机之间的共享，且可以利用容器间共享GPU的隔离方案。

其中，具体的GPU资源分配方案可以根据实际需求设置。比如在GPU共享的容器集群内，可以针对一块GPU，根据算力和显存分为多个GPU单元，分别给该主机上的第二容器和第三容器使用。

下面结合图4，以Kubevirt为例，对上述过程进行举例说明。

在Kubevirt中，容器内虚拟机作为一种CRD资源，其定制controller会将虚拟机CRD转换为POD，POD内管理libevirt和qemu等进程。POD内虚拟机运行后，POD的网络会通过网桥的方式(或者NAT方式)，将虚拟机的网络和POD的网络连接起来，虚拟机对外的IP即为POD的IP，虚拟机的网络出POD后，和其他POD的网络同等的传输方式和优先级。因此，POD内虚拟机和其他POD网络与普通POD网络之间是同样的网络传输方式。POD内虚拟机和POD(即容器内和容器)之间的基于网络的GPU共享也是基于此。

图4中下侧的主机NODE的GPU分为两个单元，共享给一个第一容器和一个第三容器。其中，图4中的CON表示容器，VM表示虚拟机。第三容器直接可以跑CUDA基础上的应用(比如TensorFlow)。右侧的主机NODE的GPU使用的是NVIDIA驱动。容器直接使用GPU时，GPU可以是nvidia的驱动。

在该第三容器中的应用要使用GPU资源时，该应用可以将请求发送给对应的CUDARuntime/Library/Driver，以达到使用GPU资源的目的。其中，该第三容器可以直接访问GPU。

该第一容器中构建RCUDA的Server端，将CUDA的能力以API的形式提供出来。图4中上侧的CON表示与第一容器对应的第二容器，该第二容器内设置有虚拟机。第二容器内的虚拟机与第一容器之间可以通过POD之间的网络，建立稳定的TCP连接来传递相关的API和数据，也可以基于其他网络通信实现该过程。第二容器与第一容器可以在同一个主机上，也可以图4所示位于不同的主机上。

第二容器内的虚拟机可以正常跑CUDA基础上的应用(比如TensorFlow)。可以根据应用的请求类别，将请求分给对应的代理(如图4所示的CUDA Runtime Proxy、CUDALibrary Proxy、CUDA Driver Proxy)来处理，该代理通过第二容器内的虚拟机中的Communicator、第一容器中的Communicator及API Service，将请求和数据发送给第一容器中对应的代理(如图4所示的Real CUDA Runtime Proxy、CUDA Library Proxy、CUDADriver Proxy)，从而达到使第二容器内虚拟机访问GPU的目的。

请参照图5，图5为本申请实施例提供的处理方法的流程示意图之三。所述方法还可以包括步骤S110。可以理解的是，在进行上述步骤S120～步骤S140之前，可先通过步骤S110创建与上述步骤S120～步骤S140对应的第一容器、第三容器及第二容器内的虚拟机。

步骤S110，接收输入的创建请求，并根据所述创建请求创建对应的容器或容器内虚拟机。

在本实施例中，该创建请求可以是用户输入的，也可以是其他设备发送的，具体可以根据实际情况确定。在接收到该创建请求后，可以将该创建请求进行保存，比如，将相关的资源对象存入数据库(比如etcd)；当对应的controller监听到该创建请求后，可创建对应的与所述创建请求对应的容器或容器内虚拟机。

请参照图6，图6为图5中步骤S110包括的一种子步骤的流程示意图。在本实施例中，步骤S110可以包括子步骤S111～子步骤S114。

子步骤S111，在接收到用于创建容器内虚拟机的第一创建请求的情况下，根据所述第一创建请求中包括的虚拟机配置文件生成第二容器。

其中，生成的第二容器中包括虚拟机。

子步骤S112，在所述第一创建请求请求GPU资源的情况下，根据所述第一创建请求中的GPU资源需求信息，生成第一容器，并保存与所述第一创建请求对应的所述第一容器和第二容器的对应关系。

子步骤S113，为生成的第二容器进行资源调度，并基于调度的资源拉起该第二容器。

子步骤S114，为生成的第一容器进行资源调度，并基于调度的资源拉起该第一容器。

其中，为该第一容器调度的资源中包括与所述GPU资源需求信息对应的GPU资源。

在所述创建请求为用于创建容器内虚拟机的第一创建请求时，可以根据该第一创建请求中的虚拟机配置文件VM spec生成第二容器，该第二容器负责启动虚拟机，该第二容器中包括与该虚拟机配置文件对应的虚拟机。在该第一创建请求另外请求了GPU资源时，可以根据请求的规格(即GPU资源需求信息)，生成对应的第一容器。由于后续该第二容器内的虚拟器要调用该第一容器的GPU资源，因此此时可保存与该第一创建请求对应的第一容器和第二容器的对应关系，以便后续基于该对应关系建立通信连接。

值得说明的是，在需要将容器内虚拟机和GPU绑定时，可以对应创建第一容器、设置有虚拟机的第二容器，并保存两者的对应关系。在解绑时，则可以不对第二容器进行改变，只删除所对应的对应关系及对应的第一容器即可。在虚拟机内设置有对应的RCUDAClient端的情况下，还可以在虚拟机内进行RCUDA Client端的对应启停即可。

之后，则可以进行资源调度，以向所述第一容器及第二容器分配相应的资源，进而基于该资源拉起该第一容器及第二容器，从而完成有GPU请求的容器内虚拟机的创建。其中，值得说明的是，在针对所述第一容器进行资源调度时，由于该第一容器需要GPU资源，因此要额外经过GPU的调度器根据请求的GPU规格进行调度。

下面结合图7，以应用于Kubernetes集群为例，对上述有GPU请求的容器内虚拟机的创建流程进行举例说明。

(a)Kubernetes集群通过Kubernetes-api收到创建虚拟机的请求，将相关的资源对象存入数据库，比如etcd，也即保存创建虚拟机的请求。

(b)虚拟机的CRD controller(即图6中的VM controller)监听到虚拟机创建请求时，根据与该虚拟机创建请求对应的VM spec生成pod spec文件。该pod spec文件为虚拟机的基本POD(管理libvirt和qemu，负责启动虚拟机)。在该虚拟机创建请求另请求了GPU的资源时，则根据请求的规格创建对应的辅助POD(负责启动辅助容器)。可以虚拟机POD和辅助POD的注释中保存二者的对应关系，或者通过其他的方式保存二者之间的关系，比如数据库。后续二者的通信可通过POD IP实现，或创建对应的cluster service实现，以免POD IP发生变化，当然可以理解的是，也可以通过其他方式实现。

(c)虚拟机的基本POD直接通过Kubernetes集群的通用调度器进行调度。

(d)虚拟机的辅助容器，因为需要实际调用GPU资源，要额外经过GPU的调度器根据请求的GPU规格进行调度。其中，图6中的Extend gpu scheduler表示GPU的调度器，经过GPU的调度器调度GPU资源。

(e)调度后的POD，基本都通过kubelet和对应的运行时将POD拉起。

运行中的虚拟机的绑定和解绑GPU的流程为：虚拟机的基本POD无需改变，只是创建和删除对应的辅助POD以及对应关系，虚拟机内进行对应的RCUDA Client端的启停即可。

请参照图8，图8为图5中步骤S110包括的另一种子步骤的流程示意图。在本实施例中，步骤S110可以包括子步骤S116～子步骤S117。

子步骤S116，在接收到用于创建容器且请求GPU资源的第二创建请求的情况下，根据所述第二创建请求中包括的容器配置文件生成第三容器。

子步骤S117，为生成的第三容器进行资源调度，并基于调度的资源拉起该第三容器。

其中，调度的资源包括GPU资源。

在所述创建请求为用于创建容器的第二创建请求时，可以根据该第二创建请求中的容器配置文件生成第三容器。在该第二创建请求还另外请求了GPU资源时，在针对该第三容器进行资源调度时，还要额外经过GPU的调度器根据请求的GPU规格进行调度，以为该第三容器分配相应的GPU资源。之后，则可以基于调度的资源拉起该第三容器。

下面再次结合图7，以应用于Kubernetes集群为例，对上述有GPU请求的容器的创建流程进行举例说明。

(f)Kubernetes集群中收到创建容器的请求，将相关的资源对象存入数据库，比如etcd。

(g)POD controller监听到创建容器的请求，将其转换为对应的pod spec。

(d)由于该请求有GPU需求，因此要创建的容器的是普通容器；普通容器，因为需要实际调用GPU资源，要额外经过GPU的调度器根据请求的GPU规格进行调度。

(e)调度后的POD，基本都通过kubelet和对应的运行时将POD拉起。

在本实施例中，GPU资源的发现和调度分配以及健康检查均和容器内集群使用一套，辅助容器和普通容器的优先级和使用GPU的方式，保持一致。

本申请实施例解决了容器内虚拟机使用GPU受限的问题，也即，解决了如下问题：容器内虚拟机使用GPU和容器使用GPU的底层实现方法不兼容、不能共享、不能统一调度，对容器内虚拟机的推广和使用产生了较多限制。在本申请实施例提供的容器内虚拟机和容器共享GPU并统一调度的方案中，容器内虚拟机使用GPU和容器使用GPU的底层实现方法兼容，可以集群范围内共享，可以统一调度，提高了GPU的使用率，降低了容器内虚拟机使用GPU的复杂度，可充分发挥容器内虚拟机和容器统一调度和管理的优势。

为了执行上述实施例及各个可能的方式中的相应步骤，下面给出一种处理装置200的实现方式，可选地，该处理装置200可以采用上述图1所示的处理装置200的器件结构。进一步地，请参照图9，图9为本申请实施例提供的处理装置200的方框示意图之一。需要说明的是，本实施例所提供的处理装置200，其基本原理及产生的技术效果和上述实施例相同，为简要描述，本实施例部分未提及之处，可参考上述的实施例中相应内容。所述处理装置200可以包括：通信模块220及处理模块230。

所述通信模块220，用于根据第一容器和设置有虚拟机的第二容器的对应关系，建立所述第一容器和第二容器的通信连接。其中，所述第一容器被分配的图形处理器GPU资源所在的GPU为第三容器可直接访问的GPU，所述第二容器没有被分配GPU资源。

所述处理模块230，用于在第二容器内的虚拟机需要使用GPU资源的情况下，控制所述第二容器内的虚拟机通过所述第一容器与所述第二容器的通信连接，访问所述第一容器对应的GPU，以调用该第一容器被分配的GPU资源。

所述处理模块230，还可以用于在第三容器要使用GPU资源的情况下，控制所述第三容器访问对应的GPU，以使用该第三容器被分配的GPU资源。

请参照图10，图10为本申请实施例提供的处理装置200的方框示意图之二。可选地，在本实施例中，所述处理装置200还可以包括调度管理模块210。

所述调度管理模块210用于：接收输入的创建请求，并根据所述创建请求创建对应的容器或容器内虚拟机。

可选地，在本实施例中，所述调度管理模块210具体用于：在接收到用于创建容器内虚拟机的第一创建请求的情况下，根据所述第一创建请求中包括的虚拟机配置文件生成第二容器，其中，生成的第二容器中包括虚拟机；在所述第一创建请求请求GPU资源的情况下，根据所述第一创建请求中的GPU资源需求信息，生成第一容器，并保存与所述第一创建请求对应的所述第一容器和第二容器的对应关系；为生成的第二容器进行资源调度，并基于调度的资源拉起该第二容器；为生成的第一容器进行资源调度，并基于调度的资源拉起该第一容器，其中，为该第一容器调度的资源中包括与所述GPU资源需求信息对应的GPU资源。

可选地，在本实施例中，所述调度管理模块210具体用于：在接收到用于创建容器且请求GPU资源的第二创建请求的情况下，根据所述第二创建请求中包括的容器配置文件生成第三容器；为生成的第三容器进行资源调度，并基于调度的资源拉起该第三容器，其中，调度的资源包括GPU资源。

可选地，上述模块可以软件或固件(Firmware)的形式存储于图1所示的存储器110中或固化于电子设备100的操作系统(Operating System，OS)中，并可由图1中的处理器120执行。同时，执行上述模块所需的数据、程序的代码等可以存储在存储器110中。

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

综上所述，本申请实施例提供一种处理方法、装置、网络设备及可读存储介质，根据分配有GPU资源的第一容器和没有被分配GPU资源但设置有虚拟机的第二容器的对应关系，建立该第一容器和第二容器的通信连接，在该第二容器内的虚拟机要使用GPU资源的情况下，控制该第二容器内的虚拟机通过上述通信连接访问上述第一容器对应的GPU，以调用该第一容器被分配的GPU资源；在分配有GPU资源的第三容器要使用GPU资源的情况下，控制该第三容器直接访问对应的GPU，以使用该第三容器被分配的资源。其中，所述第三容器及第一容器被分配的GPU资源在同一GPU上。由此，可使容器内虚拟机与容器在同一时刻使用同一块GPU，从而提高GPU的使用率。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

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

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims

1.一种处理方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收输入的创建请求，并根据所述创建请求创建对应的容器或容器内虚拟机。

3.根据权利要求2所述的方法，其特征在于，所述根据所述创建请求创建对应的容器或容器内虚拟机，包括：

在接收到用于创建容器内虚拟机的第一创建请求的情况下，根据所述第一创建请求中包括的虚拟机配置文件生成第二容器，其中，生成的第二容器中包括虚拟机；

在所述第一创建请求请求GPU资源的情况下，根据所述第一创建请求中的GPU资源需求信息，生成第一容器，并保存与所述第一创建请求对应的所述第一容器和第二容器的对应关系；

为生成的第二容器进行资源调度，并基于调度的资源拉起该第二容器；

为生成的第一容器进行资源调度，并基于调度的资源拉起该第一容器，其中，为该第一容器调度的资源中包括与所述GPU资源需求信息对应的GPU资源。

4.根据权利要求2所述的方法，其特征在于，所述根据所述创建请求创建对应的容器或容器内虚拟机，包括：

在接收到用于创建容器且请求GPU资源的第二创建请求的情况下，根据所述第二创建请求中包括的容器配置文件生成第三容器；

为生成的第三容器进行资源调度，并基于调度的资源拉起该第三容器，其中，调度的资源包括GPU资源。

5.一种处理装置，其特征在于，包括：

处理模块，用于在第二容器内的虚拟机需要使用GPU资源的情况下，控制所述第二容器内的虚拟机通过所述第一容器与所述第二容器的通信连接，访问所述第一容器对应的GPU，以调用该第一容器被分配的GPU资源。

6.根据权利要求5所述的装置，其特征在于，所述装置还包括调度管理模块，

所述调度管理模块用于：接收输入的创建请求，并根据所述创建请求创建对应的容器或容器内虚拟机。

7.根据权利要求6所述的装置，其特征在于，所述调度管理模块具体用于：

8.根据权利要求6所述的装置，其特征在于，所述调度管理模块具体用于：

9.一种电子设备，其特征在于，包括处理器和存储器，所述存储器存储有能够被所述处理器执行的机器可执行指令，所述处理器可执行所述机器可执行指令以实现权利要求1-4中任意一项所述的处理方法。

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