kubernetes的kube-scheduler性能將提升40%

高性能的調度器是一個雲平台成功的重要因素之一。在美團雲，我們學習Kubernetes的調度思想，實現自己的調度器。去年10月，我加入美團雲開始著手優化舊版的調度系統，除了在架構上的優化外，我也不斷在思考著如何優化目前調度的流程，kube-scheduler的調度流程有何問題，還有哪些可優化的地方？

一方面我們從調度器的Python實現重構為Go的實現，並增加了一系列的架構優化工作，性能提升了近2個數量級，達到在約30000個節點的集群下每次調度的平均時間低於100ms。這裡不是本文的重點，在此略過。

另一方面我們來看看在調度流程上的優化，該優化簡單的說是預選階段的中斷機制，我們首先說下調度流程，在此以kubernetes為例子。

我們知道，調度服務是Kubernetes容器集群管理系統中載入並運行的調度程序，負責收集、統計分析容器集群管理系統中所有Node的資源使用情況，然後以此為依據將新建的Pod發送到優先順序最高的可用Node上去建立。

調度分為幾個部分：

• 首先是預選過程，過濾掉不滿足條件的節點，這個過程稱為Predicates
• 然後是優選過程，對通過的節點按照優先順序排序，稱之為Priorities
• 最後是選定過程，從中選擇優先順序最高的節點，稱為Select

我所做的優化就在這裡預選階段這裡，預選階段可以認為是過濾的功能，即遍歷全部節點，過濾掉不滿足條件的節點，可能會有多個過條件和過濾項，這一階段輸出的所有滿足要求的Node都將被記錄並作為第二階段優選過程的輸入。

目前在預選階段即使遇到候選Node不符合某項條件，還是繼續判斷後面的條件是否符合，但其實對於調度過程來說這部分的計算並不重要，唯一的用途就是可以將目前所有Node的不符合的條件全部記錄下來，但這些數據真的很重要嗎？尤其是在已經對所有的Predicates排序了的情況下。

這些計算耗時隨著條件的增多線性的增長，通過條件失敗中斷機制在我們目前大約十個條件的情況下性能可以提升40%，每次調度在52ms，甚至更低。

在真實環境中驗證之後，我將該優化提交到了Kubernetes官方，優化PR，該優化將隨著kubernetes 1.10一起發布！並作為默認設置。大家可以通過策略配置文件的alwaysCheckAllPredicates選項選擇false來體驗變化。

同行們有興趣可以在自己的集群下試試是否有提高！