源碼為 k8s v1.6.1 版本，github 上對應(yīng)的 commit id 為 b0b7a323cc5a4a2019b2e9520c21c7830b7f708e

本文將對 Scheduler 的調(diào)度算法原理和執(zhí)行過程進行分析，重點介紹 Scheduler 算法中預(yù)選和優(yōu)選的相關(guān)內(nèi)容。

Kubernetes Scheduler的基本功能

Kubernetes Scheduler 的作用是根據(jù)特定的調(diào)度算法將pod調(diào)度到指定的工作節(jié)點(Node)上，這一過程也叫綁定(bind)。Scheduler 的輸入為需要調(diào)度的 Pod 和可以被調(diào)度的節(jié)點(Node)的信息，輸出為調(diào)度算法選擇的 Node，并將該 pod bind 到這個 Node 。

Kubernetes Scheduler中調(diào)度算法分為兩個階段：

預(yù)選 : 根據(jù)配置的 Predicates Policies(默認(rèn)為 DefaultProvider 中定義的 default predicates policies 集合)過濾掉那些不滿足Policies的的Nodes，剩下的Nodes作為優(yōu)選的輸入。

優(yōu)選 : 根據(jù)配置的 Priorities Policies(默認(rèn)為 DefaultProvider 中定義的 default priorities policies 集合)給預(yù)選后的Nodes進行打分排名，得分***的Node即作為最適合的Node，該Pod就Bind到這個Node。

預(yù)選規(guī)則詳細(xì)說明

預(yù)先規(guī)則主要用于過濾出不符合規(guī)則的Node節(jié)點，剩下的節(jié)點作為優(yōu)選的輸入。在1.6.1版本中預(yù)選規(guī)則包括：

詳細(xì)的規(guī)則說明：

(1) NoDiskConflict : 檢查在此主機上是否存在卷沖突。如果這個主機已經(jīng)掛載了卷，其它使用這個卷的Pod不能調(diào)度到這個主機上。GCE 、Amazon EBS 和 Ceph RBD 使用的規(guī)則如下:

1. GCE 允許同時掛載多個卷，只要這些卷都是只讀的。
2. Amazon EBS 不允許不同的 Pod 掛載同一個卷。
3. Ceph RBD 不允許任何兩個 pods 分享相同的 monitor，match pool 和 image。

注：ISCSI 與 GCE 一樣，在卷都是只讀的情況下，允許掛載兩個 IQN 相同的卷。

(2) NoVolumeZoneConflict : 檢查在給定的 zone 限制前提下，檢查在此主機上部署 Pod 是否存在卷沖突，目前指對 PV 資源進行檢查(NewVolumeZonePredicate對象predicate函數(shù))。

(3) MaxEBSVolumeCount : 確保已掛載的 EBS 存儲卷不超過設(shè)置的***值。默認(rèn)值是39。它會檢查直接使用的存儲卷，和間接使用這種類型存儲的 PVC 。計算不同卷的總目，如果新的 Pod 部署上去后卷的數(shù)目會超過設(shè)置的***值，那么 Pod 就不能調(diào)度到這個主機上。

(4) MaxGCEPDVolumeCount : 確保已掛載的 GCE 存儲卷不超過設(shè)置的***值。默認(rèn)值是16。規(guī)則同MaxEBSVolumeCount。

(5) MaxAzureDiskVolumeCount : 確保已掛載的Azure存儲卷不超過設(shè)置的***值。默認(rèn)值是16。規(guī)則同MaxEBSVolumeCount。

(6) CheckNodeMemoryPressure : 判斷節(jié)點是否已經(jīng)進入到內(nèi)存壓力狀態(tài)，如果是則只允許調(diào)度內(nèi)存為0標(biāo)記的 Pod。

(7) CheckNodeDiskPressure : 判斷節(jié)點是否已經(jīng)進入到磁盤壓力狀態(tài)，如果是則不調(diào)度新的Pod。

(8) PodToleratesNodeTaints : Pod 是否滿足節(jié)點容忍的一些條件。

(9) MatchInterPodAffinity : 節(jié)點親和性篩選。

(10) GeneralPredicates : 包含一些基本的篩選規(guī)則(PodFitsResources、PodFitsHostPorts、HostName、MatchNodeSelector)。

(11) PodFitsResources : 檢查節(jié)點上的空閑資源(CPU、Memory、GPU資源)是否滿足 Pod 的需求。

(12) PodFitsHostPorts : 檢查 Pod 內(nèi)每一個容器所需的 HostPort 是否已被其它容器占用。如果有所需的HostPort不滿足要求，那么 Pod 不能調(diào)度到這個主機上。

(13) 檢查主機名稱是不是 Pod 指定的 HostName。

(14) 檢查主機的標(biāo)簽是否滿足 Pod 的 nodeSelector 屬性需求。

優(yōu)選規(guī)則詳細(xì)說明

優(yōu)選規(guī)則對符合需求的主機列表進行打分，最終選擇一個分值***的主機部署 Pod。kubernetes 用一組優(yōu)先級函數(shù)處理每一個待選的主機。每一個優(yōu)先級函數(shù)會返回一個0-10的分?jǐn)?shù)，分?jǐn)?shù)越高表示主機越“好”，同時每一個函數(shù)也會對應(yīng)一個表示權(quán)重的值。最終主機的得分用以下公式計算得出：

finalScoreNode = (weight1 priorityFunc1) + (weight2 priorityFunc2) + … + (weightn * priorityFuncn)

詳細(xì)的規(guī)則說明：

(1) SelectorSpreadPriority : 對于屬于同一個 service、replication controller 的 Pod，盡量分散在不同的主機上。如果指定了區(qū)域，則會盡量把 Pod 分散在不同區(qū)域的不同主機上。調(diào)度一個 Pod 的時候，先查找 Pod 對于的 service或者 replication controller，然后查找 service 或 replication controller 中已存在的 Pod，主機上運行的已存在的 Pod 越少，主機的打分越高。

(2) LeastRequestedPriority : 如果新的 pod 要分配一個節(jié)點，這個節(jié)點的優(yōu)先級就由節(jié)點空閑的那部分與總?cè)萘康谋戎?(總?cè)萘?節(jié)點上pod的容量總和-新pod的容量)/總?cè)萘?來決定。CPU 和 memory 權(quán)重相當(dāng)，比值***的節(jié)點的得分***。需要注意的是，這個優(yōu)先級函數(shù)起到了按照資源消耗來跨節(jié)點分配 pods 的作用。計算公式如下：

cpu((capacity – sum(requested)) 10 / capacity) + memory((capacity – sum(requested)) 10 / capacity) / 2

(3) BalancedResourceAllocation : 盡量選擇在部署 Pod 后各項資源更均衡的機器。BalancedResourceAllocation 不能單獨使用，而且必須和 LeastRequestedPriority 同時使用，它分別計算主機上的 cpu 和 memory 的比重，主機的分值由 cpu 比重和 memory 比重的“距離”決定。計算公式如下：score = 10 – abs(cpuFraction-memoryFraction)*10

(4) NodeAffinityPriority : Kubernetes 調(diào)度中的親和性機制。Node Selectors(調(diào)度時將 pod 限定在指定節(jié)點上)，支持多種操作符(In、 NotIn、 Exists、DoesNotExist、 Gt、 Lt)，而不限于對節(jié)點 labels 的精確匹配。另外，Kubernetes 支持兩種類型的選擇器，一種是 “ hard(requiredDuringSchedulingIgnoredDuringExecution)” 選擇器，它保證所選的主機滿足所有Pod對主機的規(guī)則要求。這種選擇器更像是之前的 nodeselector，在 nodeselector 的基礎(chǔ)上增加了更合適的表現(xiàn)語法。另一種 “ soft(preferresDuringSchedulingIgnoredDuringExecution)” 選擇器，它作為對調(diào)度器的提示，調(diào)度器會盡量但不保證滿足 NodeSelector 的所有要求。

(5) InterPodAffinityPriority : 通過迭代 weightedPodAffinityTerm 的元素計算和，并且如果對該節(jié)點滿足相應(yīng)的PodAffinityTerm，則將 “weight” 加到和中，具有***和的節(jié)點是***選的。

(6) NodePreferAvoidPodsPriority(權(quán)重1W) : 如果 Node 的 Anotation 沒有設(shè)置 key-value:scheduler. alpha.kubernetes.io/ preferAvoidPods = "..."，則該 node 對該 policy 的得分就是10分，加上權(quán)重10000，那么該node對該policy的得分至少10W分。如果Node的Anotation設(shè)置了，scheduler.alpha.kubernetes.io/preferAvoidPods = "..." ，如果該 pod 對應(yīng)的 Controller 是 ReplicationController 或 ReplicaSet，則該 node 對該 policy 的得分就是0分。

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

另外在優(yōu)選的調(diào)度規(guī)則中，有幾個未被默認(rèn)使用的規(guī)則：

(1) ImageLocalityPriority : 據(jù)主機上是否已具備 Pod 運行的環(huán)境來打分。ImageLocalityPriority 會判斷主機上是否已存在 Pod 運行所需的鏡像，根據(jù)已有鏡像的大小返回一個0-10的打分。如果主機上不存在 Pod 所需的鏡像，返回0;如果主機上存在部分所需鏡像，則根據(jù)這些鏡像的大小來決定分值，鏡像越大，打分就越高。

(2) EqualPriority : EqualPriority 是一個優(yōu)先級函數(shù)，它給予所有節(jié)點一個相等的權(quán)重。

(3) ServiceSpreadingPriority : 作用與 SelectorSpreadPriority 相同，已經(jīng)被 SelectorSpreadPriority 替換。

(4) MostRequestedPriority : 在 ClusterAutoscalerProvider 中，替換 LeastRequestedPriority，給使用多資源的節(jié)點，更高的優(yōu)先級。計算公式為：(cpu(10 sum(requested) / capacity) + memory(10 sum(requested) / capacity)) / 2

原文鏈接：http://zhuanlan.51cto.com/columnlist/txyjs/

【本文是51CTO專欄作者“騰訊云技術(shù)社區(qū)”的原創(chuàng)稿件，轉(zhuǎn)載請通過51CTO聯(lián)系原作者獲取授權(quán)】

戳這里，看該作者更多好文