### HAMi vGPU 原理分析 Part 4：Spread在HAMi（Hardware Accelerated Multi-Instance）vGPU技术中，Spread是一个关键的概念，它涉及到如何将GPU资源分配给多个虚拟机（VM）。以下是对Sp

上篇我们分析了 hami-scheduler 工作流程，知道了 hami-webhook、hami-scheduler 是怎么配合工作的。 本文为 HAMi 原理分析的第四篇，分析 hami-scheduler 在调度时是如何选择节点的，即：Spread、Binpack 等高级调度策略是怎么实现的。 这篇文章我们解决最后一个问题：Spread、Binpack 等高级调度策略是怎么实现的 以下分析基于 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 调度逻辑， 调度时根据节点剩余资源量进行打分选择节点 6）异步任务，包括 GPU 感知逻辑 devicePlugin 中的后台 Goroutine 定时上报 Node 上的 GPU 资源并写入到 Node 的 Annoations Extender Scheduler 插件根据 Node Annoations 解析出 GPU 资源总量、从 Node 上已经运行的 Pod 的 Annoations 中解析出 GPU 使用量，计算出每个 Node 剩余的可用资源保存到内存供调度时使用 1. 配置调度策略 hami-scheduler 提供了两种不同级别的调度策略： 节点调度策略：作用于调度过程中如何为 Pod 选择节点 GPU 调度策略：作用于选择节点后，节点存在多 GPU 时如何为 Pod 选择 GPU 根据部署文档，我们可以在部署时指定调度策略 scheduler.defaultSchedulerPolicy.nodeSchedulerPolicy: 字符串类型，预设值为"binpack"，表示 GPU 节点调度策略。 "binpack"表示尽量将任务分配到同一个 GPU 节点上 "spread"表示尽量将任务分配到不同 GPU 节点上。 scheduler.defaultSchedulerPolicy.gpuSchedulerPolicy: 字符串类型，预设值为"spread", 表示 GPU 调度策略。 "binpack"表示尽量将任务分配到同一个 GPU 上 "spread"表示尽量将任务分配到不同 GPU 上。