怎么進(jìn)行Kubernetes集群調(diào)度器原理剖析及思考

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

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

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

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

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

注明：本文中代碼基于v1.11版本Kubernetes進(jìn)行分析，如有不當(dāng)之處，歡迎指正！

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

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

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

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

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

1.2 調(diào)度器的考量標(biāo)準(zhǔn)

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

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

了解不同類型的資源拓?fù)洌浞终莆窄h(huán)境拓?fù)湫畔⒛軌蚴拐{(diào)度工作更充分的利用資源（如經(jīng)常訪問(wèn)數(shù)據(jù)的任務(wù)如果距數(shù)據(jù)近可以顯著減少執(zhí)行時(shí)間），并且可以基于資源拓?fù)湫畔⒍x更加復(fù)雜的策略。但全局資源信息的維護(hù)消耗會(huì)限制集群的整體規(guī)模和調(diào)度執(zhí)行時(shí)間，這也讓調(diào)度器難以擴(kuò)展，從而限制集群規(guī)模。

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

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

資源使用率最大化

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

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

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

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

充分考慮各種層級(jí)的公平性

1.3 鎖對(duì)調(diào)度器設(shè)計(jì)的影響

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

我們首先通過(guò)一個(gè)簡(jiǎn)單的例子，比較下悲觀鎖和樂(lè)觀鎖處理邏輯的不同，假設(shè)有如下的一個(gè)場(chǎng)景：

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

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

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

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

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

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

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

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

Kubernetes調(diào)度器剖析

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

2.1 Kubernetes調(diào)度器的設(shè)計(jì)

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

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

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

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

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

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

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

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

（1）基于事件驅(qū)動(dòng)啟動(dòng)循環(huán)過(guò)程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖2：?jiǎn)蝹€(gè)Pod的調(diào)度過(guò)程

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

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

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

(2)經(jīng)過(guò)預(yù)選策略對(duì)節(jié)點(diǎn)過(guò)濾后，進(jìn)入優(yōu)選階段

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

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

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

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

LeastRequestedPriority：由節(jié)點(diǎn)空閑資源與節(jié)點(diǎn)總?cè)萘康谋戎?，即由（總?cè)萘?節(jié)點(diǎn)上Pod的容量總和-新Pod的容量）/總?cè)萘浚﹣?lái)決定節(jié)點(diǎn)的優(yōu)先級(jí)。CPU和memory具有相同權(quán)重，比值越大的節(jié)點(diǎn)得分越高。

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

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

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

TaintTolerationPriority : 使用 Pod 中 tolerationList 與 節(jié)點(diǎn) Taint 進(jìn)行匹配，配對(duì)成功的項(xiàng)越多，則得分越低。

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

3.1典型的幾個(gè)問(wèn)題和解決思路

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

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

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

（2）調(diào)度以單個(gè)pod進(jìn)行的，因而調(diào)度互相關(guān)聯(lián)的工作負(fù)載會(huì)難以實(shí)現(xiàn)

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

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

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

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

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

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

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

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

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

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

企業(yè)場(chǎng)景應(yīng)用的案例

4.1 通用計(jì)算場(chǎng)景

Kubernetes default-scheduler滿足通用計(jì)算的需求，主要服務(wù)于以快速開(kāi)發(fā)測(cè)試為目標(biāo)的持續(xù)集成和持續(xù)部署平臺(tái)（DevOps平臺(tái)）、以標(biāo)準(zhǔn)三層架構(gòu)應(yīng)用為特點(diǎn)的容器應(yīng)用運(yùn)行與運(yùn)維平臺(tái)（容器平臺(tái)）、PaaS平臺(tái)和云原生應(yīng)用的核心基礎(chǔ)架構(gòu)平臺(tái)（aPaaS平臺(tái)）幾種場(chǎng)景。

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

4.2 批處理場(chǎng)景

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

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

4.3 特定領(lǐng)域業(yè)務(wù)場(chǎng)景

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

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

主要從設(shè)計(jì)原理、代碼實(shí)現(xiàn)等層面介紹Kubernetes的調(diào)度器以及社區(qū)對(duì)其的補(bǔ)充加強(qiáng)，總結(jié)了Kubernetes調(diào)度器的設(shè)計(jì)原理以及在何種場(chǎng)景如何增強(qiáng)Kubernetes來(lái)滿足業(yè)務(wù)需求，提供技術(shù)選型的依據(jù)和評(píng)價(jià)標(biāo)準(zhǔn)。

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

分享標(biāo)題：怎么進(jìn)行Kubernetes集群調(diào)度器原理剖析及思考
當(dāng)前路徑：http://muchs.cn/article34/gphdpe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供移動(dòng)網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)公司、微信小程序、面包屑導(dǎo)航、服務(wù)器托管

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)