法 1：通过配置（无代码）
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler# ...
- schedulerName: batch-schedulerplugins:score:enabled:- name: NodeResourcesFitweight: 3disabled:- name: ImageLocality- name: NodeResourcesBalancedAllocation
通过修改这么个东西，启用或禁用插件，
优点：不用编写代码；升级轻松。
缺点：能力范围受限于内置插件和参数的能力范围。
注意：早先的 Scheduling Policy 已经没了。
法 2：Scheduling Framework
kube-scheduler 的代码形状就是一个框架，不修改，编译出来就是原版。
在扩展点（类似于回调函数的调用位置）实现插件（类似于回调函数），即可编译出自己的版本。
优点：自由度高，生态中有一些可以开箱即用的东西。
缺点：升级 k8s 版本时要进行重新编译并回归测试。
法 3：Scheduler Extender
kube-scheduler 可以配置 extenders，把 Filter、Score、Bind 等阶段外包给一个 HTTP server。
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
extenders:
- urlPrefix: "http://127.0.0.1:12345/api/scheduler"# ...
优点：不限制技术栈，接入容易。
缺点：跨进程有延时和性能开销。可以控制的阶段受限。
注意：k8s 官方已经不怎么推荐这种方式，而推荐 Scheduling Framework 方式。
法 4：完全自己搞
使用 k8s 客户端 watch 那些 spec.schedulerName 为预设值的 Pod。
优点：自由度极高，想做什么就做什么。
缺点：什么都要自己干（排队、抢占、亲和性、拓扑感知等等）。而且要注意和别默认的调度器冲突。容易和其他组件的演进脱节。
适用范围：实验性调度系统。或者与 k8s 有很大不同的调度方式。
法 5：引入其他调度器
如 Kueue、Volcano、YuniKorn、Koordinator。
法 6：组合方式
运行多个调度器，按照 spec.schedulerName 进行分工。每个调度器再按照 spec.schedulerName 分配自己管理的多个 profile 中的某个。
优点：不同特点的负载分别调度。
缺点：运维复杂。要当心，别让多个调度器打架。