一种基于共享式GPU的分布式容器调度方法及其系统

技术领域

本发明涉及一种基于共享式GPU的分布式容器调度方法及其系统，属于云计算技术领域。

背景技术

由于云计算的发展，采用Kubernetes(管理云平台中多个主机上的容器化的应用)可以极大的提升服务器集群中资源利用率。然而随着云计算业务的多样化、复杂化，同时使用容器搭配GPU以提升业务和工作流的性能和效率已经成为了边缘计算和大型分布式机器学习的计算搭配主力，而现有的分布式容器调度器大部分仅仅能基于CPU和内存指标调度容器任务，或者只能简单检测GPU数量而不能检测显卡细颗粒的性能指标来实现GPU共享，现有的分布式容器调度器无法适配各种复杂场景的计算需求，导致有特定GPU需求的容器被调度在非适配节点上运行，使得整个分布式集群的GPU资源利用率低下，影响整个分布式集群性能。

在云计算领域，应用GPU的业务和工作流逐渐多样化，如云游戏、机器学习训练，这将会给针对GPU资源的调度带来更多的挑战，分布式集群的容器调度需要基于当前集群内的GPU指标状态合理调度容器，否则会导致整个分布式集群内部任务分配不均衡，影响GPU资源调度结果，间接造成分布式集群运算效率的低下。

发明内容

为了解决多样化的云计算业务中容器调度不合理、GPU资源利用率低下的问题，本发明提出了一种基于共享式GPU的分布式容器调度方法及其系统，实现对容器创建事件的监听、容器调度队列生成和容器调度，本发明能够针对待调度容器的需求选择最适配的节点进行容器调度，保证集群内部节点的负载均衡，提高集群的资源利用率。

为解决上述技术问题，本发明采用了如下技术手段：

第一方面，本发明提出了一种基于共享式GPU的分布式容器调度方法，包括如下步骤：

实时监听Kubernetes API-Server中的容器创建事件，并在监测到新的容器创建事件后，对创建的容器进行校验；

利用校验成功的容器更新容器调度队列；

当容器调度队列不为空时，按顺序从容器调度队列中读取待调度容器，并从Kubernetes集群中选出待调度容器对应的最佳节点，生成容器调度二元组；

根据容器调度二元组将待调度容器调度到最佳节点上，完成分布式容器调度。

结合第一方面，进一步的，对创建的容器进行校验的方法为：

根据创建的容器的字段信息进行GPU标签校验：判断容器是否包含GPU标签，当容器不包含GPU标签，则GPU标签校验失败，将校验失败时间和对应的错误信息写入Kubernetes事件日志，否则GPU标签校验成功，其中，所述GPU标签包括GPU数量标签、GPU显存标签、GPU时钟频率标签；

当GPU标签校验成功，根据创建的容器的字段信息进行调度器名称校验：判断容器的调度器字段是否为系统调度器名称，当调度器字段不是系统调度器名称，则调度器名称校验失败，将校验失败时间和对应的错误信息写入Kubernetes事件日志，否则，调度器名称校验成功，完成容器校验。

结合第一方面，进一步的，利用校验成功的容器更新容器调度队列的方法为：

将校验成功的容器从队尾送入容器调度队列；

获取容器调度队列中每个容器预设的优先级标签，根据优先级标签将容器调度队列中的所有容器从高到低排序，完成容器调度队列更新。

结合第一方面，进一步的，从Kubernetes集群中选出待调度容器对应的最佳节点的方法为：

根据Kubernetes集群中每个节点的GPU数据和待调度容器的GPU标签进行节点选择和过滤，获得容器可调度节点；

当容器可调度节点数量为1，将该容器可调度节点作为最佳节点；

当容器可调度节点数量大于1，基于容器可调度节点的GPU数据计算每个容器可调度节点的得分，选取得分最高的容器可调度节点作为最佳节点。

结合第一方面，进一步的，获得容器可调度节点的具体操作为：

当待调度容器携带GPU数量标签时，遍历Kubernetes集群中的所有节点，当节点所持有的GPU数量大于等于GPU数量标签值，则将该节点标记为一次可调度节点，当待调度容器未携带GPU数量标签，将Kubernetes集群中的所有节点标记为一次可调度节点，并将该待调度容器的GPU数量标签值设置为1；

当待调度容器携带GPU显存标签，遍历所有一次可调度节点，当一次可调度节点中GPU空闲显存大于GPU显存标签值的GPU数量大于等于该待调度容器的GPU数量标签值时，将该一次可调度节点标记为二次可调度节点，当待调度容器未携带GPU显存标签，将所有一次可调度节点标记为二次可调度节点；

当待调度容器携带GPU时钟频率标签，遍历所有二次可调度节点，当二次可调度节点中GPU时钟频率大于GPU时钟频率标签值的GPU数量大于等于该待调度容器的GPU数量标签值时，将该二次可调度节点标记为容器可调度节点，当待调度容器未携带GPU时钟频率标签，将所有二次可调度节点标记为容器可调度节点；

当容器可调度节点为空时，将当前时间和调度错误信息写入Kubernetes事件日志。

结合第一方面，进一步的，基于容器可调度节点的GPU数据计算每个容器可调度节点的得分的计算公式如下：

其中，Score表示容器可调度节点的得分，FilteredGPUScore表示容器可调度节点中满足待调度容器要求的所有GPU的GPU得分，所述待调度容器要求为待调度容器的GPU显存标签和GPU时钟频率标签，FilteredGPUWeight为GPU得分的权重，RealScore表示容器可调度节点中所有GPU的显存得分，RealWeight为显存得分的权重，AllocateScore表示容器可调度节点的配额得分，AllocateWeight为配额得分的权重；

FilteredGPUScore的计算公式为：

FilteredGPUScore＝∑FilteredGPUScorePerCard (2)

其中，FilteredGPUScorePerCard表示容器可调度节点中满足待调度容器要求的GPU的GPU分数，Bandwith表示GPU显存位宽，MaxBandwith表示容器可调度节点中满足待调度容器要求的所有GPU的GPU显存位宽最大值，Clock表示GPU时钟频率，MaxClock表示容器可调度节点中满足待调度容器要求的所有GPU的GPU时钟频率最大值，Power表示GPU功率，MaxPower表示容器可调度节点中满足待调度容器要求的所有GPU的GPU功率最大值，Core表示GPU核心数，MaxCore表示容器可调度节点中满足待调度容器要求的所有GPU的GPU核心数最大值，FreeMemory表示GPU空闲显存，MaxFreeMemory表示容器可调度节点中满足待调度容器要求的所有GPU的GPU空闲显存最大值，TotalMemory表示GPU显存总量，MaxTotalMemory表示容器可调度节点中满足待调度容器要求的所有GPU的GPU显存总量最大值；

RealScore的计算公式为：

其中，FreeMemorySum表示容器可调度节点中所有GPU的GPU空闲显存之和，TotalMemorySum表示容器可调度节点中所有GPU的GPU显存总量之和；

AllocateScore的计算公式为：

其中，AllocateMemorySum表示待调度容器申请的显存总量，即待调度容器的GPU显存标签值与GPU数量标签值的乘积。

结合第一方面，进一步的，所述容器调度二元组由待调度容器和最佳节点的节点名称组成。

结合第一方面，进一步的，根据容器调度二元组将待调度容器调度到最佳节点上的具体操作为：

根据容器调度二元组，将待调度容器的节点名称字段设置为二元组中最佳节点的节点名称，并异步更新Kubernetes API-Server中该容器的节点名称字段。

第二方面，本发明提出了一种基于共享式GPU的分布式容器调度系统，包括：

容器创建事件监听器，用于监听Kubernetes API-Server中的容器创建事件，并在监测到新的容器创建事件之后进行容器校验；

容器调度队列，用于按照优先级存放待调度的容器；

容器调度器，用于从容器调度队列的队头读取待调度容器，并从Kubernetes集群中选出待调度容器对应的最佳节点，生成容器调度二元组；

容器调度执行器，用于根据容器调度二元组更新Kubernetes API-Server中待调度容器的节点名称字段，完成容器调度操作；

通信模块，用于根据系统配置文件分别构建容器创建事件监听器、容器调度队列、容器调度器、容器调度执行器与Kubernetes API-Server的通信。

结合第二方面，进一步的，所述系统配置文件包括Kubernetes API-Server的IP地址、端口号、TLS公钥和TLS私钥；

根据系统配置文件构建通信的操作为：

根据IP地址和端口号建立容器创建事件监听器、容器调度队列、容器调度器、容器调度执行器与Kubernetes API-Server的通信链路；

根据TLS公钥和TLS私钥对通信链路进行认证，认证成功后完成通信构建。

采用以上技术手段后可以获得以下优势：

本发明提出了一种基于共享式GPU的分布式容器调度方法及其系统，在容器调度过程中，本发明基于容器的GPU数量、显存、时钟频率等要求进行节点选择，通过根据集群中GPU显卡的细颗粒度指标状态合理调度容器，使得多容器任务可以共享GPU，通过同时考虑节点内的显卡指标状态、空闲显存和配额情况来将待调度容器调度到最适配的节点上，从而提高集群的GPU资源利用率，以适配复杂场景的计算需求。与现有技术相比，本发明能够保证集群内部节点的负载均衡，增强了分布式容器集群中的GPU资源利用率，更好的满足调度需求，让容器有更快的任务完成时间。

附图说明

图1为本发明一种基于共享式GPU的分布式容器调度方法的步骤流程图；

图2为本发明实施例中更新容器调度队列的操作流程图；

图3为本发明实施例中节点选择和过滤的操作流程图；

图4为本发明一种基于共享式GPU的分布式容器调度系统的结构示意图；

图5为本发明实施例中分布式容器调度系统的工作原理图；

图6为本发明实施例中不同调度器进行容器调度时负载平衡熵的变化示意图；

图7为本发明实施例中不同调度器进行容器调度时调度时间的变化示意图；

图中，1是容器创建事件监听器，2是容器调度队列，3是容器调度器，4是容器调度执行器，5是通信模块。。

具体实施方式

下面结合附图对本发明的技术方案作进一步说明：

本发明提出了一种基于共享式GPU的分布式容器调度方法，如图1所示，具体包括如下步骤：

步骤A、实时监听Kubernetes API-Server中的容器创建事件，并在监测到新的容器创建事件后，对创建的容器进行校验；

步骤B、利用校验成功的容器更新容器调度队列；

步骤C、当容器调度队列不为空时，按顺序从容器调度队列中读取待调度容器，并从Kubernetes集群中选出待调度容器对应的最佳节点，生成容器调度二元组；

步骤D、根据容器调度二元组将待调度容器调度到最佳节点上，完成分布式容器调度。

在步骤A中，利用网络实现与Kubernetes API-Server的通信，并实时监听Kubernetes API-Server中的容器创建事件。系统用户可以通过kubectl向KubernetesAPI-Server发送请求创建GPU容器，生成容器创建事件，创建前可以人为设置容器的镜像名称、容器调度优先级标签、容器启动命令、容器启动参数、容器使用的GPU标签等等，其中，GPU标签包括GPU数量标签、GPU显存标签、GPU时钟频率标签。Kubernetes API-Server可以根据容器创建事件实例化(创建)该容器对象并进行容器存储。当监测到新的容器创建事件后，需要获取该容器创建事件创建的容器对象的各个字段信息，根据字段信息对容器进行校验。

对创建的容器进行校验的具体操作如下：

步骤A01、根据创建的容器的字段信息进行GPU标签校验：判断容器是否包含GPU标签，当容器不包含任一GPU标签，则GPU标签校验失败，将校验失败时间和对应的错误信息(不包含GPU标签)写入Kubernetes事件日志，以便后续查找错误信息；当容不包含一个或多个GPU标签，GPU标签校验成功，可以进行后续操作。

步骤A02、当GPU标签校验成功，根据创建的容器的字段信息进行调度器名称校验：判断容器的调度器字段是否为系统调度器名称，当调度器字段不是系统调度器名称，则调度器名称校验失败，将校验失败时间和对应的错误信息(容器的调度器字段)写入Kubernetes事件日志；否则调度器名称校验成功，完成容器校验，容器校验成功。

在步骤B中会将校验成功的容器送入容器调度队列，并进行容器调度队列更新，如图2所示，具体操作如下：

步骤B01、将校验成功的容器从队尾送入容器调度队列中，生成当前时刻的容器调度队列。

步骤B02、获取当前时刻的容器调度队列中每个容器预设的优先级标签，根据优先级标签将容器调度队列中的所有容器从高到低排序，优先级高的容器放在容器调度队列的队头，优先级低的容器放在队尾，完成容器调度队列更新。

在本发明实施例中，步骤C的具体操作为：

步骤C01、实时监听容器调度队列是否为空，当容器调度队列不为空时，从容器调度队列的队头读取一个待调度容器，并获得该待调度容器的GPU标签。此外，本发明向Kubernetes API-Server发起请求获取当前Kubernetes集群中所有节点的GPU数据，包括：节点所持有的GPU数量，节点所持有的每张GPU的显存位宽、GPU时钟频率、GPU核心数、GPU显存总量、GPU可用显存总量、GPU功率等。

步骤C02、根据Kubernetes集群中每个节点的GPU数据和待调度容器的GPU标签进行节点选择和过滤，获得容器可调度节点.

步骤C03、当容器可调度节点数量为1，将该容器可调度节点作为最佳节点。

步骤C04、当容器可调度节点数量大于1，基于容器可调度节点的GPU数据计算每个容器可调度节点的得分，选取得分最高的容器可调度节点作为最佳节点。

步骤C05、利用待调度容器和最佳节点的节点名称组成容器调度二元组。

容器可调度节点是Kubernetes集群中满足待调度容器需求的节点，如图3所示，本发明主要从3个维度进行容器可调度节点的筛选：

步骤C021、根据GPU数量标签进行节点筛选：当待调度容器携带GPU数量标签时，遍历Kubernetes集群中的所有节点，当节点所持有的GPU数量大于等于GPU数量标签值，则将该节点标记为一次可调度节点；当待调度容器未携带GPU数量标签，将Kubernetes集群中的所有节点标记为一次可调度节点，并将该待调度容器的GPU数量标签值设置为1。

步骤C022、在C021的基础上根据GPU显存标签进行节点筛选：当待调度容器携带GPU显存标签，遍历所有一次可调度节点，当一次可调度节点中GPU空闲显存大于GPU显存标签值的GPU数量大于等于该待调度容器的GPU数量标签值(C021中未携带GPU数量标签的默认为1)时，将该一次可调度节点标记为二次可调度节点；当待调度容器未携带GPU显存标签，将所有一次可调度节点标记为二次可调度节点。

步骤C023、在C022的基础上根据GPU时钟频率标签进行节点筛选：当待调度容器携带GPU时钟频率标签，遍历所有二次可调度节点，当二次可调度节点中GPU时钟频率大于GPU时钟频率标签值的GPU数量大于等于该待调度容器的GPU数量标签值时，将该二次可调度节点标记为容器可调度节点；当待调度容器未携带GPU时钟频率标签，将所有二次可调度节点标记为容器可调度节点。

步骤C024、如果经历了3个维度的筛选后，容器可调度节点为空，则将当前时间和调度错误信息(容器可调度节点为空)写入Kubernetes事件日志。

在本发明实施例中，步骤C04中容器可调度节点的得分主要分为3个部分：1、满足待调度容器要求的GPU得分，待调度容器要求为待调度容器的GPU显存标签和GPU时钟频率标签；2、节点上所有GPU的显存得分；3、节点的配额得分。

满足待调度容器要求的GPU得分的计算公式如下：

FilteredGPUScore＝∑FilteredGPUScorePerCard (6)

其中，FilteredGPUScore表示容器可调度节点中满足待调度容器要求的所有GPU的GPU得分，FilteredGPUScorePerCard表示容器可调度节点中满足待调度容器要求的一个GPU的GPU分数。

FilteredGPUScorePerCard的计算公式如下：

其中，Bandwith表示GPU显存位宽，MaxBandwith表示容器可调度节点中满足待调度容器要求的所有GPU的GPU显存位宽最大值，Clock表示GPU时钟频率，MaxClock表示容器可调度节点中满足待调度容器要求的所有GPU的GPU时钟频率最大值，Power表示GPU功率，MaxPower表示容器可调度节点中满足待调度容器要求的所有GPU的GPU功率最大值，Core表示GPU核心数，MaxCore表示容器可调度节点中满足待调度容器要求的所有GPU的GPU核心数最大值，FreeMemory表示GPU空闲显存，MaxFreeMemory表示容器可调度节点中满足待调度容器要求的所有GPU的GPU空闲显存最大值，TotalMemory表示GPU显存总量，MaxTotalMemory表示容器可调度节点中满足待调度容器要求的所有GPU的GPU显存总量最大值。

节点上所有GPU的显存得分的计算公式如下：

其中，RealScore表示可调度节点中所有GPU的显存得分，FreeMemorySum表示容器可调度节点中所有GPU的GPU空闲显存之和，TotalMemorySum表示容器可调度节点中所有GPU的GPU显存总量之和。

节点的配额得分的计算公式如下：

其中，AllocateScore表示容器可调度节点的配额得分，AllocateMemorySum表示待调度容器申请的显存总量，即待调度容器的GPU显存标签值与GPU数量标签值的乘积。

根据公式(6)～(9)，容器可调度节点的得分Score的计算公式如下：

其中，FilteredGPUWeight为GPU得分的权重，FilteredGPUWeight的默认值为2，RealWeight为显存得分的权重，RealWeight的默认值为1，AllocateWeight为配额得分的权重，AllocateWeight的默认值为2。

在本发明实施例中，步骤D的具体操作为：根据容器调度二元组，将待调度容器的节点名称字段设置为二元组中最佳节点的节点名称，并异步更新Kubernetes API-Server中该容器的节点名称字段。

本发明还提出了一种基于共享式GPU的分布式容器调度系统，如图4所示，系统主要包括容器创建事件监听器1、容器调度队列2、容器调度器3、容器调度执行器4和通信模块5。本发明系统的工作原理如图5所示。

容器创建事件监听器主要用于监听Kubernetes API-Server中的容器创建事件，并在监测到新的容器创建事件之后进行容器校验，容器创建事件监听器还会将校验成功的容器送入容器调度队列；其工作过程和本发明方法的步骤A一致。容器调度队列主要用于按照优先级存放待调度的容器，其工作过程与本发明方法的步骤B一致。容器调度器主要用于从容器调度队列的队头读取待调度容器，并从Kubernetes集群中选出待调度容器对应的最佳节点，生成容器调度二元组，其工作过程与本发明方法的步骤C一致。容器调度执行器主要用于根据容器调度二元组更新Kubernetes API-Server中待调度容器的节点名称字段，完成容器调度操作，实现节点绑定，其工作过程与本发明方法的步骤D一致。

通信模块用于帮助容器创建事件监听器、容器调度队列、容器调度器、容器调度执行器与Kubernetes API-Server建立通信链接。通信模块获取系统配置文件，系统配置文件包括Kubernetes API-Server的IP地址、端口号、TLS公钥和TLS私钥。通信模块首先检查系统配置文件中是否存在IP地址和端口号，如果存在，通信模块读取IP地址和端口号，并根据IP地址和端口号尝试与Kubernetes集群通信，通信成功的情况下建立容器创建事件监听器、容器调度队列、容器调度器、容器调度执行器与Kubernetes API-Server的通信链路；通信模块再检查系统配置文件中是否存在TLS公钥和TLS私钥，如果存在，通过TLS公钥和TLS私钥尝试与Kubernetes API-Server通信，对通信链路进行认证，如果认证成功，则完成通信构建，容器创建事件监听器、容器调度队列、容器调度器、容器调度执行器可以和Kubernetes API-Server进行信息交互。如果系统配置文件不存在、IP地址不可达、端口关闭或者认证不成功，则将通信失败时间和失败原因记录并生成故障信息记录到本地，将故障信息以邮件形式发送给运维工程师，以便运维工程师检查、修复。

为了验证本发明的容器调度效果，本发明实施例给出了如下实验：

本发明实施例利用名为Node Simulator的调度仿真器模拟节点资源和Kubernetes中容器的状态，Node Simulator部署在Kubernetes控制平面所处的物理服务器上，其配置如表1所示：

表1

在本发明实施例中，容器均被设置为是机器学习任务，每个任务都需要Tensorflow、Pytorch等主流框架，所有容器均设置为在开始运行10秒钟后消耗GPU资源。实验选择Kubernetes调度器和Kubeshare作为比较的基准，所有实验重复20次计算平均值，以确保结果的有效性。通过Node Simulator生成10个Kubernetes节点，每个节点都配备4个NVIDIA TITAN-Xp GPU，具体配置参数如表2所示：

表2

实验1：

实验1选择负载平衡熵来衡量负载平衡的程度，负载平衡熵的定义为：

其中，E(U)表示负载平衡熵，N表示集群中的节点数，u

其中，n

从公式(11)、(12)可以看出，具有充分平衡的资源利用的集群的熵为1。

实验1中调度的容器的数量为225个，这些容器各自请求2000M GPU内存，并与Poisson分布请求到达一起形成调度队列，分别利用Kubernetes调度器、Kubeshare和本发明进行容器调度，并计算对应的负载平衡熵，结果如图6所示，图6中的横坐标表示调度的容器的数量，纵坐标表示集群的平均负载平衡熵。从图中可以看出，本发明的熵值最接近1，因此本发明的调度性能优于Kubernetes调度器。尽管Kubernetes调度器的调度策略包含LeastRequestedPriority和BalancedResourceAllocation策略，以避免在单个节点上消耗过多资源，但它在资源利用率方面仍处于较弱的平衡，这是因为Kubernetes的默认调度策略未能考虑到容器的实际GPU资源消耗。同样的，Kubeshare使用Most-fit调度策略和相似性标记机制以确保集群负载平衡的程度，但是，当容器开始消耗GPU资源时，调度决策就会发生偏移。结果表明，本发明可以更平衡地保证集群的资源利用率。

实验2：

考虑到当前的集群需要处理大型并发任务，任务调度时间被视为衡量调度程序性能必不可少的指标。在实验2中，调度的容器的数量为100个，所有要调度的容器各自请求500M GPU内存，并与Poisson分布请求到达一起形成调度队列，分别利用Kubernetes调度器、Kubeshare和本发明进行容器调度，并计算对应的调度时间，结果如图7所示，图中，横坐标表示要调度的容器的数量，纵坐标表示容器的调度时间，该时间是从调度事件的创建开始到绑定节点的完成结束。从图7可以看出，与Kubernetes和本发明相比，Kubeshare的性能相对较差，由于它考虑了GPU级别的亲和性，导致亲和性操作非常耗时。同时，尽管Kubernetes与本发明相比表现良好，但它们的调度策略缺乏对集群资源利用率的深入考虑，资源利用的平衡相对较弱，因此，Kubernetes默认调度器虽然可以做出快速的调度决策，却忽略了调度质量。

综上所述，本发明的容器调度时间优于其他基准方法，并且可以确保以更加平衡的方式确保集群GPU资源的消耗。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和变形，这些改进和变形也应视为本发明的保护范围。