摘要：如果上的資源耗盡，這類將無法成功調度。將這個資源及其對應的設備個數記錄到更新到。

extended-resources在k8s1.9中是一個stable的特性?？梢杂靡痪湓拋砀爬ㄟ@個特性：

通過向apiserver發送一個patch node 的請求，為這個node增加一個自定義的資源類型，用于以該資源的配額統計和相應的QoS的配置。

舉例：

curl --header "Content-Type: application/json-patch+json" 
--request PATCH 
--data "[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]" 
http://localhost:8001/api/v1/nodes/10.123.123.123/status

如上，我們為10.123.123.123這個node增加了一個resource：example.com/dongle (命令中的 ~1 會轉化為 / ) ,這個node的capicity/allocable中會展示其有4個example.com/dongle資源：

"capacity": {
  "alpha.kubernetes.io/nvidia-gpu": "0",
  "cpu": "2",
  "memory": "2049008Ki",
  "example.com/dongle": "4",

如果我們要清除這個資源可以使用：

curl --header "Content-Type: application/json-patch+json" 
--request PATCH 
--data "[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]" 
http://localhost:8001/api/v1/nodes//status

如果對QoS的含義不了解，可以參考我之前的文章

先假設整個k8s集群中我們只對10.123.123.123這個node動了手腳，當我們創建pod時，在spec.containers.resources.requests/limits中可以設置

 "example.com/dongle": "2"

從而讓pod被調度到10.123.123.123上并消耗其2個example.com/dongle資源。這個資源將與cpu、memory一樣，被調度器進行統計，并用在pod的調度算法中。如果node上的example.com/dongle資源耗盡，這類pod將無法成功調度。

設備插件從1.8版本開始加入，到1.9目前仍是alpha特性，設備插件的作用是在不更改k8s代碼的情況下，向k8s提供各種資源的統計信息和使用預備工作。這里說的資源如GPU、高性能NIC、FPGA、infiniBand或其他。

device-plugin功能由DevicePlugins這個參數控制，默認是禁用的，啟用這個參數后就可以令kubelet開放Register 的grpc服務。 device-plugin可以通過這個服務向kubelet注冊自己，注冊時要告知kubelet：

本device-plugin的Unix socket 名稱。用于kubelet作為grpc 客戶端向本device-plugin發請求；

本device-plugin的API版本；

本device-plugin要開放的資源名，此處資源名必須遵循一定格式，形如：nvidia.com/gpu

注冊成功后，kubelet會向device-plugin調用Listandwatch方法獲取設備的列表，此處設備的列表以該資源所有設備的描述信息（id、健康狀態）組成數組返回。kubelet將這個資源及其對應的設備個數記錄到node.status.capicity/allocable 更新到apiserver。該方法會一直循環檢查，一旦設備異?；蛘邚臋C器上拔出，會將最新的設備列表返回給kubelet。

如此一來，創建pod時，spec.containers.resource.limits/requests 中就可以增加如 "nvidia.com/gpu" : 2 這樣的字段，來告知k8s將pod調度到有超過2個nvidia.com/gpu資源余量的nodes上（這里與上文的extended-resources中QoS是一個道理）。當node上要運行該pod時，kubelet會向device-plugin調用Allocate方法，device-plugin在這里可能會做一些初始化的操作，比如GPU清理或QRNG初始化之類。如果初始化成功。該方法會返回分配給該pod使用的設備在容器創建時需要如何配置，這個配置會被傳遞到container runtime。用于run 容器時作為參數進行配置。

完整的使用流程如下圖（圖片來源：https://github.com/kubernetes...）

我們從創建pod的整個流程中一步步解析代碼執行：

創建帶特殊資源設備的pod；
調度器從cache中選擇滿足要求的node；
node收到ADD POD， 對pod執行admit方法進行可運行的判斷。

kubelet初始化時增加了一個admitHandler：

klet.admitHandlers.AddPodAdmitHandler(lifecycle.NewPredicateAdmitHandler(klet.getNodeAnyWay, criticalPodAdmissionHandler, klet.containerManager.UpdatePluginResources))

其中就包括了klet.containerManager.UpdatePluginResources方法，該方法會執行devicepluginManager中的Allocate方法：

func (cm *containerManagerImpl) UpdatePluginResources(node *schedulercache.NodeInfo, attrs *lifecycle.PodAdmitAttributes) error {
      return cm.devicePluginManager.Allocate(node, attrs)
}

上述的Allocate方法，會將kubelet本身緩存記錄的資源可用量進行判斷和計算；
然后選定要使用的設備，向device-plugin發送Allocate調用，device-plugin會針對request中的設備id，檢查是否可用，并將使用這幾個設備需要的使用參數返回給kubelet，返回的格式是：

type AllocateResponse struct {
 // List of environment variable to be set in the container to access one of more devices.
 Envs map[string]string
 // Mounts for the container.
 Mounts []*Mount
 // Devices for the container.
 Devices []*DeviceSpec
}

最后將要這個pod要使用哪幾個資源設備（設備id、以及deviceplugin返回的設備使用參數）記錄在podDevices中,podDevices就是一個從pod到資源設備詳細信息的映射，是一個多層次的map結構。

kubelet要創建pod的容器時，會調用到GenerateRunContainerOptions方法，用于生成容器runtime要的參數，該方法中會首先調用：

opts, err := kl.containerManager.GetResources(pod, container)

而containerManager中GetResources會調用devicePluginManager中的GetDeviceRunContainerOptions方法，最后執行deviceRunContainerOptions方法，從podDevices中獲取這個pod相應的容器需要使用的設備，并組織成容器運行時參數的對象opts，最終run container時會被用到。比如gpu容器，會在opts中增加devices參數的指定，最后容器創建時會帶有需要的設備。

部署device-plugin插件最佳的方法是使用k8s的daemonset，因為daemonset可以在插件失敗是重新啟動之，且會自動分布到滿足條件的所有node節點上。

社區參考文檔
https://kubernetes.io/docs/ta...