摘要：摘要的生態(tài)地位已經(jīng)確立，可擴展性將是其發(fā)力的主戰(zhàn)場。該功能由于只是替代了做了些更名的工作，所以在已經(jīng)是穩(wěn)定的狀態(tài)了。異構(gòu)計算作為非常重要的新戰(zhàn)場，非常重視。而異構(gòu)計算需要強大的計算力和高性能網(wǎng)絡，需要提供一種統(tǒng)一的方式與等高性能硬件集成。

摘要： Kubernetes的生態(tài)地位已經(jīng)確立，可擴展性將是其發(fā)力的主戰(zhàn)場。異構(gòu)計算作為非常重要的新戰(zhàn)場，Kubernetes非常重視。而異構(gòu)計算需要強大的計算力和高性能網(wǎng)絡，需要提供一種統(tǒng)一的方式與GPU、FPGA、NIC、InfiniBand等高性能硬件集成。

點此查看原文：http://click.aliyun.com/m/43607/

Kubernetes的Device Plugin設計解讀

最近在調(diào)研Kubernetes的GPU調(diào)度和運行機制，發(fā)現(xiàn)傳統(tǒng)的alpha.kubernetes.io/nvidia-gpu即將在1.11版本中下線，和GPU相關(guān)的調(diào)度和部署的代碼將徹底從主干代碼中移除。

取而代之的是通過Extended Resource+Device Plugin兩個Kubernetes的內(nèi)置模塊，外加由設備提供商實現(xiàn)的相應Device Plugin, 完成從設備的集群級別調(diào)度至工作節(jié)點，到設備與容器的實際綁定。

首先思考的第一個問題是為什么進入alpha.kubernetes.io/nvidia-gpu主干一年之久的GPU功能徹底移除？

1.OutOfTree是Kubernetes一個很好的理念，之前的Cloud Provider的重構(gòu)也是類似的工作。對于Kubernetes來說，不做瑞士軍刀，專注于自身核心和通用能力，而將像GPU，InfiniBand,FPGA和公共云能力的工作完全交給社區(qū)和領(lǐng)域?qū)＜摇＿@樣一方面可以降低軟件自身使用的復雜度，減小穩(wěn)定性風險，另外OutOfTree分開迭代也能夠更靈活實現(xiàn)的功能升級。
2.而開放的軟件架構(gòu)設計和標準也調(diào)動了社區(qū)參與的積極性，而活躍的社區(qū)其實是Kubernetes打贏容器調(diào)度框架之戰(zhàn)的核心法寶。

先來簡要介紹一下kubernetes這兩個模塊：

Extended Resource: 一種自定義資源擴展的方式，將資源的名稱和總數(shù)量上報給API server，而Scheduler則根據(jù)使用該資源pod的創(chuàng)建和刪除，做資源可用量的加減法，進而在調(diào)度時刻判斷是否有滿足資源條件的節(jié)點。目前這里的Extended Resource的增加和減少單元必須是整數(shù)，比如你可以分配1個GPU，但是不能分配0.5個GPU。該功能由于只是替代了Opaque integer resources,做了些更名的工作，所以在1.8已經(jīng)是穩(wěn)定的狀態(tài)了。但是當integer這個關(guān)鍵詞被移除，也引發(fā)我們的想象，未來會不會有0.5存在的可能性？
Device Plugin：通過提供通用設備插件機制和標準的設備API接口。這樣設備廠商只需要實現(xiàn)相應的API接口，無需修改Kubelet主干代碼，就可以實現(xiàn)支持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，需要實現(xiàn)以下兩個方法 ListAndWatch和Allocate，并監(jiān)聽在/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會調(diào)用該API做設備發(fā)現(xiàn)和狀態(tài)更新（比如設備變得不健康）
Allocate: 當Kubelet創(chuàng)建要使用該設備的容器時， Kubelet會調(diào)用該API執(zhí)行設備相應的操作并且通知Kubelet初始化容器所需的device，volume和環(huán)境變量的配置。

插件生命周期管理：
1.插件啟動時，以grpc的形式通過/var/lib/kubelet/device-plugins/kubelet.sock向Kubelet注冊，同時提供插件的監(jiān)聽Unix Socket，API版本號和設備名稱（比如nvidia.com/gpu）。Kubelet將會把這些設備暴露到Node狀態(tài)中，以Extended Resource的要求發(fā)送到API server中，后續(xù)Scheduler會根據(jù)這些信息進行調(diào)度。
2.插件啟動后，Kubelet會建立一個到插件的listAndWatch長連接，當插件檢測到某個設備不健康的時候，就會主動通知Kubelet。此時如果這個設備處于空閑狀態(tài)，Kubelet就會將其挪出可分配列表；如果該設備已經(jīng)被某個pod使用,Kubelet就會將該Pod殺掉
3.插件啟動后可以利用Kubelet的socket持續(xù)檢查Kubelet的狀態(tài)，如果Kubelet重啟，插件也會相應的重啟，并且重新向Kubelet注冊自己

部署方式

一般可以支持daemonset和非容器化的部署，目前官方推薦使用deamonset部署。

實現(xiàn)樣例

Nvidia 的官方GPU插件
NVIDIA 提供了一個基于 Device Plugins 接口的 GPU 設備插件NVIDIA/k8s-device-plugin, 從用戶角度變得更加簡單了。比起傳統(tǒng)的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設備插件實現(xiàn)，但是只支持運行在Google Container Engine的平臺上，可以通過container-engine-accelerators了解

Solarflare NIC 插件

網(wǎng)卡造商Solarflare也實現(xiàn)了自己的設備插件sfc-device-plugin， 可以通過demo體驗用戶感受。

總結(jié)

Kubernetes的生態(tài)地位已經(jīng)確立，可擴展性將是其發(fā)力的主戰(zhàn)場。異構(gòu)計算作為非常重要的新戰(zhàn)場，Kubernetes非常重視。而異構(gòu)計算需要強大的計算力和高性能網(wǎng)絡，需要提供一種統(tǒng)一的方式與GPU、FPGA、NIC、InfiniBand等高性能硬件集成。而Device Plugin是Kubernetes給出的答案，還是非常簡單優(yōu)雅的，雖然還在演進之中，但是未來可期。阿里云容器服務隨后也會推出基于device plugin的Kubernetes GPU 1.9.3集群，敬請期待。

識別以下二維碼，閱讀更多干貨：