CN115454636A - 一种容器云平台gpu资源调度方法、装置及应用 - Google Patents

Abstract

本申请提出了一种算法容器云平台GPU资源调度方法、装置及应用，包括以下步骤：构建一个容器云平台，使用GPU服务端对物理机中所有的GPU资源进行虚拟切割，得到GPU资源列表；当容器云平台收到资源调度请求后，生成调度列表，GPU客户端组件根据所述调度列表进行配置，配置完成后对所述容器云平台发起回应，所述容器云平台根据回应在单独的容器中部署GPU代理组件来管理每一工作服务器的GPU资源；在GPU服务端上为每一工作服务器部署监测代理组件对所述工作服务器进行监测，检测到所述工作服务器越权行为时，由对应的GPU客户端对工作服务器进行隔离。本方案可以基于整个物理机的GPU资源进行安全、统一的调度，避免了被攻击了风险。

Description

一种容器云平台GPU资源调度方法、装置及应用

技术领域

本申请涉及资源调度技术领域，特别是涉及一种容器云平台GPU资源调度方法、装置及应用。

背景技术

近年来随着云计算技术与容器相关技术的发展，Doker和Kubernetes技术已经成为众多企业应用交付的标准，在原生的Kubernetes容器云平台中，算法应用主要用GPU显存来运行，Nvidia官方提供了相应的GPU容器调度能力，但是通常都是将一个GPU卡分配给一个容器，无法支持复杂资源的分配。

由于Navidia关于GPU内核目前大部分处于未开源的状态，对于GPU资源共享的方式往往是通过CUDA本地劫持来实现的，CUDA本地劫持通过调用CUDA API，进而调用GPU硬件进行并行计算，libcuda.so是用户态下最终会被调用的Driver API库，它的接口公开但是实现细节闭源，通过实现一个例如libvendot-cuda.so的动态库劫持了应用程序对CUDADriver API的调用，并且把调用转发给真实的GPU原厂的libcuda.so，在转发过程中，绝大部分的API可以直接透传，而通过对少量API进行流控和修改，做到将不同的容器绑定到同一张GPU卡上，并进行相应的显存控制。综上所述，上述方案基本都是在保留官方功能的基础上，通过device-plugin插件对业务容器内注入vGPU配置参数，实现对GPU的显存和计算单元进行限制的目的，从而在一个物理GPU上模拟出多张小的vGPU卡，而且此类本地劫持CUDA方案的左、中、右三层处在同一个容器内部，而且访问权限一致，由于处在同一容器，用户完全有可能绕过中间的限制，去直接触达原生CUDA，存在被隐秘信道攻坚、侧信道攻击和内存溢出攻击的风险，同时导致容器与GPU、Nvidia插件、服务器绑定，失去了容器自动迁移，故障自愈的优越性。

而在Kubernetes集群中，采用扩展调度器(Scheduler)对这些切分后的vGPU进行调度，使不同的容器可以共享同一张物理GPU，提高GPU的利用率。

综上所述，目前现有技术实现GPU资源调度存在以下问题：1.算法容器与服务器高度绑定，仅支持单机虚拟化GPU卡，失去了容器自动迁移，故障自愈的优越性；2.存在安全问题，GPU、cuda驱动、容器在同一层，存在隐秘信道攻击、侧信道攻击和内存溢出攻击的风险。

发明内容

本申请实施例提供了一种容器云平台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资源调度方法。

本发明的主要贡献和创新点如下：

本申请实施例采用C/S架构，所述工作服务器通过所述GPU客户端组件与所述GPU服务端进行通信，在整个软件栈中，所述GPU客户端组件在CUDA driver这个层面上截获了所有的CUDA服务访问，将这些服务访问和数据通过网络传递给所述GPU服务端，所述GPU服务端把所述服务访问交给GPU进行处理，实现了在GPU上进行计算与内存资源协同隔离。

在所述容器云平台中存在GPU控制中心，GPU控制中心与所述GPU服务端保持心跳连接，并全方位的对所述GPU客户端进行监控，发现其危险行为，做到GPU资源调度任务的安全调度，对于每个所述工作服务器，一方面做到了进程隔离，另一方面在所述GPU客户端调用GPU资源的时候，做到了SM隔离，根据每个所述工作服务器的权限提供伴生信息，确认获取的GPU资源只能获得其占用SM上的资源利用数据，做到了GPU伴生信息脱敏，相较于现有技术，本方案通过对物理机中所有的GPU资源进行两个资源维度的虚拟切割，突破了对本地物理机上的GPU进行虚拟切割的限制，并将其转变为对于整个数据中心范围的GPU资源调用，增强了GPU算法容器的故障自愈能力，并将所述GPU客户端组件与所述GPU服务端进行资源列表请求的绑定，并通过监测代理组件对GPU行为分析安全调度。

本申请的一个或多个实施例的细节在以下附图和描述中提出，以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的一种容器云平台GPU资源调度方法的流程图；

图2是根据本申请实施例的一种容器云平台中GPU控制中心、GPU客户端和GPU服务端的交互示意图；

图3是根据本申请实施例的一种容器云平台GPU资源调度装置的结构框图；

图4是根据本申请实施例的电子装置的硬件结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

为了便于理解本方案，在此对实施例中出现的一些技术名词加以解释：

CUDA(Compute Unified Device Architecture)：是显卡厂商NVIDIA推出的运算平台。CUDA^TM是一种由NVIDIA推出的通用并行计算架构，该架构使GPU能够解决复杂的计算问题。它包含了CUDA指令集架构(ISA)以及GPU内部的并行计算引擎。开发人员可以使用C语言来为CUDA^TM架构编写程序，所编写出的程序可以在支持CUDA^TM的处理器上以超高性能运行。

Prometheus：Prometheus是一个开源的系统监控和报警系统，在Kubernetes容器管理系统中，通常会使用Prometheus进行监控，同时Prometheus也支持多种exporter采集数据，还支持pushgateway进行数据上报，Prometheus的性能足够支撑上万台规模的集群。

Metric：metric提供了一个强大的工具包，用于衡量生产环境中关键组件的行为，让我们可以对服务中的一些行为进行监控和统计。

Etcd：为Kubernetes中的存储集群。

Response：Response是web容器在用户每次请求服务端的时候，创建的一对容器对象，Response容器是服务端返还给客户端的一个响应内容对象容器。

Sidecar：Sidecar是将应用程序的组件部署到单独的进程或容器中，以提供隔离和封装，此模式还允许应用程序由异构组件和技术实现。

Agent：Agent是在客户端上部署一个Agent进程，客户端与服务端通过这个Agent进程进行代理，其中Agent与客户端通常在同一主机，可直接通过licalhost进行访问。

SM：SM单元，全称Streaming Multiprocessors，是GPU资源的一种，其中包含了多个SP(streaming processor)，即流处理器，每个SP可以跑一个线程，在一个SM单元中的多个SP可以共享上下文。

隐秘信道攻击：木马程序与间谍程序首先在GPU上实现同驻，随后基于GPU物理资源的争用实现了间谍程序与木马程序的信息传输。

侧信道攻击：攻击者可以通过资源争用方式或非资源争用方式不断访问性能技术函数，获得GPU资源利用量，构建侧信道恢复内核中的有价值的信息。

内存溢出攻击，攻击者绕过中间的限制，去直接触达原生代码，进而霸占整个物理GPU，引发内存溢出。

实施例一

本申请实施例提供了一种容器云平台GPU资源调度方法，可以对本地物理机上的GPU进行虚拟切割的限制，从而调用整个数据中心的GPU资源，并降低了容器云平台被攻击的风险，具体地，参考图1，所述方法包括：

构建容器云平台，所述容器云平台包括信息互通的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为基础构建，除本申请实施例提到的功能以及组件外，具有Kubernetes的所有常规功能和组件。

在一些实施例中，所述GPU控制中心、GPU客户端和GPU服务端的交互如图2所示，所述GPU控制中心包括控制中心调度模块、控制中心监控模块和控制中心鉴权模块；所述GPU客户端包括客户端鉴权模块和客户端容器管理模块；所述GPU服务端包括服务端鉴权模块、服务端GPU管理模块和服务端资源列表模块。

具体的，所述GPU控制中心的控制中心调度模块负责处理GPU资源的调度请求，在进行调度时基于树状拓扑结构对所述GPU资源来自容器云平台的etcd集群的信息进行调度，所述树状拓扑结构的根节点是一个物理机，叶子节点为GPU卡，所述根节点和多个叶子节点组成一个拓扑集群。所述GPU控制中心的控制中心监控模块负责监控GPU卡的信息，并开放接口以供prometheus进行监测结果的拉取，同时对收集到的metric信息进行风险分析；所述GPU控制中心的控制中心鉴权模块负责与所述GPU客户端和GPU服务端进行通信，对GPU客户端分发公钥，并对风险容器进行隔离判断。

具体的，所述GPU客户端的客户端鉴权模块负责与所述GPU控制中心和GPU服务端进行通信以及与所述GPU服务端进行连接，并接收所述控制中心鉴权模块分发的公钥；所述GPU客户端的客户端容器管理模块负责拦截所述容器云平台中CUDA库中的内存和计算相关的API，转而通过GPU客户端与GPU服务端进行远程调度，并对调度内容进行分析。

具体的，所述GPU服务端的服务端鉴权模块负责与所述GPU控制中心和GPU客户端进行通信以及与所述GPU客户端进行连接；所述GPU管理模块负责将物理机中所有的GPU资源进行两个资源维度的虚拟切割，并可用于启动GPU代理组件和GPU计算容器；所述资源列表模块向每一工作服务器上的控制组件发送注册请求，在每一控制组件中进行注册，注册成功后每一所述控制组件以列表形式发送其对应工作服务器的资源请求，所述服务端资源列表模块根据所述资源请求将GPU资源列表返回给所述容器云平台。

在一些实施例中，在“GPU服务端获取物理机中所有的GPU资源，并对每一GPU资源进行两个资源维度的虚拟切割”步骤中，获取物理机中GPU卡的数量和每张GPU卡的资源量，将每一GPU卡虚拟切割为多个显存资源和多个计算资源两个资源维度。

示例性的，将256M作为一个显存资源对每张GPU卡进行划分，根据每张GPU卡的显存大小不同可以划分为不同数量的显存资源，每一显存资源对应自身所属的GPU卡；将每张GPU卡划分为100个计算资源，则每一计算资源拥有百分之一的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资源列表。

示例性的，以Kubenetes(K8S)为例，GPU服务端首先会向K8S中每一工作服务器的Kubelet发起注册请求，在Kubelet中进行注册，之后Kubelet会向所述GPU服务端以列表的形式发送资源请求，所述GPU服务端根据所述资源列表请求将GPU资源列表返回给所述容器云平台。

示例性的，所述GPU资源列表存储在所述容器云平台的etcd集群中进行存储，所述容器云平台的每个工作服务器资源量使用所述GPU资源列表的格式进行显示，也就是说，每一工作服务器显示自身使用GPU资源总量信息，已使用的GPU卡数，每一GPU卡对应的显存资源和计算资源进行列表格式的显示。

在一些实施例中，所述资源调度请求的类型为独享型或共享性，根据不同的请求类型生成不同的调度方式，根据所述调度方式得到调度信息，将所述调度信息、需要进行资源调度的目标工作服务器和其配置文件、GPU服务端进行组合，生成调度列表。

进一步的，当调度请求的类型为独享型时存在以下调度方式：

1)若请求的条件为一张GPU卡，但请求的资源量大于所述GPU资源列表中最大单张GPU卡的可用资源时，显示调度失败；

2)若请求的条件为多张GPU卡，且所述GPU资源列表中存在大于请求资源量的单张CPU卡的可用资源时，获取所述GPU资源列表，从资源量最小的单张GPU卡开始对所述GPU资源列表进行遍历，并结合所述目标工作服务器的网络拓扑和本身的资源列表请求对GPU客户端进行匹配，当遍历到合适的单张GPU卡时，将该GPU卡虚拟为多个不同的GPU卡与GPU客户端进行匹配，提供给目标工作服务器进行使用，且将该GPU卡以及虚拟后的多张GPU卡标记为独享模式，其中的剩余GPU资源不再进行分配。为了降低网络影响，在进行匹配时，优先选择所述目标工作服务器存在GPU资源的工作服务器上，因为一些工作服务器中仅存在CPU资源，在进行调用GPU资源时，需要通过交换机等网络设备，而在对存在GPU资源的工作服务器上进行调用时则不需要经过交换机等网络设备；

3)若请求的条件为多张GPU卡，且所述GPU资源列表中不存在大于请求资源量的单张GPU卡的可用资源时，需要多张不同的GPU卡协同提供，获取所述GPU资源列表，按照单叶子节点数量最接近的进行遍历，得到所有满足条件的组合列表，将所述组合列表结合所述目标工作服务器的网络拓扑和本身的资源列表请求对GPU客户端进行匹配，得到匹配结果，将所述匹配结果中的多张GPU卡标记为独享模式，其中的剩余GPU资源不再进行分配；

4)若请求的条件为单张CPU卡，所述GPU资源列表中存在大于请求资源量的单张GPU卡的可用资源时，获取所述GPU资源列表，按照单叶子节点数量最少的原则进行遍历，得到所有满足条件的组合列表，将所述组合列表结合所述目标工作服务器的网络拓扑和本身的资源列表请求对GPU客户端进行匹配，得到匹配结果，将所述匹配结果中的单张GPU卡标记为独享模式，其中的剩余GPU资源不再进行分配。

进一步的，当调度请求的类型为共享型时，以树状拓扑图的形式生成一个共享资源列表，对所述GPU资源列表进行遍历，将未提供GPU资源的GPU卡和共享标记下的虚拟GPU卡放入所述共享资源列表中，共享型的调度存在以下调度方式：

1)若请求的条件为单张GPU卡，但请求的资源量大于所述共享资源列表中最大单张GPU卡的可用资源时，显示调度失败；

2)若请求的条件为多张GPU卡，所述共享资源列表中存在大于请求资源量的单张GPU卡，则从剩余资源量最小的单张GPU卡开始对所述共享资源列表进行遍历，并结合所述目标工作服务器的网络拓扑和本身的资源列表请求对GPU客户端进行匹配，当遍历到合适的单张GPU卡时，将该GPU卡虚拟为多个不同的GPU卡与GPU客户端进行匹配，提供给目标工作服务器进行使用，且将该GPU卡以及虚拟后的多张GPU卡标记为共享模式，若有剩余资源再进行分配；

3)若请求的条件为多张GPU卡，所述共享资源列表中不存在大于请求资源量的单张GPU卡时，则需要多张GPU卡提供协助，获取所述共享资源列表，按照单叶子节点数量最接近的进行遍历，得到所有满足条件的组合列表，将所述组合列表结合所述目标工作服务器的网络拓扑和本身的资源列表请求对GPU客户端进行匹配，得到匹配结果，将所述匹配结果中的多张GPU卡标记为共享模式，其中的剩余GPU资源再进行分配；

4)若请求的条件为单张CPU卡，所述共享资源列表中存在大于请求资源量的单张GPU卡的可用资源时，获取所述共享资源列表，按照单叶子节点数量最少的原则进行遍历，得到所有满足条件的组合列表，将所述组合列表结合所述目标工作服务器的网络拓扑和本身的资源列表请求对GPU客户端进行匹配，得到匹配结果，将所述匹配结果中的单张GPU卡标记为共享模式，其中的剩余GPU资源再进行分配。

具体的，通过对调度请求的判断，和对不合理的调度请求进行拒绝，防止了对GPU资源的过渡调用，减少出现内存溢出的可能性。

在一些实施例中，在“GPU客户端组件根据所述调度列表进行配置并对所述容器云平台发起回应”步骤中，所述GPU客户端组件收到调度列表后，创建一个目录，用来保存所述对应工作服务器的配置信息、请求、及操作日志，且所述GPU客户端根据所述调度列表虚拟出GPU资源，并以Response的形式向所述容器云平台发起回应。

具体的，由所述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客户端的返回形式Response创建并初始化一个容器，并以sidecar旁挂的形式启动一个GPU代理组件(vGPUagent)，并运行在一个pod中，所述GPU代理组件用来管理GPU资源。

在一些实施例中，在所述GPU服务端上为每一工作服务器部署监测代理组件和配置文件，所述监测代理组件以一定的时间频率对所述容器云平台发送监测信息，所述容器云平台通过监测信息对所述工作服务器进行监测，检测到所述工作服务器越权行为时，由对应的GPU客户端对工作服务器进行隔离，所述配置文件中存有所述工作服务器的命名空间信息、容器信息、GPU资源信息；所述GPU计算容器根据所述调度列表对不同的工作服务器所需要的GPU资源做虚拟切割，并且通过调用内核模块进行SM隔离，以防止上下文信息的泄露。

具体的，所述GPU服务器根据预调度列表对每一所述工作服务器生成监测代理组件，所述检测代理组件以sidecar的方式挂载到所述工作服务器上；所述配置文件为yaml格式。

具体的，所述GPU服务器根据所述工作服务器的配置文件生成公钥、私钥，将公钥上传到所述GPU控制中心中，由所述GPU控制中心分发对应的公钥到每一所述GPU客户端组件上，以便GPU客户端组件对GPU服务器进行访问，当所述GPU客户端组件首次对GPU服务器进行访问时，对所述GPU客户端组件进行验证，验证通过后，将所述GPU客户端组件与对应的监测代理组件和GPU容器资源进行绑定，绑定后，所述工作服务器需要调用GPU资源时，将通过GPU客户端组件进行劫持请求后对所述GPU计算容器中的资源进行调用。

具体的，所述GPU计算容器通过调用内核模块进行SM的隔离，其根据权限提供伴生信息，确保所述工作服务器获取的虚拟GPU资源只能获得其占用SM上的资源利用数据，做到了GPU伴生信息脱敏。

具体的，所述监测代理组件伴随着对应的工作服务器进行启动，所述监测代理组件每隔一定时间向所述容器云平台发送metric信息，所述容器云平台根据metric信息检查所述工作服务器是否具有越权行为或是否存在风险点，同时，所述容器云平台收到metric信息后会开发相关接口，以便prometheus将metric信息拉取显示在前端界面，若所述容器云平台监测到越权行为或风险点，则通知所述工作服务器对应的GPU客户端对该工作服务器进行隔离，目的是防止隐秘信道攻击和侧信道攻击。

在一些实施例中，每一工作服务器中的GPU客户端组件会周期性的检查工作服务器是否存活，若所述工作服务器已经销毁，则向所述容器云平台发送通知，所述容器云平台收到相关通知后，确认所述工作服务器的健康状态，若确认所述工作服务器已经销毁，通知所述GPU服务端释放所述工作服务器的GPU资源。

实施例二

另外，本方案还提供一种容器云平台，所述容器云平台包括GPU控制中心、GPU客户端、GPU服务端和若干个工作服务器，用于执行实施例一所述的一种容器云平台GPU资源调度方法。

实施例三

基于相同的构思，参考图3，本申请还提出了一种容器云平台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计算容器中的资源进行调用；

实施例四

本实施例还提供了一种电子装置，参考图4，包括存储器404和处理器402，该存储器404中存储有计算机程序，该处理器402被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

具体地，上述处理器402可以包括中央处理器(CPU)，或者特定集成电路(ApplicationSpecificIntegratedCircuit，简称为ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

其中，存储器404可以包括用于数据或指令的大容量存储器404。举例来说而非限制，存储器404可包括硬盘驱动器(HardDiskDrive，简称为HDD)、软盘驱动器、固态驱动器(SolidStateDrive，简称为SSD)、闪存、光盘、磁光盘、磁带或通用串行总线(UniversalSerialBus，简称为USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器404可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器404可在数据处理装置的内部或外部。在特定实施例中，存储器404是非易失性(Non-Volatile)存储器。在特定实施例中，存储器404包括只读存储器(Read-OnlyMemory，简称为ROM)和随机存取存储器(RandomAccessMemory，简称为RAM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(ProgrammableRead-OnlyMemory，简称为PROM)、可擦除PROM(ErasableProgrammableRead-OnlyMemory，简称为EPROM)、电可擦除PROM(ElectricallyErasableProgrammableRead-OnlyMemory，简称为EEPROM)、电可改写ROM(ElectricallyAlterableRead-OnlyMemory，简称为EAROM)或闪存(FLASH)或者两个或更多个以上这些的组合。在合适的情况下，该RAM可以是静态随机存取存储器(StaticRandom-AccessMemory，简称为SRAM)或动态随机存取存储器(DynamicRandomAccessMemory，简称为DRAM)，其中，DRAM可以是快速页模式动态随机存取存储器404(FastPageModeDynamicRandomAccessMemory，简称为FPMDRAM)、扩展数据输出动态随机存取存储器(ExtendedDateOutDynamicRandomAccessMemory，简称为EDODRAM)、同步动态随机存取内存(SynchronousDynamicRandom-AccessMemory，简称SDRAM)等。

存储器404可以用来存储或者缓存需要处理和/或通信使用的各种数据文件，以及处理器402所执行的可能的计算机程序指令。

处理器402通过读取并执行存储器404中存储的计算机程序指令，以实现上述实施例中的任意一种容器云平台GPU资源调度方法。

可选地，上述电子装置还可以包括传输设备406以及输入输出设备408，其中，该传输设备406和上述处理器402连接，该输入输出设备408和上述处理器402连接。

传输设备406可以用来经由一个网络接收或者发送数据。上述的网络具体实例可包括电子装置的通信供应商提供的有线或无线网络。在一个实例中，传输设备包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输设备406可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。

输入输出设备408用于输入或输出信息。在本实施例中，输入的信息可以是资源调度请求、GPU资源列表等，输出的信息可以是调度列表等。

可选地，在本实施例中，上述处理器402可以被设置为通过计算机程序执行以下步骤：

S101、构建容器云平台，所述容器云平台包括信息互通的GPU控制中心、GPU客户端、GPU服务端和若干个工作服务器，所述GPU服务端获取物理机中所有的GPU资源，并对每一GPU资源进行两个资源维度的虚拟切割，得到GPU资源列表信息，所述GPU资源列表信息存储在容器云平台中，所述GPU客户端以GPU客户端组件的形式挂载在每一工作服务器上；

S102、所述GPU控制中心获取的用户的资源调度请求，基于所述GPU资源列表信息生成调度列表，并将所述调度列表发送到每一工作服务器上的GPU客户端组件和所述GPU服务端中，GPU客户端组件根据所述调度列表进行配置并对所述容器云平台发起回应，所述容器云平台根据所述回应创建一个容器，并在所述容器中部署GPU代理组件来管理每一工作服务器的GPU资源，所述GPU代理组件与每一所述GPU客户端组件连接，所述GPU服务端根据所述调度列表，生成与所述工作服务器一一对应的GPU计算容器，每一所述GPU计算容器中存有对应工作服务器所需的GPU资源，所述GPU客户端组件与所述GPU服务端进行连接并对每一所述GPU计算容器中的资源进行调用。

需要说明的是，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

通常，各种实施例可以以硬件或专用电路、软件、逻辑或其任何组合来实现。本发明的一些方面可以以硬件来实现，而其他方面可以以可以由控制器、微处理器或其他计算设备执行的固件或软件来实现，但是本发明不限于此。尽管本发明的各个方面可以被示出和描述为框图、流程图或使用一些其他图形表示，但是应当理解，作为非限制性示例，本文中描述的这些框、装置、系统、技术或方法可以以硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其他计算设备或其某种组合来实现。

本发明的实施例可以由计算机软件来实现，该计算机软件由移动设备的数据处理器诸如在处理器实体中可执行，或者由硬件来实现，或者由软件和硬件的组合来实现。包括软件例程、小程序和/或宏的计算机软件或程序(也称为程序产品)可以存储在任何装置可读数据存储介质中，并且它们包括用于执行特定任务的程序指令。计算机程序产品可以包括当程序运行时被配置为执行实施例的一个或多个计算机可执行组件。一个或多个计算机可执行组件可以是至少一个软件代码或其一部分。另外，在这一点上，应当注意，如图4中的逻辑流程的任何框可以表示程序步骤、或者互连的逻辑电路、框和功能、或者程序步骤和逻辑电路、框和功能的组合。软件可以存储在诸如存储器芯片或在处理器内实现的存储块等物理介质、诸如硬盘或软盘等磁性介质、以及诸如例如DVD及其数据变体、CD等光学介质上。物理介质是非瞬态介质。

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

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

Claims (13)

1.一种容器云平台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计算容器中的资源进行调用。

2.根据权利要求1所述的一种容器云平台GPU资源调度方法，其特征在于，在“GPU服务端获取物理机中所有的GPU资源，并对每一GPU资源进行两个资源维度的虚拟切割”步骤中，获取物理机中GPU卡的数量和每张GPU卡的资源量，将每一GPU卡虚拟切割为多个显存资源和多个计算资源两个资源维度。

3.根据权利要求1所述的一种容器云平台GPU资源调度方法，其特征在于，“所述GPU资源列表存储在容器云平台中”步骤包括，所述GPU服务端先在容器云平台中进行注册，注册成功后所述容器云平台向所述GPU服务端发送资源列表请求，所述GPU服务端收到资源列表请求后将GPU资源列表返回给所述容器云平台，所述GPU资源列表以外部资源的形式显示在容器云平台的可分配资源中，并将所述GPU资源列表存储在容器云平台中。

4.根据权利要求1所述的一种容器云平台GPU资源调度方法，其特征在于，所述资源调度请求的类型为独享型或共享型，根据不同的请求类型生成不同的调度方式，根据所述调度方式得到调度信息，将所述调度信息、需要进行资源调度的目标工作服务器和其配置文件、GPU服务端进行组合，生成调度列表。

5.根据权利要求4所述的一种容器云平台GPU资源调度方法，其特征在于，当调度请求为独享型时，对所述GPU资源列表中未提供GPU资源的GPU卡进行遍历。

6.根据权利要求4所述的一种容器云平台GPU资源调度方法，其特征在于，当调度请求的类型为共享型时，以树状拓扑图的形式生成一个共享资源列表，对所述GPU资源列表进行遍历，将未提供GPU资源的GPU卡和共享标记下的虚拟GPU卡放入所述共享资源列表中。

7.根据权利要求1所述的一种容器云平台GPU资源调度方法，其特征在于，在“将所述调度列表发送到每一工作服务器上的GPU客户端组件和所述GPU服务端中”步骤包括，所述GPU客户端组件和所述GPU服务端收到调度列表后进行心跳测试，若心跳测试失败，重新生成调度列表，若心跳测试成功保持连接状态，则进行GPU资源调度；所述GPU服务端收到调度列表后与当前GPU资源列表进行比较，若资源不符，则返回失败请求，重新生成调度列表，若所述当前GPU资源列表与所述调度列表资源相符，则进行GPU资源调度。

8.根据权利要求1所述的一种容器云平台GPU资源调度方法，其特征在于，在所述GPU服务端上为每一工作服务器部署监测代理组件和配置文件，所述监测代理组件以一定的时间频率对所述容器云平台发送监测信息，所述容器云平台通过监测信息对所述工作服务器进行监测，检测到所述工作服务器越权行为时，由对应的GPU客户端对工作服务器进行隔离，所述配置文件中存有所述工作服务器的命名空间信息、容器信息、GPU资源信息；所述GPU计算容器根据所述调度列表对不同的工作服务器所需要的GPU资源做虚拟切割，并且通过调用内核模块进行SM隔离。

9.根据权利要求1所述的一种容器云平台GPU资源调度方法，其特征在于，每一工作服务器中的GPU客户端组件会周期性的检查工作服务器是否存活，若所述工作服务器已经销毁，则向所述容器云平台发送通知，所述容器云平台收到相关通知后，确认所述工作服务器的健康状态，若确认所述工作服务器已经销毁，通知所述GPU服务端释放所述工作服务器的GPU资源。

10.一种容器云平台，所述容器云平台包括GPU控制中心、GPU客户端、GPU服务端和若干工作服务器，其特征在于，用于执行权利要求1-9任一所述的一种容器云平台GPU资源调度方法。

11.一种容器云平台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计算容器中的资源进行调用。

12.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行权利要求1-9任一所述的一种容器云平台GPU资源调度方法。

13.一种可读存储介质，其特征在于，所述可读存储介质中存储有计算机程序，所述计算机程序包括用于控制过程以执行过程的程序代码，所述过程包括根据权利要求1-9任一项所述的一种容器云平台GPU资源调度方法。

Images