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集羣，敬請期待。

識別如下二維碼，閱讀更多幹貨：