Kubernetes的Device Plugin设计解读

maoerya · · 1090 次点击 · 开始浏览    置顶
这是一个创建于 的主题,其中的信息可能已经有所发展或是发生改变。

摘要: Kubernetes的生态地位已经确立,可扩展性将是其发力的主战场。异构计算作为非常重要的新战场,Kubernetes非常重视。而异构计算需要强大的计算力和高性能网络,需要提供一种统一的方式与GPU、FPGA、NIC、InfiniBand等高性能硬件集成。 **点此查看原文:http://click.aliyun.com/m/43607/** **Kubernetes的Device Plugin设计解读** 最近在调研Kubernetes的GPU调度和运行机制,发现传统的`alpha.kubernetes.io/nvidia-gpu`即将在1.11版本中下线,和GPU相关的调度和部署的代码将彻底从主干代码中移除。 取而代之的是通过[Extended Resource](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/?spm=a2c4e.11153959.blogcont498185.11.3ae63614DyRbdI#extended-resources)+[Device Plugin](https://kubernetes.io/docs/concepts/cluster-administration/device-plugins/?spm=a2c4e.11153959.blogcont498185.12.3ae63614d0bt9c)两个Kubernetes的内置模块,外加由设备提供商实现的相应Device Plugin, 完成从设备的集群级别调度至工作节点,到设备与容器的实际绑定。 首先思考的第一个问题是为什么进入`alpha.kubernetes.io/nvidia-gpu`主干一年之久的GPU功能彻底移除? 1.OutOfTree是Kubernetes一个很好的理念,之前的Cloud Provider的重构也是类似的工作。对于Kubernetes来说,不做瑞士军刀,专注于自身核心和通用能力,而将像GPU,InfiniBand,FPGA和公共云能力的工作完全交给社区和领域专家。这样一方面可以降低软件自身使用的复杂度,减小稳定性风险,另外OutOfTree分开迭代也能够更灵活实现的功能升级。 2.而开放的软件架构设计和标准也调动了社区参与的积极性,而活跃的社区其实是Kubernetes打赢容器调度框架之战的核心法宝。 先来简要介绍一下kubernetes这两个模块: [Extended Resource](https://kubernetes.io/docs/tasks/administer-cluster/extended-resource-node/?spm=a2c4e.11153959.blogcont498185.13.3ae63614k28q3e): 一种自定义资源扩展的方式,将资源的名称和总数量上报给API server,而Scheduler则根据使用该资源pod的创建和删除,做资源可用量的加减法,进而在调度时刻判断是否有满足资源条件的节点。目前这里的Extended Resource的增加和减少单元必须是整数,比如你可以分配1个GPU,但是不能分配0.5个GPU。该功能由于只是替代了[Opaque integer resources](https://github.com/rootsongjc/kubernetes.github.io/blob/master/docs/tasks/configure-pod-container/opaque-integer-resource.md?spm=a2c4e.11153959.blogcont498185.14.3ae636144hriJ9&file=opaque-integer-resource.md),做了些更名的工作,所以在1.8已经是稳定的状态了。但是当integer这个关键词被移除,也引发我们的想象,未来会不会有0.5存在的可能性? [Device Plugin](https://kubernetes.io/docs/concepts/cluster-administration/device-plugins/?spm=a2c4e.11153959.blogcont498185.15.3ae63614Bg2zWO):通过提供通用设备插件机制和标准的设备API接口。这样设备厂商只需要实现相应的API接口,无需修改Kubelet主干代码,就可以实现支持GPU、FPGA、高性能 NIC、InfiniBand 等各种设备的扩展。该能力在Kubernetes 1.8和1.9版本处于Alpha版本,在1.10会进入Beta版本。 应该说这个功能目前还比较新,需要通过feature gate打开, 即配置 --feature-gates=DevicePlugins=true **Device Plugin的设计:** **API设计:** 实际上Device plugins实际上是简单的grpc server,需要实现以下两个方法 ListAndWatch和Allocate,并监听在/var/lib/kubelet/device-plugins/目录下的Unix Socket,比如/var/lib/kubelet/device-plugins/nvidia.sock ``` service DevicePlugin { // returns a stream of []Device rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {} rpc Allocate(AllocateRequest) returns (AllocateResponse) {} } ``` 其中: ListAndWatch: Kubelet会调用该API做设备发现和状态更新(比如设备变得不健康) Allocate: 当Kubelet创建要使用该设备的容器时, Kubelet会调用该API执行设备相应的操作并且通知Kubelet初始化容器所需的device,volume和环境变量的配置。 **插件生命周期管理:** 1.插件启动时,以grpc的形式通过/var/lib/kubelet/device-plugins/kubelet.sock向Kubelet注册,同时提供插件的监听Unix Socket,API版本号和设备名称(比如nvidia.com/gpu)。Kubelet将会把这些设备暴露到Node状态中,以Extended Resource的要求发送到API server中,后续Scheduler会根据这些信息进行调度。 2.插件启动后,Kubelet会建立一个到插件的listAndWatch长连接,当插件检测到某个设备不健康的时候,就会主动通知Kubelet。此时如果这个设备处于空闲状态,Kubelet就会将其挪出可分配列表;如果该设备已经被某个pod使用,Kubelet就会将该Pod杀掉 3.插件启动后可以利用Kubelet的socket持续检查Kubelet的状态,如果Kubelet重启,插件也会相应的重启,并且重新向Kubelet注册自己 ![图片描述](http://img.blog.csdn.net/20180312160400891?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveXVucWlpbnNpZ2h0/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast) **部署方式** 一般可以支持daemonset和非容器化的部署,目前官方推荐使用deamonset部署。 **实现样例** **Nvidia 的官方GPU插件** NVIDIA 提供了一个基于 Device Plugins 接口的 GPU 设备插件[NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin?spm=a2c4e.11153959.blogcont498185.16.3ae63614urFmKd), 从用户角度变得更加简单了。比起传统的alpha.kubernetes.io/nvidia-gpu, 不再需要使用volumes指定CUDA需要使用的库。 ``` apiVersion: apps/v1 kind: Deployment metadata: name: tf-notebook labels: app: tf-notebook spec: template: # define the pods specifications metadata: labels: app: tf-notebook spec: containers: - name: tf-notebook image: tensorflow/tensorflow:1.4.1-gpu-py3 resources: limits: nvidia.com/gpu: 1 ``` **Google GCP GPU插件** GCP也提供了一个GPU设备插件实现,但是只支持运行在Google Container Engine的平台上,可以通过[container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators?spm=a2c4e.11153959.blogcont498185.17.3ae63614AScx4J)了解 **Solarflare NIC 插件** 网卡造商Solarflare也实现了自己的设备插件[sfc-device-plugin](https://github.com/vikaschoudhary16/sfc-device-plugin?spm=a2c4e.11153959.blogcont498185.18.3ae636143Z1aEK), 可以通过[demo](https://asciinema.org/a/UyzMDcSHB42eWrP0soiwPyhEM?spm=a2c4e.11153959.blogcont498185.19.3ae63614rl2BkS)体验用户感受。 **总结** Kubernetes的生态地位已经确立,可扩展性将是其发力的主战场。异构计算作为非常重要的新战场,Kubernetes非常重视。而异构计算需要强大的计算力和高性能网络,需要提供一种统一的方式与GPU、FPGA、NIC、InfiniBand等高性能硬件集成。而Device Plugin是Kubernetes给出的答案,还是非常简单优雅的,虽然还在演进之中,但是未来可期。阿里云容器服务随后也会推出基于device plugin的Kubernetes GPU 1.9.3集群,敬请期待。 **识别以下二维码,阅读更多干货:** ![图片描述](http://img.blog.csdn.net/20180312161216266?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveXVucWlpbnNpZ2h0/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)

有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1090 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传