目錄

• 一、預(yù)選階段
• • 1、第一種類型，叫作 GeneralPredicates。
  • 2、第二種類型，是與 Volume 相關(guān)的過濾規(guī)則。
  • 3、第三種類型，是宿主機相關(guān)的過濾規(guī)則。
  • 4、第四種類型，是 Pod 相關(guān)的過濾規(guī)則。
• 二、優(yōu)選階段
• 三、調(diào)度源碼
• 總結(jié)

---

在 Kubernetes 項目中，默認(rèn)調(diào)度器的主要職責(zé)，就是為一個新創(chuàng)建出來的 Pod，尋找一個最合適的節(jié)點（Node）。

從集群所有的節(jié)點中，根據(jù)調(diào)度算法挑選出所有可以運行該 Pod 的節(jié)點

從第一步的結(jié)果中，再根據(jù)調(diào)度算法挑選一個最符合條件的節(jié)點作為最終結(jié)果。
預(yù)選，優(yōu)選，綁定三個階段

一、預(yù)選階段

Kubernetes 中，默認(rèn)的調(diào)度策略有如下三種：

1、第一種類型，叫作 GeneralPredicates。

PodFitsResources 計算的就是宿主機的 CPU 和內(nèi)存資源等是否夠用，PodFitsResources 檢查的只是 Pod 的 requests 字段

PodFitsHost 檢查的是，宿主機的名字是否跟 Pod 的 spec.nodeName 一致。這里應(yīng)該指的是pod中已指定的spec.nodeName

PodFitsHostPorts 檢查的是，Pod 申請的宿主機端口（spec.nodePort）是不是跟已經(jīng)被使用的端口有沖突。

PodMatchNodeSelector 檢查的是，Pod 的 nodeSelector 或者 nodeAffinity 指定的節(jié)點，是否與待考察節(jié)點匹配，等等。

2、第二種類型，是與 Volume 相關(guān)的過濾規(guī)則。

NoDiskConflict 檢查的條件，是多個 Pod 聲明掛載的持久化 Volume 是否有沖突

MaxPDVolumeCountPredicate 檢查的條件，則是一個節(jié)點上某種類型的持久化 Volume 是不是已經(jīng)超過了一定數(shù)目

VolumeZonePredicate，則是檢查持久化 Volume 的 Zone（高可用域）標(biāo)簽，是否與待考察節(jié)點的 Zone 標(biāo)簽相匹配。

VolumeBindingPredicate 的規(guī)則。它負(fù)責(zé)檢查的，是該 Pod 對應(yīng)的 PV 的 nodeAffinity 字段，是否跟某個節(jié)點的標(biāo)簽相匹配。

3、第三種類型，是宿主機相關(guān)的過濾規(guī)則。

PodToleratesNodeTaints，負(fù)責(zé)檢查的就是我們前面經(jīng)常用到的 Node 的“污點”機制。

NodeMemoryPressurePredicate，檢查的是當(dāng)前節(jié)點的內(nèi)存是不是已經(jīng)不夠充足，如果是的話，那么待調(diào)度 Pod 就不能被調(diào)度到該節(jié)點上。

4、第四種類型，是 Pod 相關(guān)的過濾規(guī)則。

這一組規(guī)則，跟 GeneralPredicates 大多數(shù)是重合的。而比較特殊的，是 PodAffinityPredicate。這個規(guī)則的作用，是檢查待調(diào)度 Pod 與 Node 上的已有 Pod 之間的親密（affinity）和反親密（anti-affinity）關(guān)系

---

上面這四種類型的 Predicates，就構(gòu)成了調(diào)度器確定一個 Node 可以運行待調(diào)度 Pod 的基本策略。在具體執(zhí)行的時候， 當(dāng)開始調(diào)度一個 Pod 時，Kubernetes 調(diào)度器會同時啟動 16 個 Goroutine，來并發(fā)地為集群里的所有 Node 計算 Predicates，最后返回可以運行這個 Pod 的宿主機列表。

---

二、優(yōu)選階段

在 預(yù)選 階段完成了節(jié)點的“過濾”之后，Priorities 階段的工作就是為這些節(jié)點打分。這里打分的范圍是 0-10 分，得分最高的節(jié)點就是最后被 Pod 綁定的最佳節(jié)點。
1、最常用到的一個打分規(guī)則，是 LeastRequestedPriority。它的計算方法，可以簡單地總結(jié)為如下所示的公式：

score = (cpu((capacity-sum(requested))10/capacity) + memory((capacity-sum(requested))10/capacity))/2

2、LeastRequestedPriority 一起發(fā)揮作用的，還有 BalancedResourceAllocation。它的計算公式如下所示：

score = 10 -variance(cpuFraction,memoryFraction,volumeFraction)*10

其中，每種資源的 Fraction 的定義是 ：Pod 請求的資源 / 節(jié)點上的可用資源。而 variance 算法的作用，則是計算每兩種資源 Fraction 之間的“距離”。而最后選擇的，則是資源 Fraction 差距最小的節(jié)點。所以說，BalancedResourceAllocation 選擇的，其實是調(diào)度完成后，所有節(jié)點里各種資源分配最均衡的那個節(jié)點，從而避免一個節(jié)點上 CPU 被大量分配、而 Memory 大量剩余的情況。

3、NodeAffinityPriority、TaintTolerationPriority 和 InterPodAffinityPriority 這三種 Priority。顧名思義，它們與前面的 PodMatchNodeSelector、PodToleratesNodeTaints 和 PodAffinityPredicate 這三個 Predicate 的含義和計算方法是類似的。但是作為 Priority，一個 Node 滿足上述規(guī)則的字段數(shù)目越多，它的得分就會越高。

4、在默認(rèn) Priorities 里，還有一個叫作 ImageLocalityPriority 的策略。它是在 Kubernetes v1.12 里新開啟的調(diào)度規(guī)則，即：如果待調(diào)度 Pod 需要使用的鏡像很大，并且已經(jīng)存在于某些 Node 上，那么這些 Node 的得分就會比較高。當(dāng)然，為了避免這個算法引發(fā)調(diào)度堆疊，調(diào)度器在計算得分的時候還會根據(jù)鏡像的分布進行優(yōu)化，即：如果大鏡像分布的節(jié)點數(shù)目很少，那么這些節(jié)點的權(quán)重就會被調(diào)低，從而“對沖”掉引起調(diào)度堆疊的風(fēng)險。

---

三、調(diào)度源碼

1、UpdateNodeNameToInfoMap根據(jù)node的cache更新信息，如果node已被移除，則將map的對應(yīng)節(jié)點信息刪掉，如果map中不存在節(jié)點的信息，將該節(jié)點的信息集合加入map中，這些信息集合運用于后期的pod調(diào)度的邏輯判斷，對于么個節(jié)點，這些信息包括:

a、節(jié)點的node資源信息；
b、在該節(jié)點上的pod請求和可分配的資源總和，包括cpu、內(nèi)存、gpu、容許的pod總數(shù)、存儲等；
c、內(nèi)存、磁盤壓力情況；
d、節(jié)點上的占用端口；
e、Pod的親和性；
f、節(jié)點taints容忍性；

2、findNodesThatFit是schedule的預(yù)選，該函數(shù)根據(jù)配置的 Predicates Policies會返回一組符合Policies的nodes，最后將這組nodes作為優(yōu)選的輸入。如果經(jīng)過預(yù)選后返回的節(jié)點只有一個，那么直接將該節(jié)點的名稱返回，如果多余1個，將繼續(xù)優(yōu)選。
priorityMetaProducer獲取pod effect為空或者為PreferNoSchedule，將toleration加入toleration列表，獲取selector與pod相關(guān)的rc、rs、service加入到selector列表。獲取pod中container請求的cpu、內(nèi)存大小綜合，如果container未設(shè)定，cpu默認(rèn)為100，內(nèi)存默認(rèn)為209715200。
獲取pod的親和性。
關(guān)于PreferNoSchedule、NoSchedule、NoExecute的介紹如下：
對比一個 node 上所有的 taints，忽略掉和 pod 中 toleration 匹配的 taints，遺留下來未被忽略掉的所有 taints 將對 pod 產(chǎn)生 effect。
a、至少有 1 個未被忽略的 taint 且 effect 是 NoSchedule 時，則 k8s 不會將該 pod 調(diào)度到這個 node 上
b、不滿足上述場景，但至少有 1 個未被忽略的 taint 且 effect 是 PreferNoSchedule 時，則 k8s 將嘗試不把該 pod 調(diào)度到這個 node 上
c、至少有 1 個未被忽略的 taint 且 effect 是 NoExecute 時，則 k8s 會立即將該 pod 從該 node 上驅(qū)逐（如果已經(jīng)在該 node 上運行），或著不會將該 pod 調(diào)度到這個 node 上（如果還沒在這個 node 上運行）

總結(jié)

調(diào)度會獲取pod中container請求的cpu、內(nèi)存大小，如果container未設(shè)定，cpu默認(rèn)為100，內(nèi)存默認(rèn)為209715200,建議合理設(shè)置resource request/limit,防止調(diào)度不均，節(jié)點熱度不同的問題

總結(jié)

以上是生活随笔為你收集整理的k8s-scheduler调度规则的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。