這篇文章將為大家詳細講解有關怎么進行Kubernetes集群調(diào)度器原理剖析及思考，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

為鹽田等地區(qū)用戶提供了全套網(wǎng)頁設計制作服務，及鹽田網(wǎng)站建設行業(yè)解決方案。主營業(yè)務為網(wǎng)站設計制作、成都網(wǎng)站制作、鹽田網(wǎng)站設計，以傳統(tǒng)方式定制建設網(wǎng)站，并提供域名空間備案等一條龍服務，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

云環(huán)境或者計算倉庫級別（將整個數(shù)據(jù)中心當做單個計算池）的集群管理系統(tǒng)通常會定義出工作負載的規(guī)范，并使用調(diào)度器將工作負載放置到集群恰當?shù)奈恢?。好的調(diào)度器可以讓集群的工作處理更高效，同時提高資源利用率，節(jié)省能源開銷。

通用調(diào)度器，如Kubernetes原生調(diào)度器Scheduler實現(xiàn)了根據(jù)特定的調(diào)度算法和策略將pod調(diào)度到指定的計算節(jié)點（Node）上。但實際上設計大規(guī)模共享集群的調(diào)度器并不是一件容易的事情。調(diào)度器不僅要了解集群資源的使用和分布情況，還要兼顧任務分配速度和執(zhí)行效率。過度設計的調(diào)度器屏蔽了太多的技術實現(xiàn)，以至于無法按照預期完成調(diào)度任務，或導致異常情況的發(fā)生，不恰當?shù)恼{(diào)度器的選擇同樣會降低工作效率，或導致調(diào)度任務無法完成。

本文主要從設計原理、代碼實現(xiàn)兩個層面介紹Kubernetes的調(diào)度器以及社區(qū)對其的補充加強，同時對業(yè)界常用調(diào)度器的設計實現(xiàn)進行比較分析。通過本文，讀者可了解調(diào)度器的來龍去脈，從而為選擇甚至設計實現(xiàn)適合實際場景的調(diào)度器打下基礎。

注明：本文中代碼基于v1.11版本Kubernetes進行分析，如有不當之處，歡迎指正！

調(diào)度器的基本知識

1.1 調(diào)度器的定義

通用調(diào)度的定義是指基于某種方法將某項任務分配到特定資源以完成相關工作，其中任務可以是虛擬計算元素，如線程、進程或數(shù)據(jù)流，特定資源一般是指處理器、網(wǎng)絡、磁盤等，調(diào)度器則是完成這些調(diào)度行為的具體實現(xiàn)。使用調(diào)度器的目的是實現(xiàn)用戶共享系統(tǒng)資源的同時，降低等待時間，提高吞吐率以及資源利用率。

本文中我們討論的調(diào)度器是指大規(guī)模集群下調(diào)度任務的實現(xiàn)，比較典型的有Mesos/Yarn(Apache)、Borg/Omega(Google)、Quincy(Microsoft)等。構建大規(guī)模集群（如數(shù)據(jù)中心規(guī)模）的成本非常之高，因此精心設計調(diào)度器就顯得尤為重要。

常見類型的調(diào)度器的對比分析如下表1所示：

1.2 調(diào)度器的考量標準

我們首先思考一下調(diào)度器是根據(jù)哪些信息來進行調(diào)度工作的，以及哪些指標可以用來衡量調(diào)度工作質(zhì)量。

調(diào)度器的主要工作是將資源需求與資源提供方做全局最優(yōu)的匹配。所以一方面調(diào)度器的設計需要了解不同類型的資源拓撲，另一方面還需要對工作負載有充分的認識。

了解不同類型的資源拓撲，充分掌握環(huán)境拓撲信息能夠使調(diào)度工作更充分的利用資源（如經(jīng)常訪問數(shù)據(jù)的任務如果距數(shù)據(jù)近可以顯著減少執(zhí)行時間），并且可以基于資源拓撲信息定義更加復雜的策略。但全局資源信息的維護消耗會限制集群的整體規(guī)模和調(diào)度執(zhí)行時間，這也讓調(diào)度器難以擴展，從而限制集群規(guī)模。

另一方面，由于不同類型的工作負載會有不同的甚至截然相反的特性，調(diào)度器還需要對工作負載有充分的認識，例如服務類任務，資源需求少，運行時間長，對調(diào)度時間并不敏感；而批處理類任務，資源需求大，運行時間短，任務可能相關，對調(diào)度時間要求較高。 同時，調(diào)度器也要滿足使用方的特殊要求。如任務盡量集中或者分散，保證多個任務同時進行等。

總的來說，好的調(diào)度器需要平衡好單次調(diào)度（調(diào)度時間，質(zhì)量），同時要考慮到環(huán)境變化對調(diào)度結果的影響，保持結果最優(yōu)（必要時重新調(diào)度），保證集群規(guī)模，同時還要能夠支持用戶無感知的升級和擴展。調(diào)度的結果需要滿足但不限于下列條件，并最大可能滿足盡可能優(yōu)先級較高的條件：

資源使用率最大化

滿足用戶指定的調(diào)度需求

滿足自定義優(yōu)先級要求

調(diào)度效率高，能夠根據(jù)資源情況快速做出決策

能夠根據(jù)負載的變化調(diào)整調(diào)度策略

充分考慮各種層級的公平性

1.3 鎖對調(diào)度器設計的影響

對于資源的調(diào)度，一定會涉及到鎖的應用，不同類型鎖的選擇將直接決定調(diào)度器的使用場景。類似Mesos等兩層調(diào)度器，一般采用悲觀鎖的設計實現(xiàn)方式，當資源全部滿足任務需要時啟動任務，否則將增量繼續(xù)申請更多的資源直到調(diào)度條件滿足；而共享狀態(tài)的調(diào)度器，會考慮使用樂觀鎖的實現(xiàn)方式，Kubernetes默認調(diào)度器是基于樂觀鎖進行設計的。

我們首先通過一個簡單的例子，比較下悲觀鎖和樂觀鎖處理邏輯的不同，假設有如下的一個場景：

作業(yè)A讀取對象O

作業(yè)B讀取對象O

作業(yè)A在內(nèi)存中更新對象O

作業(yè)B在內(nèi)存中更新對象O

作業(yè)A寫入對象O實現(xiàn)持久化

作業(yè)B寫入對象O實現(xiàn)持久化

悲觀鎖的設計是對對象O實現(xiàn)獨占鎖，直到作業(yè)A完成對對象O的更新并寫入持久化數(shù)據(jù)之前，阻斷其他讀取請求。樂觀鎖的設計是對對象O實現(xiàn)共享鎖，假設所有的工作都能夠正常完成，直到有沖突產(chǎn)生，記錄沖突的發(fā)生并拒絕沖突的請求。

樂觀鎖一般會結合資源版本實現(xiàn)，同樣是上述中的例子，當前對象O的版本為v1，作業(yè)A首先完成對對象O的寫入持久化操作，并標記對象O的版本為v2，作業(yè)B在更新時發(fā)現(xiàn)對象版本已經(jīng)變化，則會取消更改。

Kubernetes調(diào)度器剖析

Kubernetes中的計算任務大多通過pod來承載運行。pod是用戶定義的一個或多個共享存儲、網(wǎng)絡和命名空間資源的容器的組合，是調(diào)度器可調(diào)度的最小單元。Kubernetes的調(diào)度器是控制平面的一部分，它主要監(jiān)聽APIServer提供的pod任務列表，獲取待調(diào)度pod，根據(jù)預選和優(yōu)選策略，為這些pod分配運行的節(jié)點。概括來說，調(diào)度器主要依據(jù)資源消耗的描述得到一個調(diào)度結果。

2.1 Kubernetes調(diào)度器的設計

Kubernetes的調(diào)度設計參考了Omega的實現(xiàn)，主要采用兩層調(diào)度架構，基于全局狀態(tài)進行調(diào)度，通過樂觀鎖控制資源歸屬，同時支持多調(diào)度器的設計。

兩層架構幫助調(diào)度器屏蔽了很多底層實現(xiàn)細節(jié)，將策略和限制分別實現(xiàn)，同時過濾可用資源，讓調(diào)度器能夠更靈活適應資源變化，滿足用戶個性化的調(diào)度需求。相比單體架構而言，不僅更容易添加自定義規(guī)則、支持集群動態(tài)伸縮，同時對大規(guī)模集群有更好的支持（支持多調(diào)度器）。

相比于使用悲觀鎖和部分環(huán)境視圖的架構（如Mesos），基于全局狀態(tài)和樂觀鎖實現(xiàn)的好處是調(diào)度器可以看到集群所有可以支配的資源，然后搶占低優(yōu)先級任務的資源，以達到策略要求的狀態(tài)。它的資源分配更符合策略要求，避免了作業(yè)囤積資源導致集群死鎖的問題。當然這會有搶占任務的開銷以及沖突導致的重試，但總體來看資源的使用率更高了。

Kubernetes中默認只有一個調(diào)度器，而Omega的設計本身支持資源分配管理器共享資源環(huán)境信息給多個調(diào)度器。所以從設計上來說，Kubernetes可以支持多個調(diào)度器。

2.2 Kubernetes調(diào)度器的實現(xiàn)

Kubernetes調(diào)度器的工作流程如下圖所示。調(diào)度器的工作本質(zhì)是通過監(jiān)聽pod的創(chuàng)建、更新、刪除等事件，循環(huán)遍歷地完成每個pod的調(diào)度流程。如調(diào)度過程順利，則基于預選和優(yōu)選策略，完成pod和主機節(jié)點的綁定，最終通知kubelet完成pod啟動的過程。如遇到錯誤的調(diào)度過程，通過優(yōu)先級搶占的方式，獲取優(yōu)先調(diào)度的能力，進而重新進入調(diào)度循環(huán)的過程，等待成功調(diào)度。

2.2.1 調(diào)度循環(huán)的完整邏輯

Kubernetes調(diào)度器完成調(diào)度的整體流程如下圖1所示。下面就每個步驟的實現(xiàn)邏輯進行說明。

（1）基于事件驅動啟動循環(huán)過程

Kubernetes調(diào)度器維護sharedIndexInformer，來完成informer對象的初始化工作。也就是調(diào)度器會監(jiān)聽pod創(chuàng)建、更新、刪除的操作事件，主動更新事件緩存，并持久化到內(nèi)存隊列，發(fā)起調(diào)度循環(huán)。

該過程的函數(shù)入口在

https://github.com/kubernetes/kubernetes/blob/9cbccd38598e5e2750d39e183aef21a749275087/pkg/scheduler/factory/factory.go#L631

（2）將沒有調(diào)度的pod加到調(diào)度器緩存并更新調(diào)度器隊列

Informer對象負責監(jiān)聽pod的事件，主要的事件類型有：針對已調(diào)度pod的addPodToCache、updatePodInCache、deletePodFromCache和針對未被調(diào)度pod的addPodToSchedulingQueue、updatePodInSchedulingQueue、deletePodFromSchedulingQueue六種事件。該過程的函數(shù)入口在：

https://github.com/kubernetes/kubernetes/blob/9cbccd38598e5e2750d39e183aef21a749275087/pkg/scheduler/eventhandlers.go

各類事件的含義如下表2所示：

（3）對調(diào)度器隊列中的每個pod執(zhí)行調(diào)度

這里需要指出的是，在單個pod調(diào)度的過程中，對于主機節(jié)點的調(diào)度算法是順序執(zhí)行的。也就是說，pod在調(diào)度的過程中會嚴格的順序執(zhí)行Kubernetes內(nèi)置的策略和優(yōu)先級，然后選擇最合適的節(jié)點。

單個pod的調(diào)度過程分為預選和優(yōu)選兩個階段。預選階段調(diào)度器根據(jù)一組規(guī)則過濾掉不符合要求的主機，選擇出合適的節(jié)點；優(yōu)選階段通過節(jié)點優(yōu)先級打分的方式（依據(jù)整體優(yōu)化策略等），選擇出分值最高的節(jié)點進行調(diào)度。

單個pod的調(diào)度過程由以下函數(shù)作為入口： https://github.com/kubernetes/kubernetes/blob/9cbccd38598e5e2750d39e183aef21a749275087/pkg/scheduler/scheduler.go#L457

當然，調(diào)度的過程可能由于沒有滿足pod運行條件的節(jié)點而調(diào)度失敗，此時當pod有優(yōu)先級指定的時候，將觸發(fā)競爭機制。具有高優(yōu)先級的pod將嘗試搶占低優(yōu)先級的pod資源。相關部分代碼實現(xiàn)如下：

如果資源搶占成功，將在下一次調(diào)度循環(huán)時標記可調(diào)度過程。如果搶占失敗，調(diào)度程序退出。調(diào)度結果不保存意味著pod仍然會出現(xiàn)在未分配列表中。

（4）接下來檢查用戶提供的插件的條件是否滿足

Reserve插件是Kubernets留給用戶進行擴展的接口，基于reserver插件用戶在這個階段可以設定自定義條件，從而滿足期望的調(diào)度過程。插件的入口函數(shù)在： https://github.com/kubernetes/kubernetes/blob/9cbccd38598e5e2750d39e183aef21a749275087/pkg/scheduler/plugins/registrar.go

可以在https://github.com/kubernetes/kubernetes/tree/9cbccd38598e5e2750d39e183aef21a749275087/pkg/scheduler/plugins/examples查看插件擴展reserver接口進行自定義調(diào)度的示例。

（5）找到滿足的節(jié)點后，更新Pod對象的標簽，保存被調(diào)度節(jié)點的結果

該過程的函數(shù)入口在https://github.com/kubernetes/kubernetes/blob/9cbccd38598e5e2750d39e183aef21a749275087/pkg/scheduler/scheduler.go#L517。

（6）完成pod到節(jié)點的綁定

pod到節(jié)點的綁定需要首先完成存儲卷的掛載，最后通過pod對象的更新，完成最后的綁定。具體代碼的邏輯可以參考： https://github.com/kubernetes/kubernetes/blob/9cbccd38598e5e2750d39e183aef21a749275087/pkg/scheduler/scheduler.go#L524 。

（7）調(diào)度完成后，主協(xié)程返回，執(zhí)行下一個調(diào)度

至此調(diào)度的完整流程就完成了，下面重點介紹下，在單個pod調(diào)度過程中Kubernetes主要是如何對節(jié)點進行選擇的，主要包括預選和優(yōu)選兩種策略。

2.2.2 單個pod的調(diào)度流程

單個pod的調(diào)度過程如下圖2所示。主要包括由pre-filter、filter、post-filter的預選過程和scoring的優(yōu)選過程。

圖2：單個Pod的調(diào)度過程

(1)pod進入調(diào)度階段，首先進入預選環(huán)節(jié)

通過規(guī)則過濾找到滿足pod調(diào)度條件的節(jié)點。

k8s內(nèi)置了許多過濾規(guī)則，調(diào)度器會按照事先定義好的順序進行過濾。內(nèi)置的過濾規(guī)則主要包括檢查節(jié)點是否有足夠資源（例如CPU、內(nèi)存與GPU等）滿足pod的運行需求，檢查pod容器所需的HostPort是否已被節(jié)點上其它容器或服務占用，檢查節(jié)點標簽（label）是否匹配pod的nodeSelector屬性要求，根據(jù) taints 和 toleration 的關系判斷pod是否可以調(diào)度到節(jié)點上pod是否滿足節(jié)點容忍的一些條件，還有檢查是否滿足csi最大可掛載卷限制等。

(2)經(jīng)過預選策略對節(jié)點過濾后，進入優(yōu)選階段

調(diào)度器根據(jù)預置的默認規(guī)則進行打分（優(yōu)先級函數(shù)得分*權重的和），然后選擇分數(shù)最高的節(jié)點實現(xiàn)pod到節(jié)點的綁定。

Kubernetes內(nèi)置的優(yōu)先級函數(shù)如下，主要包括平均分布優(yōu)先級（SelectorSpreadPriority）、最少訪問優(yōu)先級（LeastRequestedPriority）、平衡資源分布優(yōu)先級（BalancedResourceAllocation）等。

SelectorSpreadPriority：為了更好的高可用，對同屬于一個service、replication controller或者replica的多個Pod副本，盡量調(diào)度到多個不同的節(jié)點上。

InterPodAffinityPriority：通過迭代 weightedPodAffinityTerm的元素計算和，如果對該節(jié)點滿足相應的PodAffinityTerm，則將 “weight” 加到和中，具有最高和的節(jié)點是最優(yōu)選的。

LeastRequestedPriority：由節(jié)點空閑資源與節(jié)點總容量的比值，即由（總容量-節(jié)點上Pod的容量總和-新Pod的容量）/總容量）來決定節(jié)點的優(yōu)先級。CPU和memory具有相同權重，比值越大的節(jié)點得分越高。

BalancedResourceAllocation：CPU和內(nèi)存使用率越接近的節(jié)點優(yōu)先級越高，該策略不能單獨使用，必須和LeastRequestedPriority同時使用，也就是說盡量選擇在部署Pod后各項資源更均衡的機器。

NodePreferAvoidPodsPriority（權重1w）： 如果節(jié)點的 Anotation 沒有設置 key-value:scheduler. alpha.kubernetes.io/ preferAvoidPods = “…”，則該 節(jié)點對該 policy 的得分就是10分，加上權重10000，那么該節(jié)點對該policy的得分至少10W分。如果節(jié)點的Anotation設置了scheduler.alpha.kubernetes.io/preferAvoidPods = “…” ，如果該 pod 對應的 Controller 是 ReplicationController 或 ReplicaSet，則該節(jié)點對該 policy 的得分就是0分。

NodeAffinityPriority：實現(xiàn)Kubernetes調(diào)度中的親和性機制。

TaintTolerationPriority : 使用 Pod 中 tolerationList 與 節(jié)點 Taint 進行匹配，配對成功的項越多，則得分越低。

Kubernetes調(diào)度器的不足和解決思路

3.1典型的幾個問題和解決思路

（1）調(diào)度器只根據(jù)當前資源環(huán)境情況進行一次調(diào)度，一旦完成調(diào)度就沒有機制實現(xiàn)調(diào)整

雖然pod只有在自己退出、用戶刪除以及集群資源不足等情況下才會有變化。但資源拓撲的變化是隨時都有可能發(fā)生的，如批處理任務會結束，節(jié)點會新增或崩潰。這些情況導致調(diào)度的結果可能在調(diào)度時是最優(yōu)的，但在拓撲變化后調(diào)度質(zhì)量由于以上情況的發(fā)生而下降。

經(jīng)過社區(qū)討論，認為需要重新找出不滿足調(diào)度策略的pod，刪除并創(chuàng)建替代者來重新調(diào)度，據(jù)此設計啟動了項目descheduler。

（2）調(diào)度以單個pod進行的，因而調(diào)度互相關聯(lián)的工作負載會難以實現(xiàn)

如大數(shù)據(jù)分析、機器學習等計算多依賴于批處理任務，這類工作負載相關性大，互相之間有依賴關系。為了解決這個問題，社區(qū)經(jīng)過討論，提出了coscheduling 一次調(diào)度一組pod的項目，以此來優(yōu)化這類調(diào)度任務的執(zhí)行。

（3）目前調(diào)度器的實現(xiàn)只關心是否能將pod與節(jié)點綁定，資源使用情況的數(shù)據(jù)未被充分利用

目前，集群的使用量只能通過監(jiān)控數(shù)據(jù)間接推導。如果k8s集群剩余資源不足時，并沒有直觀數(shù)據(jù)可以用來觸發(fā)擴容或者告警。

根據(jù)上述情況，社區(qū)啟動了cluster-capacity framework項目 ，提供集群的容量數(shù)據(jù)，方便集群的維護程序或者管理員基于這些數(shù)據(jù)做集群擴容等。也有項目抓取監(jiān)控數(shù)據(jù)自己計算集群的整體負載情況給調(diào)度算法參考，如poseidon。

3.2 Kubernetes調(diào)度器的定制擴展

如上節(jié)所述，通用調(diào)度器在某些場景下并不能滿足用戶個性化需求，實際環(huán)境下運行的集群的調(diào)度器，往往需要根據(jù)實際的需求做定制與二次開發(fā)。

kubernetes的調(diào)度器以插件化的形式實現(xiàn)的， 方便用戶對調(diào)度的定制與二次開發(fā)。定制調(diào)度器有如下幾種方式的選擇：

更改Kubernetes內(nèi)置策略，通過更改默認的策略文件或者重新編譯調(diào)度器來實現(xiàn)。

擴展調(diào)度器在pre-filter、filter、post-filter、reserve、prebind、bind和post-bind各個階段的接口，更改調(diào)度器過濾、打分、搶占、預留的具體實現(xiàn)邏輯。

更改調(diào)度器調(diào)度算法，從頭實現(xiàn)調(diào)度器邏輯。

企業(yè)場景應用的案例

4.1 通用計算場景

Kubernetes default-scheduler滿足通用計算的需求，主要服務于以快速開發(fā)測試為目標的持續(xù)集成和持續(xù)部署平臺（DevOps平臺）、以標準三層架構應用為特點的容器應用運行與運維平臺（容器平臺）、PaaS平臺和云原生應用的核心基礎架構平臺（aPaaS平臺）幾種場景。

通常情況下，標準Kubernetes調(diào)度器能夠滿足大多數(shù)通過計算場景的訴求，主要解決應用上云過程中不同異構云資源之間的調(diào)度問題，應用上云后彈性伸縮、故障自愈等的動態(tài)調(diào)度響應，標準中間件服務和數(shù)據(jù)庫服務基于日常運維規(guī)范的調(diào)度問題以及云原生應用在服務治理、配置管理、狀態(tài)反饋、事件鏈路跟蹤上的綜合調(diào)度過程。

4.2 批處理場景

大數(shù)據(jù)分析和機器學習類任務執(zhí)行時需要大量資源，多個任務同時進行時，資源很快會用盡，部分任務會需要等待資源釋放。這類型任務的步驟往往互相關聯(lián)，單獨運行步驟可能會影響最終結果。使用默認的調(diào)度器在集群資源緊張時，甚至會出現(xiàn)占用資源的pod都在等待依賴的pod運行完畢，而集群沒有空閑資源去運行依賴任務，導致死鎖。所以在調(diào)度這類任務時，支持群組調(diào)度（在調(diào)度作業(yè)所需的資源都收集完成后才進行調(diào)度），減少了pod數(shù)量，因而降低調(diào)度器的負載，同時避免了很多資源緊張帶來的問題。

與默認調(diào)度器一次調(diào)度一個pod不同，kube-batch定義了PodGroup 定義一組相關的pod資源，并實現(xiàn)了一個全新的調(diào)度器。調(diào)度器的流程基本與默認調(diào)度器相同。Podgroup保證一組pod可以同時被調(diào)度。是Kubernetes社區(qū)在大數(shù)據(jù)分析場景中的一種實現(xiàn)。

4.3 特定領域業(yè)務場景

特定的業(yè)務場景需要調(diào)度器能夠快速生成調(diào)度的策略，并盡可能避免調(diào)度超時。Poseidon是大規(guī)模集群中基于圖應用數(shù)據(jù)局部性減少任務執(zhí)行時間同時混合多種調(diào)度算法提升調(diào)度速度的一種調(diào)度器。

Poseidon是基于Firmament算法的調(diào)度器，它通過接收heapster數(shù)據(jù)來構建資源使用信息。調(diào)用Firmament實現(xiàn)進行調(diào)度。Firmament算法受Quincy[11]啟發(fā)，構建一個從任務到節(jié)點的圖，但作者為減少調(diào)度時間，將兩種計算最短路徑的算法合并，將全量環(huán)境信息同步改為增量同步。讓Firmament處理短時間批量任務時快于Quincy，在資源短缺時沒有Kubernetes默認調(diào)度器超時的問題。

主要從設計原理、代碼實現(xiàn)等層面介紹Kubernetes的調(diào)度器以及社區(qū)對其的補充加強，總結了Kubernetes調(diào)度器的設計原理以及在何種場景如何增強Kubernetes來滿足業(yè)務需求，提供技術選型的依據(jù)和評價標準。

關于怎么進行Kubernetes集群調(diào)度器原理剖析及思考就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。