GPU Mounter - 支持 GPU 热挂载的 Kubernetes 插件

米开朗基杨

发布于 2021-03-16 10:23:32

1.3K0

发布于 2021-03-16 10:23:32

文章被收录于专栏：云原生实验室云原生实验室

前言

GPU Mounter 是一个支持动态调整运行中 Pod 可用 GPU 资源的 Kubernetes 插件，已经开源在 GitHub[1]：

支持 Pod 可用 GPU 资源的动态调整
兼容 Kubernetes 调度器
无侵入式修改
REST API 接口
一键部署

下面聊一聊我对 GPU 容器化和 GPU 挂载的认识，以及为什么需要 GPU 热挂载。

1. GPU 容器化与 GPU 挂载

GPU 挂载很好理解，即为容器或 Pod 挂载 GPU 资源，允许容器中的应用程序使用。在容器化的趋势席卷各个领域的今天，深度学习也同样无法 “幸免”。各大云服务提供商，推出了自己的深度学习云平台（如国内阿里 PAI、腾讯 TI-ONE、百度 BML，国外 AWS Sagemaker 等），深度学习领域的研究者，也开始倾向于在本地采用 Docker 容器的方式构建深度学习训练环境。截止到目前 DockerHub 上 tensorflow 镜像被超过 10M 次，pytorch 镜像被拉取超过 1M 次，可见容器化的影响。

谈到深度学习的容器化，GPU 挂载是一个绕不开的话题，为此 Docker、Kubernetes、Nvidia 都做出了很多贡献：

Nvidia 贡献了 nvidia-docker、nvidia-container-runtime、k8s-deivice-plugin 等，支持在 Docker 和 Kubernetes 环境下使用 Nvidia GPU 资源
Docker 从 19.03 版本开始原生支持--gpus参数对接 nvidia-container-runtime
Kubernetes 从 1.8 版本开始提供 Device Plugin 接口，解耦源代码中对 Nvidia GPU 的原生支持

因为有了上述工作，我们在 Docker 或 Kubernetes 环境中想要使用 GPU，只需一个--gpus参数或者一个nvidia.com/gpu资源字段即可完成 GPU 资源的挂载。

2. 当前 GPU 挂载方案的不足

当前的 GPU 容器化的方案仍然存在一点不足，无法动态调整一个已经正在运行的容器或 Pod 可用的 GPU 资源。即我们必须在启动容器时就一次设定好容器可用的 GPU 资源，如果容器已经启动而我们又想要调整其 GPU 资源，只能先关掉这个容器，重新设定后再启动。

也许正处于这一限制，当前各大深度学习云平台均无法支持调整一个运行中实例的 GPU 资源的特性。

关于 Docker 和 Kubernetes 为什么没有解决这一问题，我的理解是容器或 Pod 通常被认为应该是无状态的（Stateless），应该维持其不变性（Immutability），即容器启动后就不应该更改其配置，如果有需要，应该基于一个满足要求的镜像重新开启新的容器。从容器的通用应用场景来看，这种观点是没有问题的，但是在深度学习平台场景下，这一点我认为值得商榷，深度学习应用的依赖通常比较复杂，难以构建标准统一的 “万能” 镜像即插即用。而出于安全的原因，平台一般只允许用户使用平台提供的通用镜像，因此用户不得不破坏不变性，在运行中的容器里安装各种复杂依赖，因此深度学习平台的容器应该被认为是有状态的。

3. 什么是 / 为什么需要 GPU 热挂载？

GPU 热挂载即调整一个运行中容器的 GPU 资源，能够增加或删除一个运行中的容器可用的 GPU 资源而无需暂停或重启容器。

GPU 热挂载这个场景在深度学习云平台上其实很常见，我们来考虑下用户使用深度学习云平台的基本流程。

用户启动一个实例后实际上还需要基于平台提供的基础镜像环境再去下载导入数据集和安装其他复杂的依赖库，这一过程数据集规模较大或代码依赖在较为复杂时可能需要耗费较长时间，然而由于无法在环境准备完成后再挂载 GPU 资源，用户不得不在一开始启动实例时就申请所需 GPU 资源。在上述准备环境的过程中 GPU 实际上处于闲置状态，对用户来说需要承受昂贵的 GPU 费用，对平台而言降低了整个平台的资源利用率。