调度器工程：如何开发一个调度器

基于k8s的调度器开发

GPU集群管理相关的开源项目

k8s扩展调度的方式:(1)scheduler-extender （2）scheduler-framework

传统的scheduler-extender的缺陷：

• 扩展点数量的限制：仅支持 “Predicate”、“Priority”、“Bind” 三个扩展点。即可以在这三个阶段进行扩展，但扩展的功能只能在默认的功能之后被调用。例如当增加了新的 “Predicate” 功能后，开发者只能在默认所有预选函数执行完成之后才能调用它，不能够在这之前进行调用；
• 效率低下：调度器通过 JSON 的数据格式与扩展通信，比调用原生函数要慢得多；
• 调度器也无法通知 Extender Pod 已经取消调度；
• Extender 是单独的进程，无法使用默认调度器的缓存，需要自建一个和默认调度器一样的缓存。

scheduler-framework:在原有的调度流程基础之上提供了多种丰富的扩展点接口，不需要进行HTTP进行通信，本身就是一个“默认调度器”+“扩展点”编译在一个二进制文件里。
之所以叫framework就是不用开发者去手动实现一个调度器了，只需要根据自己的需求添加扩展点即可。

framework的扩展点具体具体包括：

1）Sort

2）PreFilter
PreFilter 在 scheduling cycle 开始时就被调用，只有当所有的 PreFilter 插件都返回 success 时，才能进入下一个阶段，否则 Pod 将会被拒绝掉，标识此次调度流程失败。PreFilter 类似于调度流程启动之前的预处理，可以对 Pod 的信息进行加工。同时 PreFilter 也可以进行一些预置条件的检查，去检查一些集群维度的条件，判断否满足 pod 的要求。

3）Filter
Filter 插件是 scheduler v1 版本中的 Predicate 的逻辑，用来过滤掉不满足 Pod 调度要求的节点。为了提升效率，Filter 的执行顺序可以被配置，这样用户就可以将可以过滤掉大量节点的 Filter 策略放到前边执行，从而减少后边 Filter 策略执行的次数，例如我们可以把 NodeSelector 的 Filter 放到第一个，从而过滤掉大量的节点。Node 节点执行 Filter 策略是并发执行的，所以在同一调度周期中多次调用过滤器。

4）PostFilter
新的 PostFilter 的接口定义在 1.19 的版本会发布，主要是用于处理当 Pod 在 Filter 阶段失败后的操作，例如抢占，Autoscale 触发等行为。

5）PreScore
PreScore 在之前版本称为 PostFilter，现在修改为 PreScore，主要用于在 Score 之前进行一些信息生成。此处会获取到通过 Filter 阶段的节点列表，我们也可以在此处进行一些信息预处理或者生成一些日志或者监控信息。

6）Scoring
Scoring 扩展点是 scheduler v1 版本中 Priority 的逻辑，目的是为了基于 Filter 过滤后的剩余节点，根据 Scoring 扩展点定义的策略挑选出最优的节点。Scoring 扩展点分为两个阶段：

打分：打分阶段会对 Filter 后的节点进行打分，scheduler 会调用所配置的打分策略
归一化: 对打分之后的结构在 0-100 之间进行归一化处理
7）Reserve
Reserve 扩展点是 scheduler v1 版本的 assume 的操作，此处会对调度结果进行缓存，如果在后边的阶段发生了错误或者失败的情况，会直接进入 Unreserve 阶段，进行数据回滚。

8）Permit
Permit 扩展点是 framework v2 版本引入的新功能（延迟调度），当 Pod 在 Reserve 阶段完成资源预留之后，Bind 操作之前，开发者可以定义自己的策略在 Permit 节点进行拦截，根据条件对经过此阶段的 Pod 进行 allow、reject 和 wait 的 3 种操作。allow 表示 pod 允许通过 Permit 阶段。reject 表示 pod 被 Permit 阶段拒绝，则 Pod 调度失败。wait 表示将 Pod 处于等待状态，开发者可以设置超时时间。
通过Permit可以实现gangscheduler。具体可查看博客