首页 > 其他分享 >GPU算力共享

GPU算力共享

时间:2024-02-25 09:04:35浏览次数:26  
标签:Kubernetes Plugin kubelet Device GPU 共享 算力 设备

工作原理
通过扩展的方式管理 GPU 资源 Kubernetes 本身是通过插件扩展的机制来管理 GPU 资源的,具体来说这里有两个独立的内部机制。 第一个是 Extend Resources,允许用户自定义资源名称。而该资源的度量是整数级别,这样做的目的在于通过一个通用的模式支持不同的异构设备,包括 RDMA、FPGA、AMD GPU 等等,而不仅仅是为 Nvidia GPU 设计的; 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。 当然如果使用的是 Device Plugin,就不需要做这个 PACTH 操作,只需要遵从 Device Plugin 的编程模型,在设备上报的工作中 Device Plugin 就会完成这个操作。
Device Plugin 工作机制 介绍一下 Device Plugin 的工作机制,整个 Device Plugin 的工作流程可以分成两个部分: - 一个是启动时刻的资源上报; - 另一个是用户使用时刻的调度和运行。 Device Plugin 的开发非常简单。主要包括最关注与最核心的两个事件方法: - 其中 ListAndWatch 对应资源的上报,同时还提供健康检查的机制。当设备不健康的时候,可以上报给 Kubernetes 不健康设备的 ID,让 Device Plugin Framework 将这个设备从可调度设备中移除; - 而 Allocate 会被 Device Plugin 在部署容器时调用,传入的参数核心就是容器会使用的设备 ID,返回的参数是容器启动时,需要的设备、数据卷以及环境变量。
资源上报和监控

- 对于每一个硬件设备,都需要它所对应的 Device Plugin 进行管理,这些 Device Plugin 以客户端的身份通过 GRPC 的方式对 kubelet 中的 Device Plugin Manager 进行连接,并且将自己监听的 Unis socket api 的版本号和设备名称比如 GPU,上报给 kubelet。 - 我们来看一下 Device Plugin 资源上报的整个流程。总的来说,整个过程分为四步,其中前三步都是发生在节点上,第四步是 kubelet 和 api-server 的交互。         - 第一步是 Device Plugin 的注册,需要 Kubernetes 知道要跟哪个 Device Plugin 进行交互。这是因为一个节点上可能有多个设备,需要 Device Plugin 以客户端的身份向 Kubelet 汇报三件事情。             - 我是谁?就是 Device Plugin 所管理的设备名称,是 GPU 还是 RDMA;             - 我在哪?就是插件自身监听的 unis socket 所在的文件位置,让 kubelet 能够调用自己;             - 交互协议,即 API 的版本号。         - 第二步是服务启动,Device Plugin 会启动一个 GRPC 的 server。在此之后 Device Plugin 一直以这个服务器的身份提供服务让 kubelet 来访问,而监听地址和提供 API 的版本就已经在第一步完成;         - 第三步,当该 GRPC server 启动之后,kubelet 会建立一个到 Device Plugin 的 ListAndWatch 的长连接, 用来发现设备 ID 以及设备的健康状态。当 Device Plugin 检测到某个设备不健康的时候,就会主动通知 kubelet。而此时如果这个设备处于空闲状态,kubelet 会将其移除可分配的列表。但是当这个设备已经被某个 Pod 所使用的时候,kubelet 就不会做任何事情,如果此时杀掉这个 Pod 是一个很危险的操作。         - 第四步,kubelet 会将这些设备暴露到 Node 节点的状态中,把设备数量发送到 Kubernetes 的 api-server 中。后续调度器可以根据这些信息进行调度。             - 需要注意的是 kubelet 在向 api-server 进行汇报的时候,只会汇报该 GPU 对应的数量。而 kubelet 自身的 Device Plugin Manager 会对这个 GPU 的 ID 列表进行保存,并用来具体的设备分配。而这个对于 Kubernetes 全局调度器来说,它不掌握这个 GPU 的 ID 列表,它只知道 GPU 的数量。这就意味着在现有的 Device Plugin 工作机制下,Kubernetes 的全局调度器无法进行更复杂的调度。比如说想做两个 GPU 的亲和性调度,同一个节点两个 GPU 可能需要进行通过 NVLINK 通讯而不是 PCIe 通讯,才能达到更好的数据传输效果。在这种需求下,目前的 Device Plugin 调度机制中是无法实现的。
Pod 的调度和运行

    - Pod 想使用一个 GPU 的时候,它只需要像之前的例子一样,在 Pod 的 Resource 下 limits 字段中声明 GPU 资源和对应的数量 (比如nvidia.com/gpu: 1)。Kubernetes 会找到满足数量条件的节点,然后将该节点的 GPU 数量减 1,并且完成 Pod 与 Node 的绑定。     - 绑定成功后,自然就会被对应节点的 kubelet 拿来创建容器。而当 kubelet 发现这个 Pod 的容器请求的资源是一个 GPU 的时候,kubelet 就会委托自己内部的 Device Plugin Manager 模块,从自己持有的 GPU 的 ID 列表中选择一个可用的 GPU 分配给该容器。此时 kubelet 就会向本机的 Device Plugin 发起一个 Allocate 请求,这个请求所携带的参数,正是即将分配给该容器的设备 ID 列表。     - Device Plugin 收到 AllocateRequest 请求之后,它就会根据 kubelet 传过来的设备 ID,去寻找这个设备 ID 对应的设备路径、驱动目录以及环境变量,并且以 AllocateResponse 的形式返还给 kubelet。     - AllocateResponse 中所携带的设备路径和驱动目录信息,一旦返回给 kubelet 之后,kubelet 就会根据这些信息执行为容器分配 GPU 的操作,这样 Docker 会根据 kubelet 的指令去创建容器,而这个容器中就会出现 GPU 设备。并且把它所需要的驱动目录给挂载进来,至此 Kubernetes 为 Pod 分配一个 GPU 的流程就结束了。
Device Plugin 机制的缺陷 需要指出的是 Device Plugin 整个工作机制和流程上,实际上跟学术界和工业界的真实场景有比较大的差异。这里最大的问题在于 GPU 资源的调度工作,实际上都是在 kubelet 上完成的。 而作为全局的调度器对这个参与是非常有限的,作为传统的 Kubernetes 调度器来说,它只能处理 GPU 数量。一旦你的设备是异构的,不能简单地使用数目去描述需求的时候,比如我的 Pod 想运行在两个有 nvlink 的 GPU 上,这个 Device Plugin 就完全不能处理。 更不用说在许多场景上,我们希望调度器进行调度的时候,是根据整个集群的设备进行全局调度,这种场景是目前的 Device Plugin 无法满足的。 更为棘手的是在 Device Plugin 的设计和实现中,像 Allocate 和 ListAndWatch 的 API 去增加可扩展的参数也是没有作用的。这就是当我们使用一些比较复杂的设备使用需求的时候,实际上是无法通过 Device Plugin 来扩展 API 实现的。 因此目前的 Device Plugin 设计涵盖的场景其实是非常单一的, 是一个可用但是不好用的状态。这就能解释为什么像 Nvidia 这些厂商都实现了一个基于 Kubernetes 上游代码进行 fork 了自己解决方案,也是不得已而为之。  

标签:Kubernetes,Plugin,kubelet,Device,GPU,共享,算力,设备
From: https://www.cnblogs.com/muzinan110/p/18031910

相关文章

  • 用于linux和windows共享的samba服务
    ftp是客户端、服务端两个服务端是vsftpdlinux客户端是ftp命令,以及其他各种支持ftp协议的工具,如windows下提供很多软件,支持图形化上传下载ftp,xftpwindows访问ftp命令行操作C:\Users\yu>ftpftp>byeC:\Users\yu>C:\Users\yu>C:\Users\yu>ftp10.0.0.31连接到10.......
  • 文件共享服务ftp
    文件共享服务方案有很多,了解即可ftp(简单文件传输服务)提供用户认证机制可以输入账号密码python-mSimpleHTTPServernginx也提供了文件下载的功能提供用户认证机制反向代理,负载均衡web服务器,静态文件服务器的作用如ftp服务器的作用samba(linux和windows之间共享数......
  • 基于EasyCVR视频汇聚系统的公安网视频联网共享视频云平台建设思路分析(二)
    一、需求分析随着科技的飞速发展,视频监控联网技术在公安工作中发挥着越来越重要的作用。为了提高公安部门对各类事件的响应速度和处理能力,建设一个高效、稳定的公安视频联网共享云平台显得尤为重要。通过建设开放的视频联网共享云平台,实现各类文件的统一存储,同时保证系统弹性扩展......
  • docker 部署Nextcloud文件共享系统
    部署Nextcloud:文件共享系统,和windows上进行文件管理方式一样。创建目录,在目录中创建文件,上传文件。使用DockerCompose(推荐方式)创建一个docker-compose.yml文件:version:'3'services:db:image:mariadb:latestrestart:alwaysenvironment:MYSQL......
  • 多个docker容器如何共享网络
    目录多个docker容器如何共享网络一、创建共享网络二、docker-compose启动容器共享网络参考文档:多个docker容器如何共享网络一、创建共享网络无论哪种方式,第一步都是创建一个共享网络,这里创建一个名为local_public的网络,可以自定义,执行后会输出一个网络的ID,代表创建成功,也可......
  • 解决VMware与win10无法共享目录
    1、安装VMwareTools这一步适用于多数情况,但对于高版本的VMWare这一步无效,当然了,先试一试总没有坏处。有看见网上说如果VMware内安装的是高版本的Ubuntu,安装的VMwareTools会破坏Ubuntu。关于这一点博主没有验证,请自行验证。安装方法很简单:1)在VMware的虚拟机菜单下,点击“重......
  • 在k8S中,一个Pod如何实现数据持久化?数据共享?跨节点Pod如何实现数据共享?
    在Kubernetes(k8S)中,同一个Pod内实现数据持久化和数据共享的方式主要通过使用Volume(卷)来完成。Volume是Kubernetes提供的一种抽象,它代表了宿主机上的一个目录或存储设备,可以被Pod中的一个或多个容器挂载并访问。1.数据持久化:EmptyDir:在Pod创建时自动创建一个空......
  • 关于NFS 网络文件共享服务的安装、配置
    NFS中文意思是网络文件系统。它用于类linux系统之间的文件共享、类似windows系统的文件共享、磁盘映射。NFS是C/S架构,在server上设置共享目录、并设置哪些共享网段、文件查看方式等。在client上挂载server共享目录到本地就可以查看共享内容。cilent和server之间通过tcp协议进......
  • 跨界协作:借助gRPC实现Python数据分析能力的共享
    gRPC是一个高性能、开源、通用的远程过程调用(RPC)框架,由Google推出。它基于HTTP/2协议标准设计开发,默认采用ProtocolBuffers数据序列化协议,支持多种开发语言。在gRPC中,客户端可以像调用本地对象一样直接调用另一台不同的机器上服务端应用的方法,使得您能够更容易地创建分布式应用......
  • bat+powershell实现win10一键共享
    网卡Ethernet共享给网卡Ethernet2C:\tools\share_net.ps1#RegistertheHNetCfglibrary(once)#regsvr32hnetcfg.dll#CreateaNetSharingManagerobject$m=New-Object-ComObjectHNetCfg.HNetShare#Listconnections$m.EnumEveryConnection|%{$m.NetConnect......