网上关于scheduler扩展介绍的文章很多，但都是东说一句西说一嘴，完全没有逻辑性，对于逻辑建构者看着很痛苦，这篇文章不会深入教你怎么扩展，而是教你几种扩展方式的关系和逻辑结构：
目前Kubernetes支持五种方式实现客户自定义的调度算法，如下：
-
default-scheduler recoding: 直接在Kubernetes默认scheduler基础上进行添加，然后重新编译kube-scheduler，修改地方在scheduler-core核心代码，需要遵守扩展规则；
-
standalone: 实现一个与kube-scheduler平行的custom scheduler，相当于你自己fork了一份，深度定制，不遵守扩展点什么的规矩，自己魔改
-
scheduler extender: webhook的方式，kube-scheduler会调用它(http/https)作为默认调度算法的补充，在调度的每个可以hook的阶段调用对应的extender，本质上就是一个http服务，用python或者java写都可以，但是需要自己去拿各种cache并维护，且http方式io时间代价很高
-
scheduler framework: scheduler暴露出标准化的interface规范，你只需要按照interface写你自己的实现，重新编译kube-scheduler，类似于第一种方案，但是更加标准化，不会修改scheduler-core核心代码（说人话就是一个是实现接口即可修改无侵入，一个需要修改人家代码有侵入）
-
scheduler-plugins：社区维护的一套基于scheduler framework的封装层次更高的一个项目，你只需要实现自己的判断逻辑，其他的（node信息，pod信息，处理返回结果）你都不用关心，只要关心自己打分逻辑即可
一般不需要深度定制的，选择scheduler extender（性能要求不高且愿意自己维护cache的）和scheduler-plugins（性能要求高，只想实现自己判断逻辑其他都不想做的）方式即可
