資深實踐篇 |基於Kubernetes 1.61的Kubernetes Scheduler排程詳解
資深實踐篇 |基於Kubernetes 1.61的Kubernetes Scheduler排程詳解
關鍵字標籤:騰訊雲,效能優化,Github
說明:該文轉載自騰訊雲技術社群騰雲閣,已徵求作者本人同意。
原始碼為 k8s v1.6.1 版本,github 上對應的 commit id 為b0b7a323cc5a4a2019b2e9520c21c7830b7f708e
本文將對 Scheduler 的排程演算法原理和執行過程進行分析,重點介紹 Scheduler 演算法中預選和優選的相關內容。
先來過一下KubernetesScheduler的基本功能
KubernetesScheduler 的作用是根據特定的排程演算法將pod
KubernetesScheduler中排程演算法分為兩個階段:
預選 : 根據配置的 Predicates Policies(預設為 DefaultProvider 中定義的 default predicates policies 集合)過濾掉那些不滿足Policies的Nodes,剩下的Nodes作為優選的輸入。
優選 : 根據配置的 Priorities Policies
預選規則詳細說明
預先規則主要用於過濾出不符合規則的Node節點,剩下的節點作為優選的輸入。在1.6.1版本中預選規則包括:
詳細的規則說明:
(1) NoDiskConflict : 檢查在此主機上是否存在卷衝突。如果這個主機已經掛載了卷,其它使用這個卷的Pod不能排程到這個主機上。GCE 、AmazonEBS 和 Ceph RBD 使用的規則如下:
1. GCE
2. AmazonEBS 不允許不同的 Pod掛載同一個卷。
3. Ceph RBD 不允許任何兩個 pods分享相同的monitor,match pool 和 image。
注:ISCSI 與 GCE 一樣,在卷都是隻讀的情況下,允許掛載兩個 IQN 相同的卷。
(2) NoVolumeZoneConflict : 檢查在給定的 zone限制前提下,檢查在此主機上部署 Pod 是否存在卷衝突,目前指對 PV 資源進行檢查(NewVolumeZonePredicate物件predicate函式)。
(3) MaxEBSVolumeCount : 確保已掛載的 EBS儲存卷不超過設定的最大值。預設值是39。它會檢查直接使用的儲存卷,和間接使用這種型別儲存的 PVC 。計算不同卷的總目,如果新的 Pod 部署上去後卷的數目會超過設定的最大值,那麼 Pod 就不能排程到這個主機上。
(4) MaxGCEPDVolumeCount : 確保已掛載的 GCE儲存卷不超過設定的最大值。預設值是16。規則同MaxEBSVolumeCount。
(5) MaxAzureDiskVolumeCount : 確保已掛載的Azure儲存卷不超過設定的最大值。預設值是16。規則同MaxEBSVolumeCount。
(6) CheckNodeMemoryPressure : 判斷節點是否已經進入到記憶體壓力狀態,如果是則只允許排程記憶體為0標記的 Pod。
(7) CheckNodeDiskPressure : 判斷節點是否已經進入到磁碟壓力狀態,如果是則不排程新的Pod。
(8) PodToleratesNodeTaints : Pod是否滿足節點容忍的一些條件。
(9) MatchInterPodAffinity : 節點親和性篩選。
(10) GeneralPredicates : 包含一些基本的篩選規則(PodFitsResources、PodFitsHostPorts、HostName、MatchNodeSelector)。
(11) PodFitsResources : 檢查節點上的空閒資源(CPU、Memory、GPU資源)是否滿足 Pod 的需求。
(12) PodFitsHostPorts : 檢查 Pod內每一個容器所需的 HostPort 是否已被其它容器佔用。如果有所需的HostPort不滿足要求,那麼 Pod 不能排程到這個主機上。
(13) 檢查主機名稱是不是 Pod指定的 HostName。
(14) 檢查主機的標籤是否滿足 Pod的 nodeSelector 屬性需求。
優選規則詳細說明
優選規則對符合需求的主機列表進行打分,最終選擇一個分值最高的主機部署 Pod。kubernetes 用一組優先順序函式處理每一個待選的主機。每一個優先順序函式會返回一個0-10的分數,分數越高表示主機越“好”,同時每一個函式也會對應一個表示權重的值。最終主機的得分用以下公式計算得出:
finalScoreNode= (weight1 priorityFunc1) +(weight2 priorityFunc2) + … + (weightn * priorityFuncn)
詳細的規則說明:
(1) SelectorSpreadPriority: 對於屬於同一個 service、replication controller 的 Pod,儘量分散在不同的主機上。如果指定了區域,則會盡量把 Pod 分散在不同區域的不同主機上。排程一個 Pod 的時候,先查詢 Pod 對於的 service或者replication controller,然後查詢 service 或 replication controller 中已存在的 Pod,主機上執行的已存在的
Pod 越少,主機的打分越高。
(2) LeastRequestedPriority : 如果新的 pod要分配一個節點,這個節點的優先順序就由節點空閒的那部分與總容量的比值((總容量-節點上pod的容量總和-新pod的容量)/總容量)來決定。CPU 和 memory 權重相當,比值最大的節點的得分最高。需要注意的是,這個優先順序函式起到了按照資源消耗來跨節點分配
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排程中的親和性機制。Node Selectors(排程時將 pod 限定在指定節點上),支援多種操作符(In、 NotIn、 Exists、DoesNotExist、 Gt、 Lt),而不限於對節點 labels 的精確匹配。另外,Kubernetes 支援兩種型別的選擇器,一種是 “ hard(requiredDuringSchedulingIgnoredDuringExecution)” 選擇器,它保證所選的主機滿足所有Pod對主機的規則要求。這種選擇器更像是之前的 nodeselector,在 nodeselector 的基礎上增加了更合適的表現語法。另一種 “ soft(preferresDuringSchedulingIgnoredDuringExecution)” 選擇器,它作為對排程器的提示,排程器會盡量但不保證滿足 NodeSelector 的所有要求。
(5) InterPodAffinityPriority : 通過迭代 weightedPodAffinityTerm的元素計算和,並且如果對該節點滿足相應的PodAffinityTerm,則將 “weight” 加到和中,具有最高和的節點是最優選的。
(6) NodePreferAvoidPodsPriority(權重1W) : 如果 Node的 Anotation 沒有設定 key-value:scheduler. alpha.kubernetes.io/ preferAvoidPods ="...",則該 node 對該policy 的得分就是10分,加上權重10000,那麼該node對該policy的得分至少10W分。如果Node的Anotation設定了,scheduler.alpha.kubernetes.io/preferAvoidPods= "..." ,如果該 pod 對應的Controller 是 ReplicationController 或 ReplicaSet,則該 node 對該 policy 的得分就是0分。
(7) TaintTolerationPriority : 使用 Pod中 tolerationList 與 Node 節點 Taint 進行匹配,配對成功的項越多,則得分越低。
另外在優選的排程規則中,有幾個未被預設使用的規則:
(1) ImageLocalityPriority : 據主機上是否已具備 Pod執行的環境來打分。ImageLocalityPriority 會判斷主機上是否已存在 Pod 執行所需的映象,根據已有映象的大小返回一個0-10的打分。如果主機上不存在 Pod 所需的映象,返回0;如果主機上存在部分所需映象,則根據這些映象的大小來決定分值,映象越大,打分就越高。
(2) EqualPriority : EqualPriority是一個優先順序函式,它給予所有節點一個相等的權重。
(3) ServiceSpreadingPriority : 作用與 SelectorSpreadPriority相同,已經被SelectorSpreadPriority 替換。
(4) MostRequestedPriority : 在 ClusterAutoscalerProvider中,替換LeastRequestedPriority,給使用多資源的節點,更高的優先順序。計算公式為:(cpu(10 sum(requested) / capacity) + memory(10sum(requested)/ capacity)) / 2