Kubernetes的Device Plugin设计解读

摘要： 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+Device Plugin两个Kubernetes的内置模块，外加由设备提供商实现的相应Device Plugin, 完成从设备的集群级别调度至工做节点，到设备与容器的实际绑定。

首先思考的第一个问题是为何进入alpha.kubernetes.io/nvidia-gpu主干一年之久的GPU功能完全移除？

1.OutOfTree是Kubernetes一个很好的理念，以前的Cloud Provider的重构也是相似的工做。对于Kubernetes来讲，不作瑞士军刀，专一于自身核心和通用能力，而将像GPU，InfiniBand,FPGA和公共云能力的工做彻底交给社区和领域专家。这样一方面能够下降软件自身使用的复杂度，减少稳定性风险，另外OutOfTree分开迭代也可以更灵活实现的功能升级。
2.而开放的软件架构设计和标准也调动了社区参与的积极性，而活跃的社区实际上是Kubernetes打赢容器调度框架之战的核心法宝。

先来简要介绍一下kubernetes这两个模块：

Extended Resource: 一种自定义资源扩展的方式，将资源的名称和总数量上报给API server，而Scheduler则根据使用该资源pod的建立和删除，作资源可用量的加减法，进而在调度时刻判断是否有知足资源条件的节点。目前这里的Extended Resource的增长和减小单元必须是整数，好比你能够分配1个GPU，可是不能分配0.5个GPU。该功能因为只是替代了Opaque integer resources,作了些改名的工做，因此在1.8已是稳定的状态了。可是当integer这个关键词被移除，也引起咱们的想象，将来会不会有0.5存在的可能性？
Device Plugin：经过提供通用设备插件机制和标准的设备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注册本身

部署方式

通常能够支持daemonset和非容器化的部署，目前官方推荐使用deamonset部署。

实现样例

Nvidia 的官方GPU插件
NVIDIA 提供了一个基于 Device Plugins 接口的 GPU 设备插件NVIDIA/k8s-device-plugin, 从用户角度变得更加简单了。比起传统的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了解

Solarflare NIC 插件

网卡造商Solarflare也实现了本身的设备插件sfc-device-plugin， 能够经过demo体验用户感觉。

总结

Kubernetes的生态地位已经确立，可扩展性将是其发力的主战场。异构计算做为很是重要的新战场，Kubernetes很是重视。而异构计算须要强大的计算力和高性能网络，须要提供一种统一的方式与GPU、FPGA、NIC、InfiniBand等高性能硬件集成。而Device Plugin是Kubernetes给出的答案，仍是很是简单优雅的，虽然还在演进之中，可是将来可期。阿里云容器服务随后也会推出基于device plugin的Kubernetes GPU 1.9.3集群，敬请期待。

识别如下二维码，阅读更多干货：