《HarmonyOS:领航者说》技术公开课来啦,大咖分享、实战解码,不容错过 了解详情
写点什么

基于 Kubernetes 的 GPU 类型调度实现

  • 2019-05-12
  • 本文字数:5112 字

    阅读完需:约 17 分钟

基于 Kubernetes 的 GPU 类型调度实现

3 月 27 日,ACM 宣布深度学习的三位缔造者——Yoshua Bengio、Yann LeCun 及 Geoffrey Hinton 获得了 2018 年度的图灵奖。与学术界相对应的,在工业界,人工智能大潮也正汹涌奔来。除了冲击人们的衣食住行医,人工智能也将成为企业转型的颠覆性力量,是企业抓住下一轮创新发展的重要机遇。


发布 | 才云 Caicloud


作者 | angao

1 行业背景

现如今,随着企业纷纷在机器学习和深度学习上加大投入,他们开始发现从头构建一个 AI 系统并非易事。


以深度学习为例。对于深度学习来说,算力是一切的根本。为了用海量数据训练性能更好的模型、加速整个流程,企业的 IT 系统需要具备快速、高效调用管理大规模 GPU 资源的能力。同时,由于算力资源十分昂贵,出于成本控制,企业也需要通过分布式训练等方式最大化 GPU 资源利用率。


面对这类新要求,基于 Kubernetes 的云原生技术为人工智能提供了一种新的工作模式。凭借其特性,Kubernetes 可以无缝将模型训练、inference 和部署扩展到多云 GPU 集群,允许数据科学家跨集群节点自动化多个 GPU 加速应用程序容器的部署、维护、调度和操作。


在 1.6 版本和 1.9 版本中,Kubernetes 先后提供了对 NVIDIA GPU、AMD GPU 容器集群管理调度的支持,进一步提高了对 GPU 等扩展资源进行统一管理和调度的能力。


但是,Kubernetes 作为新一代 AI 开发基础也存在缺陷。为训练任务分配算力资源时,它通常是随机分配容器所在节点的 GPU,而不能指定使用某类 GPU 类型


虽然这对大部分深度学习模型训练场景来说已经足够了,但如果数据科学家希望能更灵活地使用更高性能的或某一类型的 GPU,Kubernetes 的能力就有些捉襟见肘了。


因此,在这篇文章中,我将介绍才云科技在这一点上的经验,谈一谈我们如何基于 Kubernetes 灵活实现 GPU 类型的调度。

2 社区方案

问题:原生 Kubernetes 如何让 Pod 使用指定类型的 GPU?****


假设集群中有两个节点有 GPU:节点 A 上有两个 Tesla K80,节点 B 上有两个 Tesla P100。Kubernetes 可以通过 Node Label 和 Node Selector,把 Pod 调度到合适的节点上,具体如下。


先给 Node 打上特定的 Label:


# Label your nodes with the accelerator type they have.$ kubectl label nodes node-a accelerator=nvidia-tesla-k80$ kubectl label nodes node-b accelerator=nvidia-tesla-p100
复制代码


此时节点 A 如下:


$ kubectl describe node node-aName:         node-aRoles:        <none>Labels:       ...              beta.kubernetes.io/arch=amd64              beta.kubernetes.io/os=linux              kubernetes.io/hostname=node-a              accelerator=nvidia-tesla-k80Annotations:  kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock......
复制代码


当 Pod 想使用 NVIDIA Tesla K80 GPU 时,可以通过下面的方式:


apiVersion: v1kind: Podmetadata: name: cuda-vector-addspec: containers:   - name: cuda-vector-add     image: "k8s.gcr.io/cuda-vector-add:v0.1"     resources:       limits:         nvidia.com/gpu: 1 nodeSelector:   accelerator: nvidia-tesla-k80
复制代码


上述做法貌似解决了问题,但它其实治标不治本。


试想一下,如果用户集群在同一个节点上挂载了多种 GPU,我们该如何实现筛选?如果用户在同一个节点挂载了多个显存不同的 NVIDIA Tesla K80,而且想使用大于 10GiB 显存的 GPU,我们又该怎么办?


Kubernetes 的 Node Label 和 Node Selector 是没法解决这些问题的。


在上游社区,很多开发者也经常围绕此类问题展开讨论,但一直没有实际可用的方案落地。尽管如此,社区还是提供了不少精彩见解,比如下面就是社区中讨论最多的一个方案,我们的方案也借鉴了其中的部分设计。


  • 新增 ResourceClass API,用来匹配集群中的扩展资源,具体用法见下文介绍;

  • 修改 Node API,在 NodeStatus 中增加字段描述扩展资源:


type NodeStatus struct {    ComputeResources []ComputeResource}type ComputeResource struct {    // unique and deterministically generated. “resourceName-propertyHash” naming convention,    // where propertyHash is generated by calculating a hash over all resource properties    Name string    // raw resource name. E.g.: nvidia.com/nvidia-gpu    ResourceName string    // resource metadata received from device plugin.    // e.g., gpuType: k80, zone: us-west1-b    Properties map[string]string    // list of deviceIds received from device plugin.    // e.g., ["nvidia0", "nvidia1"]    Devices []string    // similar to the above but only contains allocatable devices.    AllocatableDevices []string}
复制代码


  • 扩展资源通过 Device Plugin API 向 Kubelet 组件注册其信息,随后 Kubelet 组件可以通过接收到的扩展资源信息更新节点状态,即上一步中的 ComputeResources 字段;

  • 调度器根据 ResourceClass 的定义过滤选择合适的节点。调度器监听 NodeStatus.ComputeResources 的变化并缓存节点上 ComputeResource 的分配信息,以便 ResourceClass 匹配合适的节点。


相比 Node Label 和 Node Selector,社区的方案更成熟。但不难看出,这个方案虽然可以修改 Kubernetes 核心代码和核心 API,但作为一个倍受关注的技术问题的解决方案,它的进度非常缓慢,一直没有得出更进一步的结论。

3 才云科技:GPU 类型调度实现

为了尽快实现在 Pod 使用指定类型的 GPU,并把它集成到 Caicloud Compass 中,我们在上游社区方案的基础上提出了一种全新方案。


它充分利用了 Kubernetes 的扩展性和插件机制,并遵循最小侵入和方便移植的设计原则。但是,出于简化用户使用和降低开发维护难度等原因,它还是修改了 Kubelet 和 Scheduler 组件。


同时,由于我们采用了多调度器的实现方式,所以方案中对于 Scheduler 组件的修改不影响现有集群和之后的版本升级,而 Kubelet 组件采用了向后兼容式修改,不影响已经在集群中运行的应用。


该方案不仅支持 GPU 资源,还支持包括 Infiniband、FPGAs 等扩展资源,它依赖以下现有 Kubernetes 工作机制:


  • Scheduler Extender 机制

  • Device Plugin 机制

  • API Server 扩展机制(CRD)

  • Admission 扩展机制(ResourceQuota)


在 1.6 版本中,Kubernetes 可以通过 ThirdPartyResource(TPR) 创建自定义资源,但在 1.7 版本中,它推出了 TPR 的替代方法: CustomResourceDefinition(CRD)。


CRD 允许自定义一个资源类型,因此开发人员不再需要修改 Kubernetes 核心 API 或通过 API server aggregation 增加新资源,开发和维护难度大大降低。


在我们的方案中,我们通过 CRD 定义了两种资源:ExtendedResource 和 ResourceClass。ExtendedResource 描述了一种扩展资源,比如 NVIDIA GPU;ResourceClass 则定义了容器选择哪种扩展资源,它的使用方式和 Kubernetes 中的 Extended Resource(详见参考文献)类似,用户可以直接在容器中指定,就像使用 CPU 和 Memory 一样。


下面是才云方案的基本架构图:



核心模块一:Scheduler Extender。Scheduler Extender 利用 Scheduler 组件的扩展性,负责调度容器中使用了 ResourceClass 资源对象的 Pod。它通过查询 ResourceClass 对象的定义过滤选择节点上的 ExtendedResource 资源,从而找到合适的节点并绑定,并将合适的 ExtendedResource 写到 Pod Annotation 中,供 Kubelet 组件使用。由于 Scheduler Extender 的扩展机制是通过 HTTP 的方式实现的,为了不影响集群的默认调度器性能,通过多调度器的方式为仅需要使用扩展资源的 Pod 提供调度,并且这种方式具有可移植性。


核心模块二:Nvidia Device Plugin。此组件仅针对 NVIDIA GPU 扩展资源,除了负责与 Kubelet 组件通信,它还负责创建和维护 ExtendedResource 资源对象。


那么,当同一节点上有多种不同类型的 GPU 时,这个方案是如何解决类型指定的呢


我们假设有节点 A 上有两张 GPU,一张是 NVIDIA Tesla K80,另一张是 NVIDIA Tesla P100。那么这个节点上的 NVIDIA Device Plugin 会创建两个 ExtendedResource 资源对象,分别描述这两张卡的基本属性,如型号、显存、频率等。同时,它也会向 Kubelet 注册,把 A 节点上有两张 GPU 告知节点上的 Kubelet。


这时,如果用户想创建一个使用 K80 这张 GPU 的应用,他只需要创建一个 ResourceClass 资源,在 ResourceClass 中声明使用型号为 NVIDIA Tesla K80 的 GPU(比如通过 Selector 的方式声明),然后在容器中使用这个 ResourceClass 资源。


kind: ResourceClassmetadata: name: nvidia.tesla.k80spec: selector:   matchLabels:     model: "NVIDIA Tesla K80"
kind: Podmetadata: name: example-podspec: containers: - name: example-container resources: limits: nvidia.tesla.k80: 1
复制代码


  • Kubernetes 默认调度器在经过一系列筛选过滤后,会调用 Scheduler Extender 的 Filter 方法,并将需要调度的 Pod 和过滤后的 NodeList 传递给 Filter,实现 ResourceClass 查找满足需求的 ExtendedResource,从而找到合适的节点;

  • 当调度器找到合适的节点后,调用 Scheduler Extender 的 Bind 方法,将 Pod 和 Node 绑定,并将合适的 ExtendedResource 资源对象写到 Pod Annotation 中,供 Kubelet 组件使用。


当 Pod 和 Node 绑定后,节点上的 Kubelet 组件则开始创建容器,并通过 Pod Annotation 获取容器需要使用哪块 GPU 的信息,然后通过 Device Plugin API 调用 NVIDIA Device Plugin 的 Allocate 方法。


Allocate 方法参数是容器使用的 GPU DeviceID,它通过 DeviceID 查询 GPU 的信息作为环境变量,返回给 Kubelet 用以真正创建 Pod。


从上述流程中可以看出,当我们想使用特定类型的 GPU 或者某一类 GPU 时,我们只需声明该类型的 ResourceClass 资源对象,比如:


kind: ResourceClassmetadata: name: nvidia.high.memspec: selector: - matchExpressions:   - key: "memory"     operator: "Gt"     values:       - "10GiB"
复制代码


更进一步,我们可以通过实现一个 Controller 监听集群中的 ExtendedResource 资源,自动为一种类型的 ExtendedResource 创建一个 ResourceClass 对象,为用户提供一些默认规则的 ResourceClass 资源对象。


在实际生产集群环境中,我们不仅需要满足不同应用对资源的使用,更是要做到不同应用对资源使用的限制,以及对不同的 namespace 分配不同的资源。而在 Kubernetes 中,我们一般会通过 ResourceQuota 资源对象来限制不同 namespace 的资源,例如:


kind: ResourceQuotametadata: name: example-quota namespace: systemspec: hard:   cpu: "10"   memory: 20Gi   nvidia.com/gpu: "5" 
复制代码


从上面的 ResourceQuota 定义里,我们可以看到 default 命名空间可以使用 5 块 NVIDIA GPU,但它并不限制具体该使用哪种类型的 GPU。


那么,我们该如何实现对 GPU 类型的限制呢


首先,GPU 这类扩展资源使用是标量,所以我们对标量资源的限制只能做到整数个数的限制。


其次,从上述方案中,我们知道一种 ResourceClass 代表了一种类型的扩展资源,因此对扩展资源的限制其实就是对 ResourceClass 的限制。


这样理解之后,问题就很简单明了了。下面直接给出相应的 ResourceQuota:


kind: ResourceQuotametadata: name: example-quota namespace: systemspec: hard:   cpu: "10"   memory: 20Gi   nvidia.tesla.k80: "5"
复制代码

4 展望未来

除了 GPU 类型调度,这个方案其实也可以解决 GPU 共享问题。这同样是上游社区的一个热门讨论话题。


ExtendedResource 资源中包含着 GPU 的频率、显存等信息,当多个容器想使用同一块 GPU 时,我们可以定义一个 ResourceClass 资源对象,在 ResourceClass 中声明使用多少显存(这里共享的是显存)。这样,应用部署时,我们只要在容器中声明使用该 ResourceClass 资源即可,之后 Scheduler Extender 会过滤符合条件的 ExtendedResource 对象,绑定到合适的节点上。


如果要实现资源共享,我们可能需要在 ExtendedResource 中记录显存的用量情况,供调度参考。当然,这里没有考虑到资源的隔离和限制的问题,这需要单独实现和更进一步的讨论。


以上就是我们在探索如何让 Pod 使用指定类型的 GPU 上得出的解决方案。如果你对这个主题感兴趣,或有新想法,欢迎留言一起讨论


你也可以关注我们公司的公众号(Caicloud2015),之后我们还会分享一系列内部技术和开源软件,敬请期待!


参考文献


  1. Extended Resource

  2. CustomResourceDefinition

  3. Multiple Schedulers

  4. Resource Quotas

  5. New Resource API


本文转载自公众号才云 Caicloud(ID:Caicloud2015)


原文链接


https://mp.weixin.qq.com/s/elt-P4ASilQuv9EfQdFTQw


2019-05-12 08:0013091

评论 1 条评论

发布
用户头像
用 Taint 啊
2019-05-12 11:11
回复
没有更多了
发现更多内容

kafka批量发送数据源码解析

字母哥哥

kafka 消息队列 源码解读

小程序多种开发方式对比-跨端?低代码?原生?还是云开发?

字母哥哥

小程序

九章云极DataCanvas公司获评36氪「最受投资人关注的硬核科技企业」

九章云极DataCanvas

人工智能 投资人 36氪 九章云极DataCanvas 硬科技

九章云极DataCanvas公司摘获「第五届数字金融创新大赛」最高荣誉!

九章云极DataCanvas

创新 数字金融 九章云极DataCanvas

AIRIOT助力城市管廊工程,智慧物联守护城市生命线

AIRIOT

低代码 物联网 低代码,项目开发

Linux的小知识-curl命令

技术小生

Linux curl 7月月更

鸿蒙智能家居【1.0】

坚果

HarmonyOS OpenHarmony 7月月更

2022如何评估与选择低代码开发平台?

优秀

低代码 低代码平台

让这个 CRMEB 单商户微信商城系统火起来,太好用了!

CRMEB

Http响应头处理

急需上岸的小谢

7月月更

LinkedBlockingQueue源码分析-新增和删除

zarmnosaj

7月月更

客户案例|华律网,通过观测云大幅缩短故障定位时间

观测云

【刷题记录】3. 无重复字符的最长子串

WangNing

7月月更

每日一题——PAT乙级1002题

武师叔

7月月更

java Reactive Streams响应式流式编程

字母哥哥

Java 响应式编程

聊聊 Dart 的空安全 (null safety) 特性

岛上码农

flutter ios 安卓 跨平台开发 7月月更

浅尝不辄止系列之试试腾讯云的TUIRoom(上)

为自己带盐

7月月更 TUIRoom

Meta Force原力元宇宙系统开发佛萨奇模式

薇電13242772558

智能合约

大话云原生之灰度发布篇-从步行到坐缆车的自动化服务升级

字母哥哥

灰度发布 #Kubernetes#

Java 代码中数字中间带下划线是几个意思

HoneyMoose

C++中的STL库函数之万能图——map

KEY.L

7月月更

tauri+vue开发跨操作系统的桌面应用

字母哥哥

rust Vue tauri

第四期SFO销毁,Starfish OS如何对SFO价值赋能?

BlockChain先知

Java 9 缩小字符串( Compact String)

HoneyMoose

Java 6 压缩字符串(Compressed String)

HoneyMoose

docker镜像分层原理及容器写时复制

字母哥哥

Docker 镜像

消息队列与快递柜之间妙不可言的关系

字母哥哥

消息队列

Java多线程案例之任务定时执行器

未见花闻

7月月更

使用高斯Redis实现二级索引

华为云开发者联盟

数据库 后端

开源重器!九章云极DataCanvas公司YLearn因果学习开源项目即将发布!

九章云极DataCanvas

人工智能 开源项目 #Github 因果学习 #工具包

应用实践 | 数仓体系效率全面提升!同程数科基于 Apache Doris 的数据仓库建设

SelectDB

数据库 数据仓库 架构演进 Doris

基于 Kubernetes 的 GPU 类型调度实现_AI&大模型_angao_InfoQ精选文章