這篇文章給大家分享的是有關(guān)Kubernetes Scheduler有什么用的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

公司專注于為企業(yè)提供做網(wǎng)站、成都網(wǎng)站制作、微信公眾號開發(fā)、成都做商城網(wǎng)站，小程序設(shè)計，軟件按需定制等一站式互聯(lián)網(wǎng)企業(yè)服務(wù)。憑借多年豐富的經(jīng)驗，我們會仔細了解各客戶的需求而做出多方面的分析、設(shè)計、整合，為客戶設(shè)計出具風格及創(chuàng)意性的商業(yè)解決方案，創(chuàng)新互聯(lián)公司更提供一系列網(wǎng)站制作和網(wǎng)站推廣的服務(wù)。

先來過一下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)度算法分為兩個階段：
預選 : 根據(jù)配置的 Predicates Policies（默認為 DefaultProvider 中定義的 default predicates policies 集合）過濾掉那些不滿足Policies的Nodes，剩下的Nodes作為優(yōu)選的輸入。

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

預選規(guī)則詳細說明

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

詳細的規(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è)置的最大值。默認值是39。它會檢查直接使用的存儲卷，和間接使用這種類型存儲的 PVC 。計算不同卷的總目，如果新的 Pod 部署上去后卷的數(shù)目會超過設(shè)置的最大值，那么 Pod 就不能調(diào)度到這個主機上。

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

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

(6) CheckNodeMemoryPressure : 判斷節(jié)點是否已經(jīng)進入到內(nèi)存壓力狀態(tài)，如果是則只允許調(diào)度內(nèi)存為0標記的 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) 檢查主機的標簽是否滿足 Pod 的 nodeSelector 屬性需求。

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

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

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

詳細的規(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è)萘浚﹣頉Q定。CPU 和 memory 權(quán)重相當，比值最大的節(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é)點是最優(yōu)選的。

(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ī)則中，有幾個未被默認使用的規(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(10sum(requested) / capacity)) / 2

感謝各位的閱讀！關(guān)于“Kubernetes Scheduler有什么用”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！