溫馨提示×

溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

Kubernetes調(diào)度算法是怎么使用的

發(fā)布時間：2021-10-12 09:49:49 來源：億速云 閱讀：115 作者：柒染 欄目：云計算

Kubernetes調(diào)度算法是怎么使用的，針對這個問題，這篇文章詳細介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

調(diào)度流程

調(diào)度器就是一個獨立的進程，負責(zé)不斷從apiserver拉取還沒有被調(diào)度的pod，以及可調(diào)度的node列表，通過一些列算法篩選，選出一個node并與該pod綁定，將綁定的結(jié)果寫回apiserver

調(diào)度算法

下面講解基于k8s v1.6.6的源碼

算法需要經(jīng)過兩個階段，分別是過濾和打分，首先過濾掉一部分，保證剩余的節(jié)點都是可調(diào)度的，接著在打分階段選出最高分節(jié)點，該節(jié)點就是scheduler的輸出節(jié)點。

過濾

過濾環(huán)節(jié)就是一條過濾器鏈，包含多個過濾器，每個相當(dāng)于一個函數(shù)，接收node和待調(diào)度的pod作為參數(shù)，返回bool來確定是否可調(diào)度。通過組合多個函數(shù)可以完成一條可擴展的過濾器鏈。目前k8s中已注冊的過濾器函數(shù)如下：

算法名稱是否默認詳細說明
NoVolumeZoneConflict是當(dāng)主機上zone-label（地區(qū)）包含pod中PersistentVolume卷下的zone label時，可以調(diào)度。當(dāng)主機沒有zone-label，表示沒有沒有zone限制，也可調(diào)度
MaxEBSVolumeCount是當(dāng)主機上被掛載的AWS EBS Volume超過了默認限制39，就不調(diào)度到該主機
MaxGCEPDVolumeCount是當(dāng)主機上被掛載的GCD Persistent Disk超過了默認限制16，就不調(diào)度到該機器
MaxAzureDiskVolumeCount是當(dāng)主機上被掛載的Azure Disk Volume超過了默認限制16，就不調(diào)度到該機器
NoDiskConflict是

當(dāng)主機上所有pod使用的卷和待調(diào)度pod使用的卷存在沖突，就不調(diào)度到該主機。這項檢查只針對GCE, Amazon EBS, Ceph RBD, ISCSI，具體規(guī)則為：

  •       GCE PersistentDisk允許多次只讀掛載相同的volume

  •       EBS禁止兩個pod掛載同一個id的volume

  •       Ceph RBD禁止兩個pod共享一個monitor、pool、image

  •       ISCSI禁止兩個pod共享同一個IQN

MatchInterPodAffinity是親和性檢查，設(shè)帶調(diào)度的pod為X，當(dāng)主機上所有正運行的pod與X不相互排斥時，則可調(diào)度 
PodToleratesNodeTaints是當(dāng)pod可以容忍（tolerate）主機所有的taint（污點）時，才可被調(diào)度（容忍taint標(biāo)簽的方式就是給自己也打上相應(yīng)tolerations標(biāo)簽）
CheckNodeMemoryPressure是當(dāng)主機剩余內(nèi)存緊張時，BestEffort類型的pod無法被調(diào)度到該主機
CheckNodeDiskPressure是當(dāng)主機剩余磁盤空間緊張時，無法調(diào)度到該主機 
PodFitsHostPorts是當(dāng)待調(diào)度pod中所有容器所用到的HostPort與工作節(jié)點上已使用端口存在沖突，就不調(diào)度到該主機 
PodFitsPorts是被PodFitsHostPorts取代 
PodFitsResources是當(dāng)總資源-主機中所有pod對資源的request總量 < 帶調(diào)度的pod request資源量，則不調(diào)度到該主機，現(xiàn)在會檢查CPU,MEM,GPU資源
HostName是如果待調(diào)度的pod指定了pod.Spec.Host，則調(diào)度到該主機上 
MatchNodeSelector是 當(dāng)主機label與pod中nodeSelector以及annotations  scheduler.alpha.kubernetes.io/affinity匹配，則可調(diào)度


打分

打分環(huán)節(jié)也是一條鏈路，包含多個打分函數(shù)，每個打分函數(shù)會接收node和待調(diào)度的pod作為參數(shù)，返回一個范圍在0-10的分數(shù)，每個打分函數(shù)還有一個權(quán)重值。某個node算出的總分就是所有打分函數(shù)的分值*權(quán)重值的總和，獲取總分最大的node（如果有多個，隨機取一個），該node就是最終要被調(diào)度的節(jié)點

示例：假設(shè)有個節(jié)點nodeA，有兩個打分函數(shù)priorityFunc1、priorityFunc2（每個方法都能返回一個score），兩個方法分別都有權(quán)重因子weight1、weight2。則nodeA的總分為：finalScoreNodeA = (weight1 * priorityFunc1) + (weight2 * priorityFunc2)

目前k8s中已注冊的打分函數(shù)如下：

算法名稱是否默認權(quán)重詳細說明
SelectorSpreadPriority是1相同service／rc的pods越分散，得分越高
ServiceSpreadingPriority否1相同service的pods越分散，優(yōu)得分越高，被SelectorSpreadPriority取代，保留在系統(tǒng)中，并不使用
InterPodAffinityPriority是1pod與node上正運行的其他pod親和性匹配度越高，得分越高
LeastRequestedPriority是1剩余資源越多，得分越高。cpu((capacity - sum(requested)) * 10 / capacity) + memory((capacity - sum(requested)) * 10 / capacity) / 2
BalancedResourceAllocation是1cpu和內(nèi)存利用率越接近，得分越高。10 - abs(cpuFraction-memoryFraction)*10
NodePreferAvoidPodsPriority是10000當(dāng)node的annotation scheduler.alpha.kubernetes.io/preferAvoidPods被設(shè)置時，說明該node不希望被調(diào)度，得分低，當(dāng)沒有設(shè)置時得分高。之所以權(quán)重較大是因為一旦設(shè)置preferAvoidPods表示該node不希望被調(diào)度，該項得分為0，其他沒有設(shè)置的node得分均為10000*分值，相當(dāng)于直接過濾掉該節(jié)點。思考：其實可以放在過濾環(huán)節(jié)處理
NodeAffinityPriority是1pod與node的親和性匹配度越高，得分越高
TaintTolerationPriority是1pod對node的污點（taint）的容忍（tolerate）程度越高，得分越高
EqualPriority否1所有機器得分一樣
ImageLocalityPriority否1待調(diào)度的pod會使用到一些鏡像，擁有這些鏡像越多的節(jié)點，得分越高
MostRequestedPriority否1request資源越多，得分越高，與LeastRequestedPriority相反。(cpu(10 * sum(requested) / capacity) + memory(10 * sum(requested) / capacity)) / 2


關(guān)于Kubernetes調(diào)度算法是怎么使用的問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識。

向AI問一下細節(jié)

免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI
助
手