Kubernetes的共享GPU集群调度

男娘i 2022-03-07 00:54 870阅读 0赞

#### 问题背景 ####

全球主要的容器集群服务厂商的Kubernetes服务都提供了Nvidia GPU容器调度能力，但是通常都是将一个GPU卡分配给一个容器。这可以实现比较好的隔离性，确保使用GPU的应用不会被其他应用影响；对于深度学习模型训练的场景非常适合，但是如果对于模型开发和模型预测的场景就会比较浪费。 大家的诉求是能够让更多的预测服务共享同一个GPU卡上，进而提高集群中Nvidia GPU的利用率。而这就需要提供GPU资源的划分，而这里GPU资源划分的维度指的就是GPU显存和Cuda Kernel线程的划分。通常在集群级别谈支持共享GPU，通常是两件事情：

1.调度   
2.隔离，我们这里主要讨论的是调度，隔离的方案未来会基于Nvidia的MPS来实现。

而对于细粒度的GPU卡调度，目前Kubernetes社区并没有很好的方案，这是由于Kubernetes对于GPU这类扩展资源的定义仅仅支持整数粒度的加加减减，无法支持复杂资源的分配。比如用户希望使用Pod A占用半张GPU卡，这在目前Kubernetes的架构设计中无法实现资源分配的记录和调用。这里挑战是多卡GPU共享是实际矢量资源问题，而Extened Resource是标量资源的描述。

针对此问题，我们设计了一个outoftree的共享GPU调度方案，该方案依赖于Kubernetes的现有工作机制:

*  Extended Resource定义
 *  Scheduler Extender机制
 *  Device Plugin机制

#### 用户场景 ####

*  作为集群管理员，我想提高集群的GPU使用率;在开发过程中，多个用户共享模型开发环境
 *  作为应用开发人员，我希望能够同时在Volta GPU上运行多个推理任务

#### 目标 ####

*  能够让使用者通过API描述对于一个可共享资源的申请， 并能实现该种资源的调度

#### 非目标 ####

*  不支持该共享资源的隔离
 *  不支持超卖

#### 设计原则 ####

1.  明确问题简化设计，第一步只负责调度和部署，后续再实现运行时显存管控。  
    有很多的客户明确的诉求是首先可以支持多AI应用可以调度到同一个GPU上，他们可以接受从应用级别控制显存的大小，利用类似`gpu_options.per_process_gpu_memory_fraction`控制应用的显存使用量。那我们要解决的问题就先简化到以显存为调度标尺，并且把显存使用的大小以参数的方式传递给容器内部。
2.  不做侵入式修改  
    本设计中不会修改Kubernetes核心的Extended Resource的设计， Scheduler的实现，Device Plugin的机制以及Kubelet的相关设计。重用Extended Resource描述共享资源的申请API。这样的好处在于提供一个可以移植的方案，用户可以在原生Kubernetes上使用这个方案。
3.  按显存和按卡调度的方式可以在集群内并存，但是同一个节点内是互斥的，不支持二者并存；要么是按卡数目，要么是按显存分配。

#### 详细设计 ####

**前提：**

1.  依旧延用Kubernetes Extended Resource定义，但是衡量维度最小单位从1个GPU卡变为GPU显存的MiB。如果所节点使用的GPU为单卡16GiB显存，它对应的资源就是16276MiB
2.  由于用户对于共享GPU的诉求在于模型开发和模型预测场景，在此场景下，用户申请的GPU资源上限不会超过一张卡，也就是申请的资源上限为单卡

而我们的工作首先是定义了两个新的Extended Resource： 第一个是gpu-mem， 对应的是GPU显存;第二个是gpu-count，对应的是GPU卡数。 通过两个标量资源描述矢量资源, 并且结合这一资源，提供支持共享GPU的工作机制。下面是基本的架构图：

![1240][]

**核心功能模块:**

*  **GPU Share Scheduler Extender**: 利用Kubernetes的调度器扩展机制，负责在全局调度器Filter和Bind的时候判断节点上单个GPU卡是否能够提供足够的GPU Mem，并且在Bind的时刻将GPU的分配结果通过annotation记录到Pod Spec以供后续Filter检查分配结果。
 *  **GPU Share Device Plugin**: 利用Device Plugin机制，在节点上被Kubelet调用负责GPU卡的分配，依赖scheduler Extender分配结果执行。

**具体流程:**

**1. 资源上报**

GPU Share Device Plugin利用nvml库查询到GPU卡的数量和每张GPU卡的显存， 通过`ListAndWatch()`将节点的GPU总显存（数量 *显存）作为另外Extended Resource汇报给Kubelet； Kubelet进一步汇报给Kubernetes API Server。 举例说明，如果节点含有两块GPU卡，并且每块卡包含16276MiB，从用户的角度来看：该节点的GPU资源为16276 *2 = 32552; 同时也会将节点上的GPU卡数量2作为另外一个Extended Resource上报。

**2. 扩展调度**

GPU Share Scheduler Extender可以在分配gpu-mem给Pod的同时将分配信息以annotation的形式保留在Pod spec中，并且在过滤时刻根据此信息判断每张卡是否包含足够可用的gpu-mem分配。

**2.1** Kubernetes默认调度器在进行完所有过滤(filter)行为后会通过http方式调用GPU Share Scheduler Extender的filter方法, 这是由于默认调度器计算Extended Resource时，只能判断资源总量是否有满足需求的空闲资源，无法具体判断单张卡上是否满足需求；所以就需要由GPU Share Scheduler Extender检查单张卡上是否含有可用资源。

以下图为例， 在由3个包含两块GPU卡的节点组成的Kubernetes集群中，当用户申请`gpu-mem=8138`时，默认调度器会扫描所有节点，发现N1所剩的资源为 (16276 \* 2 - 16276 -12207 = 4069 )不满足资源需求，N1节点被过滤掉。   
而N2和N3节点所剩资源都为8138MiB，从整体调度的角度看，都符合默认调度器的条件；此时默认调度器会委托GPU Share Scheduler Extender进行二次过滤，在二次过滤中，GPU Share Scheduler Extender需要判断单张卡是否满足调度需求，在查看N2节点时发现该节点虽然有8138MiB可用资源，但是落到每张卡上看，GPU0和分别GPU1只有4069MiB的可用资源，无法满足单卡8138MiB的诉求。而N3节点虽然也是总共有8138MiB可用资源，但是这些可用资源都属于GPU0，满足单卡可调度的需求。由此，通过GPU Share Scheduler Extender的筛选就可以实现精准的条件筛选。

![1240 1][]

**2.2** 当调度器找到满足条件的节点，就会委托GPU Share Scheduler Extender的bind方法进行节点和Pod的绑定，这里Extender需要做的是两件事情

*  以binpack的规则找到节点中最优选择的GPU卡id，此处的最优含义是对于同一个节点不同的GPU卡，以binpack的原则作为判断条件，优先选择空闲资源满足条件但同时又是所剩资源最少的GPU卡，并且将其作为`ALIYUN_COM_GPU_MEM_IDX`保存到Pod的annotation中；同时也保存该Pod申请的GPU Memory作为`ALIYUN_COM_GPU_MEM_POD`和`ALIYUN_COM_GPU_MEM_ASSUME_TIME`保存至Pod的annotation中，并且在此时进行Pod和所选节点的绑定。

> 注意：这时还会保存 `ALIYUN_COM_GPU_MEM_ASSIGNED`的Pod annotation，它被初始化为“false”。它表示该Pod在调度时刻被指定到了某块GPU卡，但是并没有真正在节点上创建该Pod。 `ALIYUN_COM_GPU_MEM_ASSUME_TIME`代表了 `指定`时间。

如果此时发现分配节点上没有GPU资源符合条件，此时不进行绑定，直接不报错退出，默认调度器会在assume超时后重新调度。

*  调用Kubernetes API执行节点和Pod的绑定

以下图为例，当GPU Share Scheduler Extender要把gpu-mem：8138的Pod和经过筛选出来的节点N1绑定，首先会比较不同GPU的可用资源，分别为GPU0(12207),GPU1(8138),GPU2(4069),GPU3(16276),其中GPU2所剩资源不满足需求，被舍弃掉；而另外三个满足条件的GPU中, GPU1恰恰是符合空闲资源满足条件但同时又是所剩资源最少的GPU卡，因此GPU1被选出。

![1240 2][]

**3. 节点上运行**

当Pod和节点绑定的事件被Kubelet接收到后，Kubelet就会在节点上创建真正的Pod实体，在这个过程中, Kubelet会调用GPU Share Device Plugin的`Allocate`方法, `Allocate`方法的参数是Pod申请的gpu-mem。而在`Allocate`方法中，会根据GPU Share Scheduler Extender的调度决策运行对应的Pod

**3.1** 会列出该节点中所有状态为Pending并且`ALIYUN_COM_GPU_MEM_ASSIGNED`为`false`的GPU Share Pod

**3.2** 选择出其中Pod Annotation的`ALIYUN_COM_GPU_MEM_POD`的数量与Allocate申请数量一致的Pod。如果有多个符合这种条件的Pod，就会选择其中`ALIYUN_COM_GPU_MEM_ASSUME_TIME`最早的Pod。

**3.3** 将该Pod的annotation `ALIYUN_COM_GPU_MEM_ASSIGNED`设置为`true`，并且将Pod annotation中的GPU信息转化为环境变量返回给Kubelet用以真正的创建Pod。

![1240 3][]

#### 相关项目 ####

目前项目已经开源到github.com上

[gpushare-scheduler-extender][]

[gpushare-device-plugin][]

#### 部署 ####

请参照[部署文档][Link 1]

#### 测试样例 ####

1. 首先创建一个使用`aliyun.com/gpu-mem`的应用

apiVersion: apps/v1
    kind: Deployment
    
    metadata:
      name: binpack-1
      labels:
        app: binpack-1
    
    spec:
      replicas: 1
    
      selector: # define how the deployment finds the pods it manages
        matchLabels:
          app: binpack-1
    
      template: # define the pods specifications
        metadata:
          labels:
            app: binpack-1
    
        spec:
          containers:
          - name: binpack-1
            image: cheyang/gpu-player:v2
            resources:
              limits:
                # MiB
                aliyun.com/gpu-mem: 1024

#### 使用 ####

请参照[使用文档][Link 2]

#### 构建 ####

请参照[如何构建][Link 3]

#### 视频Demo ####

**Demo 1:** 部署多个GPU Share的Pod，发现他们以binpack的方式被放置到同一个GPU卡上

**视频地址：**[http://cloud.video.taobao.com...][http_cloud.video.taobao.com...]

**Demo 2:**避免错误调度申请资源超过单个GPU可用资源的Pod

**视频地址：**[http://cloud.video.taobao.com...][http_cloud.video.taobao.com... 1]

#### Roadmap ####

*  利用nvidia MPS实现隔离
 *  支持该方案可以在由kubeadm初始化的Kubernetes集群自动化部署
 *  Scheduler Extener的高可用性
 *  为GPU, RDMA 和弹性网卡提供通用方案

--------------------

本文作者：必嘫

[阅读原文][Link 4]

本文为云栖社区原创内容，未经允许不得转载。

[1240]: /images/20220307/bb63a35944d54aa686b328e5d0dbe207.png
[1240 1]: /images/20220307/fcf8c48dc7a643c9aa0a4b70a99f6cc2.png
[1240 2]: /images/20220307/11b04dd16dcc49b98a9009c908b87a87.png
[1240 3]: /images/20220307/f8b53a4b0cdd4d979279b81d9783b38a.png
[gpushare-scheduler-extender]: https://github.com/AliyunContainerService/gpushare-scheduler-extender.git
[gpushare-device-plugin]: https://github.com/AliyunContainerService/gpushare-device-plugin.git
[Link 1]: https://github.com/AliyunContainerService/gpushare-scheduler-extender/blob/master/docs/install.md
[Link 2]: https://github.com/AliyunContainerService/gpushare-scheduler-extender/blob/master/docs/userguide.md
[Link 3]: https://github.com/AliyunContainerService/gpushare-scheduler-extender#developing
[http_cloud.video.taobao.com...]: http://cloud.video.taobao.com//play/u/2987821887/p/2/e/6/t/1/214292079721.mp4
[http_cloud.video.taobao.com... 1]: http://cloud.video.taobao.com//play/u/2987821887/p/2/e/6/t/1/214235285109.mp4
[Link 4]: https://yq.aliyun.com/articles/690623?utm_content=g_1000041607