使用 Elastic GPU 管理 Kubernetes GPU 资源

作者

徐蓓，腾讯云容器技术专家，腾讯云异构计算容器负责人，多年云计算一线架构设计与研发经验，长期深耕 Kubernetes、在离线混部与 GPU 容器化领域，Kubernetes KEP Memory QoS 作者，Kubernetes 积极贡献者。

当前存在问题

GPU 具备大量核心和高速内存，擅长并行计算，非常适合训练和运行机器学习模型。由于近几年 AI 技术愈发成熟，落地场景越来越多，对 GPU 的需求呈井喷趋势。而在资源管理调度平台上，Kubernetes 已成为事实标准。所以很多客户选择在 Kubernetes 中使用 GPU 运行 AI 计算任务。

Kubernetes 提供 device plugin 机制，可以让节点发现和上报设备资源，供 Pod 使用。GPU 资源也是通过该方式提供。以 nvidia GPU 为例，用户在 Kubernetes 节点部署 nvidia-device-plugin，插件扫描节点 GPU 卡，会以 extended resource 机制将 GPU 资源以类似nvidia.com/gpu: 8的形式注册到节点中。用户创建 Pod 时指定该资源名，经过调度器调度后，Pod 绑定到节点，最终通过 nvidia docker 提供的一系列工具，将所需 GPU 设备挂载到容器里。

Kubernetes device plugin 提供了一种便捷的方式用于集成第三方设备。但应用在 GPU 场景，还是存在以下不足：

• 集群 GPU 资源缺少全局视角。没有直观方式可获取集群层面 GPU 信息，比如 Pod / 容器与 GPU 卡绑定关系、已使用 GPU 卡数 等

• 不能很好支持多 GPU 后端。各种 GPU 技术（nvidia docker、qGPU、vCUDA、gpu share、GPU 池化）均需独立部署组件，无法统一调度和管理

问题一：缺少 GPU 资源全局视角

现有 Kubernetes 对 GPU 资源的分配调度是通过 extended resource 实现的，它是基于节点上卡数量的加减调度。用户如果想知道集群中 GPU 卡的分配情况，需要遍历节点，拿到并计算这些信息。并且由于这个资源是标量的，所以并无法拿到 Pod / 容器 与卡的绑定关系。这些问题在整卡模式下不是那么凸显，但在细粒度共享模式下，就尤为严重了。

由于 GPU 卡相对昂贵，并且某些 AI 负载吃不满单张 GPU 算力，GPU Sharing 技术应运而生。在 Kubernetes 中，我们会将一些 AI 负载共享同一张 GPU 卡，通过增加业务部署密度，提升 GPU 利用率，从而节省成本。以 TKE qGPU 为例，在 GPU Sharing 方式下，扩展资源从 GPU 卡数量变为百分比的 qGPU Core 与 MB 的 qGPU Memory。也就是说，用户可通过 qGPU 容器虚拟化技术，申请小于一张卡的 qGPU 虚拟设备。这些设备是在单张物理卡上虚拟出来的，资源之间也是强隔离的。除了 qGPU，vCUDA、gpu share 等技术都支持多个 Pod / 容器 共享同一张 GPU 卡。基于现有 Kubernetes 架构，是无法知道 GPU 卡所包含切片资源（我将之定义为 GPU Core 与 Memory 的组合）的分布情况的。集群资源分布对管理员与用户都是黑盒。管理员无法知道整个集群 GPU 切片资源的分配情况，用户也不知道新部署业务有无资源可用。

问题二：无法支持多 GPU 后端

除分配挂载整卡的方式外，TKE qGPU、vCUDA、gpu share、GPU 池化 等 GPU 共享技术越来越被用户采用。每种方案都有自己独立的一套 Kubernetes 集成实现方式。比如在 TKE qGPU 中，我们自研了 tke-qgpu-scheduler 用于 GPU 细粒度算力与显存分配调度，配套的 tke-qgpu-manager，用于节点初始化、注册上报 qGPU 资源及 qGPU 容器虚拟化。vCUDA、gpu share 也是类似架构，同样是由调度器 + device plugin 组成。这些方案相互独立，没有统一标准，无法共通。这导致用户在单个集群中很难同时使用多种 GPU 后端技术。比如用户集群有些业务是在线推理，吃不满整卡，想申请 TKE qGPU 切片资源。另一部分业务是训练，需要分配单卡。有些仿真和模型调试业务，为了成本和弹性，想要动态从远端 GPU 池申请资源。现有方案很难同时满足以上诉求，这为基于 Kubernetes 构建统一 AI 基础设施平台增加了很多难度。

以上问题均是 TKE 在基于 Kubernetes 帮助客户构建 AI 计算平台时遇到的真实困扰。随着 AI 业务的不断精进，客户已不再仅满足于“能使用 Kubernetes GPU 资源”。对 GPU 成本的关注，对 GPU 资源的整体把控，对 GPU 不同后端的精准使用，都成为了客户能用好 GPU 算力的前提条件。既然现有体系无法满足，那我们就需要另辟蹊径，重新思考 GPU 在 Kubernetes 中的位置。

一种全新的 Kubernetes GPU 方案

PV / PVC 带来的启示

在 Kubernetes 中，资源一般是围绕 Pod 设计和定义。从重要程度上讲，集群可用资源包含两种类型