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

shiweifu 发布于2019-07-01 16:39 / 2739人阅读

摘要：如果上的资源耗尽，这类将无法成功调度。将这个资源及其对应的设备个数记录到更新到。

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//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...

云服务器专线服务 etcd存储k8s资源对象设计扩展性能软件机智云服务器的设计和使用 k8s 和 docker

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/32628.html

Kubernetes的Device Plugin设计解读

摘要：摘要的生态地位已经确立，可扩展性将是其发力的主战场。该功能由于只是替代了做了些更名的工作，所以在已经是稳定的状态了。异构计算作为非常重要的新战场，非常重视。而异构计算需要强大的计算力和高性能网络，需要提供一种统一的方式与等高性能硬件集成。摘要： Kubernetes的生态地位已经确立，可扩展性将是其发力的主战场。异构计算作为非常重要的新战场，Kubernetes非常重视。而异构计算需...

bladefury 2019-06-28 10:55 评论0 收藏0
Kubernetes的Device Plugin设计解读

摘要：摘要的生态地位已经确立，可扩展性将是其发力的主战场。该功能由于只是替代了做了些更名的工作，所以在已经是稳定的状态了。异构计算作为非常重要的新战场，非常重视。而异构计算需要强大的计算力和高性能网络，需要提供一种统一的方式与等高性能硬件集成。摘要： Kubernetes的生态地位已经确立，可扩展性将是其发力的主战场。异构计算作为非常重要的新战场，Kubernetes非常重视。而异构计算需...

cheukyin 2019-05-28 18:40 评论0 收藏0
【附PPT下载】UCan技术开放日·上海站活动回顾

摘要：徐亮厚称，当前云原生已成为业务发展的一个重要引擎，年疫情更是加大了对的需求，拉动了大数据数据库中间件人工智能的云原生化发展。未来英特尔将与一起，共同利用并发挥云原生的价值，为处在数字化型中的用户，提供更加丰富的云化策略。 9月11日，由UCloud优刻得主办的UCan技术开放日活动上，以构建云原生，拥抱新增长为主题，UCloud携手达达集团、驭势科技、企源科技以及英特尔等企业的云原生技术专...

levy9527 2021-09-24 13:52 评论0 收藏0
UCan技术开放日（上海站）——云原生在多行业场景的落地实践

摘要：技术开放日云原生在多行业场景的落地实践当前，云计算已成为万千企业数字化转型的基石，随之而来的是对云计算应用效能的更高要求。UCloud UCan技术开放日——云原生在多行业场景的落地实践当前，云计算已成为万千企业数字化转型的基石，随之而来的是对云计算应用效能的更高要求。敏捷开发、弹性架构、多集群运维等，让企业现有IT架构面临新的挑战。云原生以其独特的技术特点，很好地契合了云计算发展的本质需求...

Tecode 2022-06-28 19:00 评论0 收藏0
为什么 kubernetes 天然适合微服务（3）

摘要：此文已由作者刘超授权网易云社区发布。五更加适合微服务和的设计好了，说了本身，接下来说说的理念设计，为什么这么适合微服务。相关阅读为什么天然适合微服务为什么天然适合微服务为什么天然适合微服务文章来源网易云社区此文已由作者刘超授权网易云社区发布。欢迎访问网易云社区，了解更多网易技术产品运营经验四、Kubernetes 本身就是微服务架构基于上面这十个设计要点，我们再回来看 Kube...

nicercode 2019-06-28 11:02 评论0 收藏0