k8s的扩展资源设计和device-plugin

extended-resources

extended-resources在k8s1.9中是一个stable的特性。能够用一句话来归纳这个特性：

经过向apiserver发送一个patch node 的请求，为这个node增长一个自定义的资源类型，用于以该资源的配额统计和相应的QoS的配置。

patch node 的请求：

举例：

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/<your-node-name>/status

QoS配置：

若是对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将没法成功调度。

device-plugin插件

设备插件从1.8版本开始加入，到1.9目前还是alpha特性，设备插件的做用是在不更改k8s代码的状况下，向k8s提供各类资源的统计信息和使用预备工做。这里说的资源如GPU、高性能NIC、FPGA、infiniBand或其余。

device-plugin的注册和实施

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。该方法会一直循环检查，一旦设备异常或者从机器上拔出，会将最新的设备列表返回给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...）

device-plugin 使用的代码解析

咱们从建立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的部署

部署device-plugin插件最佳的方法是使用k8s的daemonset，由于daemonset能够在插件失败是从新启动之，且会自动分布到知足条件的全部node节点上。

社区参考文档
https://kubernetes.io/docs/ta...