摘要：如果上的資源耗盡，這類將無法成功調(diào)度。將這個(gè)資源及其對(duì)應(yīng)的設(shè)備個(gè)數(shù)記錄到更新到。

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

通過向apiserver發(fā)送一個(gè)patch node 的請(qǐng)求，為這個(gè)node增加一個(gè)自定義的資源類型，用于以該資源的配額統(tǒng)計(jì)和相應(yīng)的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

如上，我們?yōu)?0.123.123.123這個(gè)node增加了一個(gè)resource：example.com/dongle (命令中的 ~1 會(huì)轉(zhuǎn)化為 / ) ,這個(gè)node的capicity/allocable中會(huì)展示其有4個(gè)example.com/dongle資源：

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

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

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

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

先假設(shè)整個(gè)k8s集群中我們只對(duì)10.123.123.123這個(gè)node動(dòng)了手腳，當(dāng)我們創(chuàng)建pod時(shí)，在spec.containers.resources.requests/limits中可以設(shè)置

 "example.com/dongle": "2"

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

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

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

本device-plugin的Unix socket 名稱。用于kubelet作為grpc 客戶端向本device-plugin發(fā)請(qǐng)求；

本device-plugin的API版本；

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

注冊(cè)成功后，kubelet會(huì)向device-plugin調(diào)用Listandwatch方法獲取設(shè)備的列表，此處設(shè)備的列表以該資源所有設(shè)備的描述信息（id、健康狀態(tài)）組成數(shù)組返回。kubelet將這個(gè)資源及其對(duì)應(yīng)的設(shè)備個(gè)數(shù)記錄到node.status.capicity/allocable 更新到apiserver。該方法會(huì)一直循環(huán)檢查，一旦設(shè)備異常或者從機(jī)器上拔出，會(huì)將最新的設(shè)備列表返回給kubelet。

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

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

我們從創(chuàng)建pod的整個(gè)流程中一步步解析代碼執(zhí)行：

創(chuàng)建帶特殊資源設(shè)備的pod；
調(diào)度器從cache中選擇滿足要求的node；
node收到ADD POD， 對(duì)pod執(zhí)行admit方法進(jìn)行可運(yùn)行的判斷。

kubelet初始化時(shí)增加了一個(gè)admitHandler：

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

其中就包括了klet.containerManager.UpdatePluginResources方法，該方法會(huì)執(zhí)行devicepluginManager中的Allocate方法：

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

上述的Allocate方法，會(huì)將kubelet本身緩存記錄的資源可用量進(jìn)行判斷和計(jì)算；
然后選定要使用的設(shè)備，向device-plugin發(fā)送Allocate調(diào)用，device-plugin會(huì)針對(duì)request中的設(shè)備id，檢查是否可用，并將使用這幾個(gè)設(shè)備需要的使用參數(shù)返回給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
}

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

kubelet要?jiǎng)?chuàng)建pod的容器時(shí)，會(huì)調(diào)用到GenerateRunContainerOptions方法，用于生成容器runtime要的參數(shù)，該方法中會(huì)首先調(diào)用：

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

而containerManager中GetResources會(huì)調(diào)用devicePluginManager中的GetDeviceRunContainerOptions方法，最后執(zhí)行deviceRunContainerOptions方法，從podDevices中獲取這個(gè)pod相應(yīng)的容器需要使用的設(shè)備，并組織成容器運(yùn)行時(shí)參數(shù)的對(duì)象opts，最終run container時(shí)會(huì)被用到。比如gpu容器，會(huì)在opts中增加devices參數(shù)的指定，最后容器創(chuàng)建時(shí)會(huì)帶有需要的設(shè)備。

部署device-plugin插件最佳的方法是使用k8s的daemonset，因?yàn)閐aemonset可以在插件失敗是重新啟動(dòng)之，且會(huì)自動(dòng)分布到滿足條件的所有node節(jié)點(diǎn)上。

社區(qū)參考文檔
https://kubernetes.io/docs/ta...