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

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

Kubernetes Scheduler的基本功能

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(13) 檢查主機(jī)名稱(chēng)是不是 Pod 指定的 HostName。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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