基于scheduler framework调度插件开发踩过的坑

1. 关于调度器插件调用顺序问题：

• 如果某个扩展点没有配置对应的扩展，调度框架将使用默认插件中的扩展
• 如果为某个扩展点配置且激活了扩展，则调度框架将先调用默认插件的扩展，再调用配置中的扩展
• 默认插件的扩展始终被最先调用，然后按照 KubeSchedulerConfiguration 中扩展的激活 enabled 顺序逐个调用扩展点的扩展
• 可以先禁用默认插件的扩展，然后在 enabled 列表中的某个位置激活默认插件的扩展，这种做法可以改变默认插件的扩展被调用时的顺

2.调度插件名称重复不会报错，可能会交叉执行调度

3.KubeSchedulerConfiguration配置格式有问题调度器还是会起来，但是初始化有报错

4.bind至少保留一个

 5.通过静态pod方式创建kube-scheduler需要注意权限问题

scheduler扩展方案对比

• default-scheduler recoding: 直接在Kubernetes默认scheduler基础上进行添加，然后重新编译kube-scheduler
• standalone: 实现一个与kube-scheduler平行的custom scheduler，单独或者和默认kube-scheduler一起运行在集群中
• scheduler extender: 实现一个”scheduler extender”，kube-scheduler会调用它(http/https)作为默认调度算法(预选&优选&bind)的补充
• scheduler framework: 实现scheduler framework plugins，重新编译kube-scheduler，类似于第一种方案，但是更加标准化，插件化