網上關于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（性能要求高，只想實現自己判斷邏輯其他都不想做的）方式即可