16. GPU管理和Device Plugin工作机制

朴灿烈づ我的快乐病毒、 2023-01-08 02:30 124阅读 0赞

> 本文由 CNCF + Alibaba 云原生技术公开课 整理而来

### 需求来源 ###

2016 年，随着 AlphaGo 的走红和 TensorFlow 项目的异军突起，一场名为 AI 的技术革命迅速从学术圈蔓延到了工业界，所谓 AI 革命从此拉开了帷幕。

经过三年的发展，AI 有了许许多多的落地场景，包括智能客服、人脸识别、机器翻译、以图搜图等功能。其实机器学习或者人工智能，并不是什么新鲜的概念，而这次热潮的背后，云计算的普及以及算力的巨大提升，才是真正将人工智能从象牙塔带到工业界的一个重要推手。

与之相对应的，从 2016 年开始，Kubernetes 社区就不断收到来自不同渠道的大量诉求，希望能在 Kubernetes 集群上运行 TensorFlow 等机器学习框架。这些诉求中，除了像 `Job` 这些离线任务的管理之外，还有一个巨大的挑战：深度学习所依赖的异构设备及英伟达的 GPU 支持。

Kubernetes 管理 GPU 能带来什么好处呢？本质上是成本和效率的考虑。由于相对 CPU 来说，GPU 的成本偏高。在云上单个 CPU 通常是一小时几毛钱，而 GPU 的花费则是从单个 GPU 每小时 10 元 ~ 30 元不等，这就要想方设法的提高 GPU 的使用率。

为什么要用 Kubernetes 管理以 GPU 为代表的异构资源？具体来说是 3 个方面：

加速部署：通过容器构想避免重复部署机器学习复杂环境
    
    提升集群资源使用率：统一调度和分配集群资源
    
    保障资源独享：利用容器隔离异构设备，避免互相影响

首先是加速部署，避免把时间浪费在环境准备的环节中。通过容器镜像技术，将整个部署过程进行固化和复用，现在许许多多的框架都提供了容器镜像，可以借此提升 GPU 的使用效率。

通过分时复用，来提升 GPU 的使用效率。当 GPU 的卡数达到一定数量后，就需要用到 Kubernetes 的统一调度能力，使得资源使用方能够做到用即申请、完即释放，从而盘活整个 GPU 的资源池。

而此时还需要通过 Docker 自带的设备隔离能力，避免不同应用的进程运行同一个设备上，造成互相影响。在高效低成本的同时，也保障了系统的稳定性。

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

### GPU 的容器化 ###

*  容器环境下使用 GPU 应用：

在容器环境下使用 GPU 应用，主要分为 2 步：

1. 构建支持 GPU 的容器镜像
    
    2. 利用 Docker 将该镜像运行起来，并把 GPU 设备和依赖库映射到容器中

*  准备 GPU 容器镜像：

有 2 个方法准备 GPU 容器镜像：

1. 直接使用官方深度学习容器镜像
    
    2. 基于 Nvidia 的 CUDA 镜像基础构建

可以直接从 docker.hub 或阿里云镜像服务中寻找官方的 GPU 镜像，包括像 TensorFlow、Caffe、PyTorch 等流行的机器学习框架，都有提供标准的镜像。这样的好处是简单便捷，而且安全可靠。

当然如果官方镜像无法满足需求时，比如对 TensorFlow 框架进行了定制修改，就需要重新编译构建自己的 TensorFlow 镜像。这种情况下的最佳实践是：依托于 Nvidia 官方镜像继续构建，而不要从头开始。

*  GPU 容器镜像原理：

要了解如何构建 GPU 容器镜像，首先要知道如何要在宿主机上安装 GPU 应用。要在宿主机上安装 GPU 应用，最底层是先安装 Nvidia 硬件驱动；再到上面是通用的 CUDA 工具库；最上层是 PyTorch、TensorFlow 这类的机器学习框架。上两层的 CUDA 工具库和应用的耦合度较高，应用版本变动后，对应的 CUDA 版本大概率也要更新；而最下层的 Nvidia 驱动，通常情况下是比较稳定的，它不会像 CUDA 和应用一样，经常更新。

同时 Nvidia 驱动需要内核源码编译，英伟达的 GPU 容器方案是：在宿主机上安装 Nvidia 驱动，而在 CUDA 以上的软件交给容器镜像来做。同时把 Nvidia 驱动里面的链接以 Mount Bind 的方式映射到容器中。这样的一个好处是：当安装了一个新的 Nvidia 驱动之后，就可以在同一个机器节点上运行不同版本的 CUDA 镜像了。

*  利用容器运行 GPU 程序：

通过上面可以知道，在运行时刻一个 GPU 容器和普通容器之间的差别，仅仅在于需要将宿主机的设备和 Nvidia 驱动库映射到容器中。

示例：

docker run -it \
        --volume=nvidia_driver_xxx_xx:/usr/local/nvidia:ro \
        --device=/dev/nvidiactl \
        --device=/dev/nvidia-uvm \
        --device=/dev/nvidia-uvm-tools \
        --device=/dev/nvidia0 \
        nvidia/cuda nvidia-smi

通常会使用 Nvidia-docker 来运行 GPU 容器，而 Nvidia-docker 的实际工作就是来自动化做这两个工作。其中挂载设备比较简单，而真正比较复杂的是 GPU 应用依赖的驱动库。对于深度学习，视频处理等不同场景，所使用的一些驱动库并不相同。这又需要依赖 Nvidia 的领域知识，而这些领域知识就被贯穿到了 Nvidia 的容器之中。

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

### Kubernetes 的 GPU 管理 ###

*  部署 GPU Kubernetes：

首先安装 Nvidia 驱动，

yum install -y gcc kernel-devel-$(uname -r)
    
    /bin/sh ./NVIDIA-Linux-x86_64*.run

安装 Nvidia Docker2，

yum install nvidia-docker2
    
    pkill -SIGNUP dockerd

从 Nvidia 的 git repo 下去下载 Device Plugin 的部署声明文件，并且通过 `kubectl create` 命令进行部署。这里 Device Plugin 是以 `Deamonset` 的方式进行部署的。

部署 Nvidia Device Plugin，

kubectl create -f nvidia-device-plugin.yml

*  在 Kubernetes 中使用 GPU：

站在用户的角度，在 Kubernetes 中使用 GPU 容器还是非常简单的。只需要在 `Pod` 资源配置的 `limits` 字段中指定 `nvidia.com/gpu` 使用 GPU 的数量，然后再通过 `kubectl create` 命令将 GPU 的 `Pod` 部署完成。

cuda-vector-add `Pod` yaml 文件示例：

apiVersion: v1
    kind: Pod
    metadata:
      name: cuda-vector-add
    spec:
      restartPolicy: OnFailure
      containers:
      - name: cuda-vector-add
        image: nvidia/cuda-vector-add:v0.1
        resources:
          limits:
            cpu: 250m
            memory: 512Mi
            nvidia.com/gpu: 1 #指定 GPU 数量

与普通容器不同的是，在 Kubernetes 中使用 GPU 容器只需要额外指定 `.spec.containers.resources.limits` 字段，声明 GPU 资源和对应的数量即可。

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

### 工作原理 ###

*  通过扩展的方式管理 GPU 资源：

Kubernetes 本身是通过插件扩展的机制来管理 GPU 资源的，有 2 个独立的内部机制：

1. Extend Resources，允许用户自定义资源名称。而该资源的度量是整数级别，目的在于通过一个通用的模式支持不同的异构设备，
       包括 RDMA、FPGA、AMD GPU 等等，而不仅仅是为 Nvidia GPU 设计的
     
    2. Device Plugin Framework，允许第三方设备提供商以外置的方式对设备进行全生命周期的管理，而 Device Plugin Framework 建立 Kubernetes 和 Device Plugin 模块之间的桥梁。
       它一方面负责设备信息的上报到 Kubernetes，另一方面负责设备的调度选择

*  Extended Resource 的上报：

Extend Resources 属于 Node-level 的 api，完全可以独立于 Device Plugin 使用。而上报 Extend Resources，只需要通过一个 `PACTH API` 对 `Node` 对象进行 `status` 部分更新即可，而这个 `PACTH` 操作可以通过一个简单的 curl 命令来完成。这样，在 Kubernetes 调度器中就能够记录这个节点的 GPU 类型，它所对应的资源数量是 1。

执行 `PACTH` 操作，

curl --header "Content-Type: application/json-patch+json" \
    --request PATCH \
    --data '[{"op": "add", "path": "/status/capacity/nvidia.com/gpu", "value": "1"}]' \
    https://localhost:6443/api/v1/nodes/<node-name>/status

查看对应资源数量，

kubectl describe node <node-name>

apiVersion: v1
    kind: Node
    ...
    Status:
      Capacity:
        nvidia.com/gpu: 1

如果使用的是 Device Plugin，就不需要做 `PACTH` 操作，只需要遵从 Device Plugin 的编程模型，在设备上报的工作中 Device Plugin 就会完成这个操作。

*  Device Plugin 工作机制：

整个 Device Plugin 的工作流程可以分成 2 个部分：

启动时刻的资源上报
    
    用户使用时刻的调度和运行

Device Plugin 的开发比较简单，主要包括最关注与最核心的 2 个事件方法：

1. ListAndWatch 对应资源的上报，同时还提供健康检查的机制。当设备不健康的时候，可以上报给 Kubernetes 不健康设备的 ID，让 Device Plugin Framework 将这个设备从可调度设备中移除
    
    2. 而 Allocate 会被 Device Plugin 在部署容器时调用，传入的参数核心就是容器会使用的设备 ID，返回的参数是容器启动时，需要的设备、数据卷以及环境变量

*  资源上报和监控：

对于每一个硬件设备，都需要它所对应的 Device Plugin 进行管理，这些 Device Plugin 以客户端的身份通过 GRPC 的方式对 `Kubelet` 中的 Device Plugin Manager 进行连接，并且将自己监听的 Unis socket api 的版本号和设备名称比如 GPU，上报给 `Kubelet`。

总的来说，整个过程分为四步，其中前三步都是发生在节点上，第四步是 `Kubelet` 和 `ApiServer` 的交互。

1. Device Plugin 的注册，需要 Kubernetes 知道要跟哪个 Device Plugin 进行交互。因为一个节点上可能有多个设备，需要 Device Plugin 以客户端的身份向 Kubelet 汇报 3 件事情：
    
        1. 我是谁？就是 Device Plugin 所管理的设备名称，是 GPU 还是 RDMA
    
        2. 我在哪？就是插件自身监听的 unis socket 所在的文件位置，让 Kubelet 能够调用自己
    
        3. 交互协议，即 API 的版本号
    
    2. 服务启动，Device Plugin 会启动一个 GRPC 的 server。在此之后 Device Plugin 一直以这个服务器的身份提供服务让 Kubelet 来访问，而监听地址和提供 API 的版本就已经在第一步完成了
    
    3. 当该 GRPC server 启动之后，Kubelet 会建立一个到 Device Plugin 的 ListAndWatch 的长连接， 用来发现设备 ID 以及设备的健康状态。当 Device Plugin 检测到某个设备不健康的时候，就会主动通知 Kubelet。
       而此时如果这个设备处于空闲状态，Kubelet 会将其移除可分配的列表。但是当这个设备已经被某个 Pod 所使用的时候，Kubelet 就不会做任何事情，如果此时杀掉这个 Pod 是一个很危险的操作
    
    4. Kubelet 会将这些设备暴露到 Node 节点的状态中，把设备数量发送到 Kubernetes 的 ApiServer 中。后续调度器可以根据这些信息进行调度

需要注意的是 `Kubelet` 在向 `ApiServer` 进行汇报的时候，只会汇报该 GPU 对应的数量。而 Kubelet 自身的 Device Plugin Manager 会对这个 GPU 的 ID 列表进行保存，并用来具体的设备分配。而这个对于 Kubernetes 全局调度器来说，它不掌握这个 GPU 的 ID 列表，它只知道 GPU 的数量。

这就意味着在现有的 Device Plugin 工作机制下，Kubernetes 的全局调度器无法进行更复杂的调度。比如说想做两个 GPU 的亲和性调度，同一个节点两个 GPU 可能需要进行通过 NVLINK 通讯而不是 PCIe 通讯，才能达到更好的数据传输效果。在这种需求下，目前的 Device Plugin 调度机制中是无法实现的。

*  `Pod` 的调度和运行的过程：

`Pod` 想使用一个 GPU 的时候，只需要在 `Pod` 的 `resources` 下 `limits` 字段中声明 GPU 资源和对应的数量（比如 `nvidia.com/gpu: 1`）。Kubernetes 会找到满足数量条件的节点，然后将该节点的 GPU 数量减 1，并且完成 `Pod` 与 `Node` 的绑定。

绑定成功后，自然就会被对应节点的 `Kubelet` 拿来创建容器。而当 `Kubelet` 发现这个 `Pod` 的容器请求的资源是一个 GPU 的时候，`Kubelet` 就会委托自己内部的 Device Plugin Manager 模块，从自己持有的 GPU 的 ID 列表中选择一个可用的 GPU 分配给该容器。此时 `Kubelet` 就会向本机的 DeAvice Plugin 发起一个 Allocate 请求，这个请求所携带的参数，正是即将分配给该容器的设备 ID 列表。

Device Plugin 收到 AllocateRequest 请求之后，它就会根据 `Kubelet` 传过来的设备 ID，去寻找这个设备 ID 对应的设备路径、驱动目录以及环境变量，并且以 AllocateResponse 的形式返还给 `Kubelet`。

AllocateResponse 中所携带的设备路径和驱动目录信息，一旦返回给 `Kubelet` 之后，`Kubelet` 就会根据这些信息执行为容器分配 GPU 的操作，这样 `Docker` 会根据 `Kubelet` 的指令去创建容器，而这个容器中就会出现 GPU 设备，并且把它所需要的驱动目录给挂载进来。

至此 Kubernetes 为 `Pod` 分配一个 GPU 的流程就结束了。

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