如何详细解析 HAMi vGPU 中 hami-scheduler 的工作流程机制？

上篇我们分析了 hami-webhook，该 Webhook 将申请了 vGPU 资源的 Pod 的调度器修改为 hami-scheduler，后续使用 hami-scheduler 进行调度。 本文为 HAMi 原理分析的第三篇，分析 hami-scheduler 工作流程。 上篇主要分析了 hami-webhook，解决了：Pod 是如何使用到 hami-scheduler，创建 Pod 时我们未指定 SchedulerName 默认会使用 default-scheduler 进行调度才对 问题。 这篇开始分析 hami-scheduler，解决另一个问题：hami-scheduler 逻辑，spread & binpark 等 高级调度策略是如何实现的 写完发现内容还是很多，spread & binpark 调度策略下一篇在分析吧，这篇主要分析调度流程。 以下分析基于 HAMi v2.4.0 省流： HAMi Webhook 、Scheduler 工作流程如下： 1）用户创建 Pod 并在 Pod 中申请了 vGPU 资源 2）kube-apiserver 根据 MutatingWebhookConfiguration 配置请求 HAMi-Webhook 3）HAMi-Webhook 检测 Pod 中的 Resource，如果申请的由 HAMi 管理的 vGPU 资源，就会把 Pod 中的 SchedulerName 改成了 hami-scheduler，这样这个 Pod 就会由 hami-scheduler 进行调度了。 对于特权模式的 Pod，Webhook 会直接跳过不处理 对于使用 vGPU 资源但指定了 nodeName 的 Pod，Webhook 会直接拒绝 4）hami-scheduler 进行 Pod 调度，不过就是用的 k8s 的默认 kube-scheduler 镜像，因此调度逻辑和默认的 default-scheduler 是一样的，但是 kube-scheduler 还会根据 KubeSchedulerConfiguration 配置，调用 Extender Scheduler 插件 这个 Extender Scheduler 就是 hami-scheduler Pod 中的另一个 Container，该 Container 同时提供了 Webhook 和 Scheduler 相关 API。 当 Pod 申请了 vGPU 资源时，kube-scheduler 就会根据配置以 HTTP 形式调用 Extender Scheduler 插件，这样就实现了自定义调度逻辑 5）Extender Scheduler 插件包含了真正的 hami 调度逻辑， 调度时根据节点剩余资源量进行打分选择节点 这里就包含了 spread & binpark 等 高级调度策略的实现 6）异步任务，包括 GPU 感知逻辑 devicePlugin 中的后台 Goroutine 定时上报 Node 上的 GPU 资源并写入到 Node 的 Annoations 除了 DevicePlugin 之外，还使用异步任务以 Patch Annotation 方式提交更多信息 Extender Scheduler 插件根据 Node Annoations 解析出 GPU 资源总量、从 Node 上已经运行的 Pod 的 Annoations 中解析出 GPU 使用量，计算出每个 Node 剩余的可用资源保存到内存供调度时使用 1. 概述 Hami-scheduler 主要是 Pod 的调度逻辑，从集群节点中为当前 Pod 选择最合适的节点。 Hami-scheduler 也是通过 Scheduler Extender 方式实现的，可以参考上一篇文章 K8s 自定义调度器 Part1：通过 Scheduler Extender 实现自定义调度逻辑 手把手实现一个自定义调度器。 但是 HAMi 并没有直接扩展 default-scheduler，而是使用默认的 kube-scheduler 镜像额外启动了一个 scheduler,但是通过配置把名称指定为了 hami-scheduler。 然后给这个 hami-scheduler 配置了 Extender，Extender 服务就是同 Pod 中的另一个 Container 启动的一个 http 服务。