【博客501】Nvidia docker runtime原理
docker 本身并不原生支持GPU,但使用docker的现有功能可以对GPU的使用进行支持。如上所述,通过 --device 来指定挂载的GPU设备,通过 -v 来将宿主机上的 nvidia gpu 的命令行工具和相关的依赖库挂载到容器。这样,在容器中就可以看到和使用宿主机上的GPU设备了。这样使用,对于GPU的可用性(哪些GPU是空闲的等)需要人为的判断,效率很低。
Nvidia docker runtime原理
场景:
docker 本身并不原生支持GPU,但使用docker的现有功能可以对GPU的使用进行支持。
docker run \
--device /dev/nvidia0:/dev/nvidia0 \
--device /dev/nvidiactl:/dev/nvidiactl \
--device /dev/nvidia-uvm:/dev/nvidia-uvm \
-v /usr/local/nvidia:/usr/local/nvidia \
-it --privileged nvidia/cuda
如上所述,通过 --device 来指定挂载的GPU设备,通过 -v 来将宿主机上的 nvidia gpu 的命令行工具和相关的依赖库挂载到容器。这样,在容器中就可以看到和使用宿主机上的GPU设备了。 这样使用,对于GPU的可用性(哪些GPU是空闲的等)需要人为的判断,效率很低。为了提高Nvidia GPU在 docker 中的易用性, Nvidia 通过对原生docker的封装实现了自己的 nvidia-docker 工具。
nvidia-docker 对于使用GPU资源的docker容器支持的层次关系:
Nvidia-docker的原理图以及各个部分的作用解析
libnvidia-container:
libnvidia-container提供了一个库和简单的CLI工具,以实现在容器当中支持使用GPU设备的目标。
nvidia-container-toolkit:
nvidia-container-toolkit是一个实现了runC prestart hook接口的脚本,该脚本在runC创建一个容器之后,启动该容器之前调用,其主要作用就是修改与容器相关联的config.json,注入一些在容器中使用NVIDIA GPU设备所需要的一些信息(比如:需要挂载哪些GPU设备到容器当中)。
nvidia-container-runtime:
nvidia-container-runtime主要用于将容器runC spec作为输入,然后将nvidia-container-toolkit脚本作为一个prestart hook注入到runC spec中,将修改后的runC spec交给runC处理。
nvidia-container-runtime 才是真正的核心部分,它在原有的docker容器运行时runc的基础上增加一个prestart hook,用于调用libnvidia-container库。
RunC:
RunC 是一个轻量级的工具,它是用来运行容器的,只用来做这一件事,并且这一件事要做好。我们可以认为它就是个命令行小工具,可以不用通过 docker 引擎,直接运行容器。事实上,runC 是标准化的产物,它根据 OCI 标准来创建和运行容器。而 OCI(Open Container Initiative)组织,旨在围绕容器格式和运行时制定一个开放的工业化标准。
直接使用RunC的命令行即可以完成创建一个容器,并提供了简单的交互能力。
容器创建
正常创建一个容器的流程是这样的:
docker --> dockerd --> containerd–> containerd-shim -->runc --> container-process
docker客户端将创建容器的请求发送给dockerd, 当dockerd收到请求任务之后将请求发送给containerd, containerd经过查看校验启动containerd-shim或者自己来启动容器进程。
创建一个使用GPU的容器
docker–> dockerd --> containerd --> containerd-shim–> nvidia-container-runtime --> nvidia-container-runtime-hook --> libnvidia-container --> runc – > container-process
基本流程和不使用GPU的容器差不多,只是把docker默认的运行时替换成了NVIDIA自家的nvidia-container-runtime。
这样当nvidia-container-runtime创建容器时,先执行nvidia-container-runtime-hook这个hook去检查容器是否需要使用GPU(通过环境变NVIDIA_VISIBLE_DEVICES来判断)。如果需要则调用libnvidia-container来暴露GPU给容器使用。否则走默认的runc逻辑。
NVIDIA Docker 整体工作架构
1、硬件,服务器上安装了英伟达 GPU
2、宿主机,安装了操作系统和 Cuda Driver,以及 Docker 引擎
3、容器,包含容器 OS 用户空间,Cuda Toolkit,以及用户应用程序
最重要的是,宿主机上需要安装 cuda driver,容器内需要安装 cuda toolkit。容器内无需安装 cuda driver。
NVIDIA 提供了一些官方镜像,其中已经安装好了 cuda toolkit,但还是需要在宿主机安装 cuda driver。
CUDA 结构图如下:
提供了 cuda driver api,cuda runtime api 和 cuda liabaries 三层 API
CUDA Driver API:
GPU设备的抽象层,通过提供一系列接口来操作GPU设备,性能最好,但编程难度高,
一般不会使用该方式开发应用程序。
CUDA Runtime API:
对CUDA Driver API进行了一定的封装,调用该类API可简化编程过程,降低开发难度;
CUDA Libraries:
是对CUDA Runtime API更高一层的封装,通常是一些成熟的高效函数库,
开发者也可以自己封装一些函数库便于使用;
CUDA调用关系:
应用程序可调用CUDA Libraries或者CUDA Runtime API来实现功能,当调用CUDA Libraries时,CUDA Libraries会调用相应的CUDA Runtime API,CUDA Runtime API再调用CUDA Driver API,CUDA Driver API再操作GPU设备。
如何实现CUDA容器化:
目标:CUDA容器化的目标就是要能让应用程序可以在容器内调用CUDA API来操作GPU。
因此需要实现:
1、在容器内应用程序可调用CUDA Runtime API和CUDA Libraries
2、在容器内能使用CUDA Driver相关库。因为CUDA Runtime API其实就是CUDA Driver API的封装,底层还是要调用到CUDA Driver API
3、在容器内可操作GPU设备
因此容器中访问 GPU 资源过程为:
要在容器内操作GPU设备,需要将GPU设备挂载到容器里,Docker可通过 --device 挂载需要操作的设备,或者直接使用特权模式(不推荐)。NVIDIA Docker是通过注入一个 prestart 的hook 到容器中,在容器自定义命令启动前就将GPU设备挂载到容器中。至于要挂载哪些GPU,可通过 NVIDIA_VISIBLE_DEVICES 环境变量控制。
挂载GPU设备到容器后,还要在容器内可调用CUDA API。CUDA Runtime API和CUDA Libraries通常跟应用程序一起打包到镜像里,而CUDA Driver API是在宿主机里,需要将其挂载到容器里才能被使用。NVIDIA Docker挂载CUDA Driver库文件到容器的方式和挂载GPU设备一样,都是在runtime hook里实现的。
注意:
该方案也有一些问题,即容器内的 cuda toolkit 同宿主机的 cuda driver 可能存在版本不兼容的问题。
NVIDIA Docker CUDA容器化分析:
这里主要分析下NVIDIA Docker 2.0的实现
修改Docker daemon 的启动参数,将默认的 Runtime修改为 nvidia-container-runtime后,可实现将GPU设备,CUDA Driver库挂载到容器中。
cat /etc/docker/daemon.json
{
"default-runtime": "nvidia",
"runtimes": {
"nvidia": {
"path": "/usr/bin/nvidia-container-runtime",
"runtimeArgs": []
}
}
}
nvidia-container-runtime实现如下:
nvidia-container-runtime其实就是在runc基础上多实现了nvidia-container-runime-hook,该hook是在容器启动后(Namespace已创建完成),容器自定义命令(Entrypoint)启动前执行。当检测到NVIDIA_VISIBLE_DEVICES环境变量时,会调用libnvidia-container挂载GPU Device和CUDA Driver。如果没有检测到NVIDIA_VISIBLE_DEVICES就会执行默认的runc。
NVIDIA Container Toolkit
如上图所示, NVIDIA 将原来 CUDA 应用依赖的API环境划分为两个部分:
1、驱动级API:由libcuda.so.major.minor动态库和内核module提供支持,图中表示为CUDA Driver
驱动级API属于底层API,每当NVIDIA公司释放出某一个版本的驱动时,如果你要升级主机上的驱动,那么内核模块和libcuda.so.major.minor这2个文件就必须同时升级到同一个版本,这样原有的程序才能正常工作,
不同版本的驱动不能同时存在于宿主机上
2、非驱动级API:由动态库libcublas.so等用户空间级别的API组成,图中表示为CUDA Toolkit
非驱动级API的版本号是以Toolkit自身的版本号来管理, 比如cuda-10,cuda-11
不同版本的Toolkit可以同时运行在相同的宿主机上
非驱动级API算是对驱动级API的一种更高级的封装,最终还是要调用驱动级API来实现功能
为了让使用GPU的容器更具可扩展性,关于非驱动级的API被 NVIDIA 打包进了 NVIDIA Container Toolkit,因此在容器中使用GPU之前,每个机器需要先安装好NVIDIA驱动,之后配置好 NVIDIA Container Toolkit之后,就可以在容器中方便使用GPU了。
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)