Docker是一個開源的應(yīng)用容器引擎，讓開發(fā)者可以打包應(yīng)用以及依賴包到一個可移植的容器中，然后發(fā)布到Linux機(jī)器上。容器使用沙箱機(jī)制，相互之間不會有任何接口，幾乎沒有性能開銷，可以很容易地在主機(jī)和數(shù)據(jù)中心中運(yùn)行。

　　Kubernetes容器集群管理系統(tǒng)的主要功能包括：使用Docker對應(yīng)用程序進(jìn)行打包、實(shí)例化及運(yùn)行;以集群的方式運(yùn)行及管理跨主機(jī)的容器;解決位于不同主機(jī)之間所運(yùn)行的容器之間的通信問題等等。其中，Scheduler(調(diào)度器)是Kubernetes容器集群管理系統(tǒng)中加載并運(yùn)行的調(diào)度程序，其負(fù)責(zé)收集、統(tǒng)計(jì)分析容器集群管理系統(tǒng)中所有Node的資源使用情況，然后以此為依據(jù)將新建的Pod發(fā)送到優(yōu)先級***的可用Node上去建立。

[[167455]]

　　在新增Pod的過程中，調(diào)度器的調(diào)度策略被分成兩個階段：Predicates階段和Priorities階段。其中，Predicates階段回答“能不能”的問題，即能否將Pod調(diào)度到特定的Node上運(yùn)行，這一階段輸出的所有滿足要求的Node將被記錄并作為第二階段的輸入。Priorities階段是回答“哪個更適合的問題”，即再次對節(jié)點(diǎn)進(jìn)行篩選，篩選出最適合運(yùn)行Pod的節(jié)點(diǎn)。

　　Predicates階段包括五個調(diào)度策略：PodFitsPorts、PodFitsResources、NoDiskConflict、 MatchNodeSelector和HostName，即需要經(jīng)過上述5個Predicates的檢驗(yàn)，才能確定為“能被調(diào)度到的Node”。如其中的 PodFitsPorts規(guī)則，它所評估的依據(jù)就是端口是否沖突，即檢測待調(diào)度的Pod中所有容器要用到的端口集對應(yīng)的HostPort集與Node上已使用的端口是否沖突。而Priorities則是在Predicates的基礎(chǔ)上回答“哪個可用Node***先”的問題。

　　Priorities階段包括三個調(diào)度策略：LeastRequestedPriority(最少請求資源優(yōu)先調(diào)度策略)、 ServiceSpreadingPriority(最小相同服務(wù)優(yōu)先調(diào)度策略)和EqualPriority(平等優(yōu)先調(diào)度策略)。即按照 LeastRequestedPriority、ServiceSpreadingPriority和EqualPriority三個調(diào)度策略，給 Predicates階段篩選出來的所有Node打分，并評出優(yōu)先級，優(yōu)先級***的Node作為Pod被調(diào)度的目的節(jié)點(diǎn)。

　　具體如下： LeastRequestedPriority的計(jì)算原則是盡量將需要新創(chuàng)建的Pod調(diào)度到計(jì)算資源占用比較小的Node上，這里的“計(jì)算資源”指 CPU 資源和Memory資源;ServiceSpreadingPriority的計(jì)算原則是使同一個Node上屬于相同服務(wù)的Pod數(shù)量盡量少，這樣調(diào)度的 Pod能夠盡可能地實(shí)現(xiàn)服務(wù)的高可用性和流量負(fù)載均衡;EqualPriority的計(jì)算原則是平等對待Predicates階段篩選出來的每一個可用 Node。目前，LeastRequestedPriority是最主要的評分依據(jù)。其計(jì)算過程如下：

　　遍歷所有可用Node，對每個可用Node上已經(jīng)調(diào)度運(yùn)行的所有Pod請求所需的Memory資源和CPU資源進(jìn)行求和;

　　對待創(chuàng)建的Pod請求所需的Memory資源和CPU資源進(jìn)行求和，加上S11中得出的對應(yīng)的Memory和CPU的值，并以int64型的整數(shù) totalMemory和int64型的整數(shù)totalMilliCPU進(jìn)行返回;

　　再次遍歷所有可用Node，并計(jì)算每個可用Node的Memory資源和CPU資源的總量，并以int64型的整數(shù)capacityMemory和 int64型的整數(shù)capacityMilliCPU進(jìn)行返回;

　　分別計(jì)算每個可用Node 的CPU得分和Memory得分;其中，CPU得分=int(((capacityMilliCPU - totalMilliCPU) * 10) / capacityMilliCPU);Memory得分= int(((capacityMemory - totalMemory) * 10) / capacityMemory);如果totalMilliCPU的值大于capacityMilliCPU或者totalMemory的值大于 capacityMemory的值，則直接返回CPU得分為0或者M(jìn)emory得分為0。將得分和***的節(jié)點(diǎn)做為Pod的啟動節(jié)點(diǎn)。

　　Kubernetes的調(diào)度器實(shí)現(xiàn)了插件化，用戶可以開發(fā)自己的調(diào)度策略并以插件的形式集成到Kubernetes中，以便調(diào)度不同類型的任務(wù)。然而隨著時間的推移，由于種種因素的影響，如工作節(jié)點(diǎn)上資源變化、其他Pod的創(chuàng)建與刪除，原有已經(jīng)被調(diào)度的Pod可能已經(jīng)不適合調(diào)度策略了。在這種情況下，社區(qū)提出了“重調(diào)度”的概念，即控制器將某個處于運(yùn)行中的Pod終止，并在不中斷服務(wù)的情況下，將此Pod重新調(diào)度到適合的節(jié)點(diǎn)上。