CN111506404A - 一种基于Kubernetes的共享GPU调度方法 - Google Patents

Abstract

本发明公开了一种基于Kubernetes的共享GPU调度方法，所述共享GPU调度方法包括以下步骤：步骤1：GPU信息上报与统计；步骤2：共享GPU给多个Pod使用。该基于Kubernetes的共享GPU调度方法，与Kubernetes支持GPU独占调度相比增加了共享调度的能力，并且支持多种调度策略，满足不同场景下的GPU使用需求，本发明结合Kubernetes和GPU达到充分利用GPU资源、合理利用GPU资源的目的，Kubernetes可以是多个节点，每个节点可以有也可以没有显卡；使用Kubernetes的API创建资源并添加GPU显存资源请求；Kubernetes收到GPU显存资源申请发送请求给GPU调度插件，调度插件调度该Pod到有GPU显存配额足够的节点并标注GPU ID；最终多个Pod运行在一个GPU上，实现共享GPU。

Description

一种基于Kubernetes的共享GPU调度方法

技术领域

本发明涉及计算机技术及任务调度技术领域，具体为一种基于Kubernetes的共享GPU调度方法。

背景技术

现阶段人工智能、深度学***台，能够管理集群中的CPU、内存、网络等资源，并且支持插件试扩充资源，NVIDIA也编写了用于管理调度NVIDIA的插件使Kubernetes能够分配GPU资源，但是一个GPU只能分配给一个Pod，不能多个Pod同时使用进行共享。

针对这一问题，需要设计一个能够使多个Pod同时使用一个GPU的共享GPU调度方法。本发明设计了一种对GPU资源进行划分并分配部分给Pod的方法，多个Pod充分利用一个GPU的资源，提高资源利用率。

发明内容

本发明的目的在于解决GPU在Kubernetes使用时可以共享多个Pod的一种方法，来合理的分配GPU资源，提高利用率。

为实现上述目的，本发明提供如下技术方案：一种基于Kubernetes的共享GPU调度方法，所述共享GPU调度方法包括以下步骤：

步骤1：GPU信息上报与统计；

步骤2：共享GPU给多个Pod使用。

优选的，所述共享GPU调度方法中的GPU信息上报与统计包含以下步骤：

步骤1：所述每个节点的基于Kubernetes插件实现的GPU设备插件读取汇总，且GPU设备插件通过远程过程调用发送到API Server转发给GPU调度服务；

步骤2：所述用于接收GPU资源请求的GPU调度服务模块统计所有上报上来的显卡信息并记录到存储，且统计内容有节点-显卡映射关系，即以节点为索引对所有GPU信息进行汇总记录。

优选的，所述步骤1中提出的每个节点可以有一个或多个显卡，也可以没有显卡不进行上报，同时信息包含节点名、显卡名、显卡ID、显卡的显存大小。

优选的，所述GPU调度服务使用了API Server的扩展API功能，其中API Server是Kubernetes中的一个重要组件，且对于设备插件程序重启重新上报的GPU信息，GPU调度服务做合并处理。

优选的，所述共享GPU调度中提出的共享GPU给多个Pod使用包含以下步骤：

步骤1：GPU资源按照显存Megabyte单位进行划分，Pod可按单位向API Server申请部分的显存资源进行调度；

步骤2：GPU调度服务接收到API Server发送过来的GPU资源申请请求后与记录中的资源相匹配，在资源满足匹配时，调度服务对所有可以调度的节点进行打分，Pod会调度到得分最高的节点上，确定匹配到的节点和显卡ID并标记到Pod；

步骤3：调度服务将调度成功的消息转交给API Server，API Server与对应的节点通信创建Pod，设备插件读取标记信息有显卡ID后关联对应的显卡到Pod，此时Pod内的程序可使用GPU。

优选的，所述Pod向API Server发送创建资源请求，可能是Deployment或者Statefulset，其中有一个或多个新的Pod需要创建，当请求的资源包含GPU资源时，集群控制器会把调度的任务转交给GPU调度服务，由GPU调度服务进行筛选调度处理。

优选的，所述步骤2中提出的GPU调度服务的调度满足以下三种策略：

1、Binpack策略，该策略在有多个显卡的情况下会优先调度Pod到剩余GPU资源较少的显卡节点，在此显卡剩余资源不够的时候调度到新的显卡，保证显卡资源占用的紧凑，避免碎片化，保证在有新的大的GPU资源请求的时候有资源可用；

2、Spread策略，该策略在有多个显卡的情况下会平均分布Pod到多个显卡，若Pod数与显卡数相同则应该每个Pod分配到独立的一个显卡，充分利用显卡资源避免浪费；

3、Exclusive策略，该策略在调度Pod时只会选择没有被分配出去的显卡，保证该Pod能够独自使用此显卡，避免被其他Pod干扰，用于对显卡资源占用较高的情况。

与现有技术相比，本发明的有益效果是：该基于Kubernetes的共享GPU调度方法，与Kubernetes支持GPU独占调度相比增加了共享调度的能力，并且支持多种调度策略，满足不同场景下的GPU使用需求。本发明结合Kubernetes和GPU达到充分利用GPU资源、合理利用GPU资源的目的。

附图说明

附图是本发明的一部分，结合说明书用来进一步描述本发明的实施过程。

图1为本发明实施例提供的一种GPU信息统计上报流程图；

图2为本发明实施例提供的一种GPU资源共享调度整体流程图；

图3为本发明实施例提供的一种GPU调度***调度策略示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

请参阅说明书附图1-3，本发明提供一种技术方案：一种基于Kubernetes的共享GPU调度方法，所述共享GPU调度方法包括以下步骤：

步骤1：GPU信息上报与统计；

步骤2：共享GPU给多个Pod使用。

进一步的，所述共享GPU调度方法中的GPU信息上报与统计包含以下步骤：步骤1：所述每个节点的基于Kubernetes插件实现的GPU设备插件读取汇总，且GPU设备插件通过远程过程调用发送到API Server转发给GPU调度服务；步骤2：所述用于接收GPU资源请求的GPU调度服务模块统计所有上报上来的显卡信息并记录到存储，且统计内容有节点-显卡映射关系，即以节点为索引对所有GPU信息进行汇总记录。

进一步的，所述步骤1中提出的每个节点可以有一个或多个显卡，也可以没有显卡不进行上报，同时信息包含节点名、显卡名、显卡ID、显卡的显存大小，设备插件程序将该节点所有显卡的信息进行汇总，通过远程过程调用发送到API Server转发给GPU调度服务。

进一步的，所述GPU调度服务使用了API Server的扩展API功能，其中API Server是Kubernetes中的一个重要组件，且对于设备插件程序重启重新上报的GPU信息，GPU调度服务做合并处理，API Server用来接收其他模块的请求进行处理或者转发到对应的服务，APIserver的扩展API功能是Kubernetes 1.7版本引入的聚合机制，能够将用户扩展的API注册到kube-apiserver上，然后通过API Server的远程过程调用对新的API进行访问和操作。

此外，所述共享GPU调度中提出的共享GPU给多个Pod使用包含以下步骤：步骤1：GPU资源按照显存Megabyte单位进行划分，Pod可按单位向API Server申请部分的显存资源进行调度；步骤2：GPU调度服务接收到API Server发送过来的GPU资源申请请求后与记录中的资源相匹配，在资源满足匹配时，调度服务对所有可以调度的节点进行打分，Pod会调度到得分最高的节点上，确定匹配到的节点和显卡ID并标记到Pod；步骤3：调度服务将调度成功的消息转交给API Server，API Server与对应的节点通信创建Pod，设备插件读取标记信息有显卡ID后关联对应的显卡到Pod，此时Pod内的程序可使用GPU。

进一步的，所述Pod向API Server发送创建资源请求，可能是Deployment或者Statefulset，其中有一个或多个新的Pod需要创建，当请求的资源包含GPU资源时，集群控制器会把调度的任务转交给GPU调度服务，由GPU调度服务进行筛选调度处理。

GPU调度服务接收到API Server发送过来的调度请求，然后进行调度处理；Kubernetes自身包含一个调度服务模块，很多节点预选和优选的调度算法，但是只能用来调度CPU、内存、存储等默认的资源，用来调度扩展GPU资源时在遇到一个节点有多显卡的一些特殊场景下无法满足，所以需要定制调度才能满足复杂的GPU调度需求；GPU调度服务使用了Kubernetes的调度框架，因为在服务启动时向API Server注册GPU字段的调度关联，其中GPU字段是一种自定义的用来表示GPU资源的字符串，API Server在接收到调度器注册请求后对相应资源于该调度器进行绑定，当有该资源的请求时会将调度交由GPU调度器调度处理。

进一步的，所述步骤2中提出的GPU调度服务的调度满足以下三种策略：

1、Binpack策略，该策略在有多个显卡的情况下会优先调度Pod到剩余GPU资源较少的显卡节点，在此显卡剩余资源不够的时候调度到新的显卡，保证显卡资源占用的紧凑，避免碎片化，保证在有新的大的GPU资源请求的时候有资源可用；

2、Spread策略，该策略在有多个显卡的情况下会平均分布Pod到多个显卡，若Pod数与显卡数相同则应该每个Pod分配到独立的一个显卡，充分利用显卡资源避免浪费；

3、Exclusive策略，该策略在调度Pod时只会选择没有被分配出去的显卡，保证该Pod能够独自使用此显卡，避免被其他Pod干扰，用于对显卡资源占用较高的情况。

在调度阶段时，调度服务首先对不满足Pod的节点进行过滤，其中有些是Kubernetes默认的筛选策略：

检查节点Ready状态，如果为NotReady状态则该节点不能部署新容器，需要对其进行过滤；

当Pod开启了HostNetwork并且定义了端口，则调度器会对节点端口进行检查，查看端口是否已经被其他服务占用；

检查Pod对象是否有存储卷的资源请求，在此节点上是否可用，如果满足则通过检查；

检查Pod的tolerations属性，对应能否容忍节点的taints；

当Pod定义了节点选择标签，调度器会筛选满足该标签的节点，对不满足标签的节点进行剔除；

检查Pod的GPU资源和节点所有显卡剩余的GPU资源，如果节点没有GPU资源或者剩余GPU资源不足则不考虑。

在评分绑定节点阶段时，调度服务对所有可以调度的节点进行打分，Pod会调度到得分最高的节点上。下面主要描述GPU资源评分策略，对已有的默认打分策略不再描述：

在进行打分时调度服务首先会获取当前调度的策略类型；

如果当前为Binpack调度策略时，要寻找的是一个接近刚好能满足请求的GPU资源大小的显卡，剩余资源与请求资源相差越多则分数越低，打分计算方式：

10-(GPUCapacity–GPUAllocatad-GPURequested)/GPUCapacity*10策略打分首先需要针对显卡进行，在该节点有多个显卡时需要对所有显卡进行打分并且取其中最高分作为该节点评分；

为了上述打分策略中不出现大于10的评分，需要检查评分并对大于10评分的置0处理。

如果当前为Spread调度策略时，需要寻找的是剩余资源最多的一个节点，打分计算方式为：

(GPUCapacity–GPUAllocatad-GPURequested)/GPUCapacity*10

对节点有多显卡的情况同Binpack调度策略。

如果当前为Exclusive调度策略时，需要的是没有被其他Pod使用的显卡，并且显卡资源满足Pod请求，最好是刚好能够满足而不是剩余很多避免资源浪费，计算方式：

10-(GPUCapacity–GPURequested)/GPUCapacity*10

经过上述调度服务的调度之后，Pod已经与调度后的一个节点进行绑定，调度服务会对Pod进行注解，标识调度后的节点和显卡ID，之后通过远程调用接口给对应节点的kubelet进行部署

接下来会将部署请求发送给对应节点的kubelet进行处理，kubelet会检查资源请求发现有GPU请求时交由GPU设备插件分配GPU资源；

设备插件除了上报GPU信息外也会在启动时向当前节点的kubelet进行注册，注册后的设备插件即可接收kubelet发送的GPU请求进行分配处理，由于调度器已经对Pod注解了显卡ID，设备插件会将对应的显卡分配给该Pod进行使用；

设备插件处理后kubelet继续创建Pod，创建成功后Pod内的程序即可使用GPU进行机器学习、视频转码等工作。

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

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

功能如果以软件功能模块的形式实现并作为独立的产品销售或者使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或者部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是，在本文中，诸如第一以及第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或者操作区分开来，而不一定要求或者暗示这些实体或者操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改以及变化。凡在本申请的精神以及原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号以及字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义以及解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或者替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (7)

1.一种基于Kubernetes的共享GPU调度方法，其特征在于：所述共享GPU调度方法包括以下步骤：

步骤1：GPU信息上报与统计；

步骤2：共享GPU给多个Pod使用。

2.根据权利要求1所述的一种基于Kubernetes的共享GPU调度方法，其特征在于：所述共享GPU调度方法中的GPU信息上报与统计包含以下步骤：

步骤1：所述每个节点的基于Kubernetes插件实现的GPU设备插件读取汇总，且GPU设备插件通过远程过程调用发送到API Server转发给GPU调度服务；

步骤2：所述用于接收GPU资源请求的GPU调度服务模块统计所有上报上来的显卡信息并记录到存储，且统计内容有节点-显卡映射关系，即以节点为索引对所有GPU信息进行汇总记录。

3.根据权利要求2所述的一种基于Kubernetes的共享GPU调度方法，其特征在于：所述步骤1中提出的每个节点可以有一个或多个显卡，也可以没有显卡不进行上报，同时信息包含节点名、显卡名、显卡ID、显卡的显存大小。

4.根据权利要求2所述的一种基于Kubernetes的共享GPU调度方法，其特征在于：所述GPU调度服务使用了API Server的扩展API功能，其中API Server是Kubernetes中的一个重要组件，且对于设备插件程序重启重新上报的GPU信息，GPU调度服务做合并处理。

5.根据权利要求1所述的一种基于Kubernetes的共享GPU调度方法，其特征在于：所述共享GPU调度中提出的共享GPU给多个Pod使用包含以下步骤：

步骤1：GPU资源按照显存Megabyte单位进行划分，Pod可按单位向API Server申请部分的显存资源进行调度；

步骤2：GPU调度服务接收到API Server发送过来的GPU资源申请请求后与记录中的资源相匹配，在资源满足匹配时，调度服务对所有可以调度的节点进行打分，Pod会调度到得分最高的节点上，确定匹配到的节点和显卡ID并标记到Pod；

步骤3：调度服务将调度成功的消息转交给API Server，API Server与对应的节点通信创建Pod，设备插件读取标记信息有显卡ID后关联对应的显卡到Pod，此时Pod内的程序可使用GPU。

6.根据权利要求5所述的一种基于Kubernetes的共享GPU调度方法，其特征在于：所述Pod向API Server发送创建资源请求，可能是Deployment或者Statefulset，其中有一个或多个新的Pod需要创建，当请求的资源包含GPU资源时，集群控制器会把调度的任务转交给GPU调度服务，由GPU调度服务进行筛选调度处理。

7.根据权利要求5所述的一种基于Kubernetes的共享GPU调度方法，其特征在于：所述步骤2中提出的GPU调度服务的调度满足以下三种策略：

1、Binpack策略，该策略在有多个显卡的情况下会优先调度Pod到剩余GPU资源较少的显卡节点，在此显卡剩余资源不够的时候调度到新的显卡，保证显卡资源占用的紧凑，避免碎片化，保证在有新的大的GPU资源请求的时候有资源可用；

2、Spread策略，该策略在有多个显卡的情况下会平均分布Pod到多个显卡，若Pod数与显卡数相同则应该每个Pod分配到独立的一个显卡，充分利用显卡资源避免浪费；

3、Exclusive策略，该策略在调度Pod时只会选择没有被分配出去的显卡，保证该Pod能够独自使用此显卡，避免被其他Pod干扰，用于对显卡资源占用较高的情况。

Images