Kubernetes K8S之調度器kube-scheduler詳解

 

Kubernetes K8S之調度器kube-scheduler概述與詳解

 

kube-scheduler調度概述

在 Kubernetes 中，調度是指將 Pod 放置到合適的 Node 節點上，而後對應 Node 上的 Kubelet 纔可以運行這些 pod。

調度器經過 kubernetes 的 watch 機制來發現集羣中新建立且還沒有被調度到 Node 上的 Pod。調度器會將發現的每個未調度的 Pod 調度到一個合適的 Node 上來運行。調度器會依據下文的調度原則來作出調度選擇。

調度是容器編排的重要環節，須要通過嚴格的監控和控制，現實生產一般對調度有各種限制，譬如某些服務必須在業務獨享的機器上運行，或者從災備的角度考慮儘可能把服務調度到不一樣機器，這些需求在Kubernetes集羣依靠調度組件kube-scheduler知足。

kube-scheduler是Kubernetes中的關鍵模塊，扮演管家的角色聽從一套機制——爲Pod提供調度服務，例如基於資源的公平調度、調度Pod到指定節點、或者通訊頻繁的Pod調度到同一節點等。容器調度自己是一件比較複雜的事，由於要確保如下幾個目標：

• 公平性：在調度Pod時須要公平的進行決策，每一個節點都有被分配資源的機會，調度器須要對不一樣節點的使用做出平衡決策。
• 資源高效利用：最大化羣集全部資源的利用率，使有限的CPU、內存等資源服務儘量更多的Pod。
• 效率問題：能快速的完成對大批量Pod的調度工做，在集羣規模擴增的狀況下，依然保證調度過程的性能。
• 靈活性：在實際運做中，用戶每每但願Pod的調度策略是可控的，從而處理大量複雜的實際問題。所以平臺要容許多個調度器並行工做，同時支持自定義調度器。

爲達到上述目標，kube-scheduler經過結合Node資源、負載狀況、數據位置等各類因素進行調度判斷，確保在知足場景需求的同時將Pod分配到最優節點。顯然，kube-scheduler影響着Kubernetes集羣的可用性與性能，Pod數量越多集羣的調度能力越重要，尤爲達到了數千級節點數時，優秀的調度能力將顯著提高容器平臺性能。

 

kube-scheduler調度流程

kube-scheduler的根本工做任務是根據各類調度算法將Pod綁定（bind）到最合適的工做節點，整個調度流程分爲兩個階段：預選策略（Predicates）和優選策略（Priorities）。

預選（Predicates）：輸入是全部節點，輸出是知足預選條件的節點。kube-scheduler根據預選策略過濾掉不知足策略的Nodes。例如，若是某節點的資源不足或者不知足預選策略的條件如「Node的label必須與Pod的Selector一致」時則沒法經過預選。

優選（Priorities）：輸入是預選階段篩選出的節點，優選會根據優先策略爲經過預選的Nodes進行打分排名，選擇得分最高的Node。例如，資源越富裕、負載越小的Node可能具備越高的排名。

通俗點說，調度的過程就是在回答兩個問題：1. 候選有哪些？2. 其中最適合的是哪一個？

值得一提的是，若是在預選階段沒有節點知足條件，Pod會一直處在Pending狀態直到出現知足的節點，在此期間調度器會不斷的進行重試。

 

預選策略（Predicates）

官網地址：調度器預選、優選策略

過濾條件包含以下：

• PodFitsHostPorts：檢查Pod容器所需的HostPort是否已被節點上其它容器或服務佔用。若是已被佔用，則禁止Pod調度到該節點。
• PodFitsHost：檢查Pod指定的NodeName是否匹配當前節點。
• PodFitsResources：檢查節點是否有足夠空閒資源（例如CPU和內存）來知足Pod的要求。
• PodMatchNodeSelector：檢查Pod的節點選擇器(nodeSelector)是否與節點(Node)的標籤匹配
• NoVolumeZoneConflict：對於給定的某塊區域，判斷若是在此區域的節點上部署Pod是否存在卷衝突。
• NoDiskConflict：根據節點請求的卷和已經掛載的卷，評估Pod是否適合該節點。
• MaxCSIVolumeCount：決定應該附加多少CSI卷，以及該卷是否超過配置的限制。
• CheckNodeMemoryPressure：若是節點報告內存壓力，而且沒有配置異常，那麼將不會往那裏調度Pod。
• CheckNodePIDPressure：若是節點報告進程id稀缺，而且沒有配置異常，那麼將不會往那裏調度Pod。
• CheckNodeDiskPressure：若是節點報告存儲壓力(文件系統已滿或接近滿)，而且沒有配置異常，那麼將不會往那裏調度Pod。
• CheckNodeCondition：節點能夠報告它們有一個徹底完整的文件系統，然而網絡不可用，或者kubelet沒有準備好運行Pods。若是爲節點設置了這樣的條件，而且沒有配置異常，那麼將不會往那裏調度Pod。
• PodToleratesNodeTaints：檢查Pod的容忍度是否能容忍節點的污點。
• CheckVolumeBinding：評估Pod是否適合它所請求的容量。這適用於約束和非約束PVC。

若是在predicates(預選)過程當中沒有合適的節點，那麼Pod會一直在pending狀態，不斷重試調度，直到有節點知足條件。

通過這個步驟，若是有多個節點知足條件，就繼續priorities過程，最後按照優先級大小對節點排序。

 

優選策略（Priorities）

包含以下優選評分條件：

• SelectorSpreadPriority：對於屬於同一服務、有狀態集或副本集（Service，StatefulSet or ReplicaSet）的Pods，會將Pods儘可能分散到不一樣主機上。
• InterPodAffinityPriority：策略有podAffinity和podAntiAffinity兩種配置方式。簡單來講，就說根據Node上運行的Pod的Label來進行調度匹配的規則，匹配的表達式有：In, NotIn, Exists, DoesNotExist，經過該策略，能夠更靈活地對Pod進行調度。
• LeastRequestedPriority：偏向使用較少請求資源的節點。換句話說，放置在節點上的Pod越多，這些Pod使用的資源越多，此策略給出的排名就越低。
• MostRequestedPriority：偏向具備最多請求資源的節點。這個策略將把計劃的Pods放到整個工做負載集所需的最小節點上運行。
• RequestedToCapacityRatioPriority：使用默認的資源評分函數模型建立基於ResourceAllocationPriority的requestedToCapacity。
• BalancedResourceAllocation：偏向具備平衡資源使用的節點。
• NodePreferAvoidPodsPriority：根據節點註釋scheduler.alpha.kubernet .io/preferAvoidPods爲節點劃分優先級。可使用它來示意兩個不一樣的Pod不該在同一Node上運行。
• NodeAffinityPriority：根據preferredduringschedulingignoredingexecution中所示的節點關聯調度偏好來對節點排序。
• TaintTolerationPriority：根據節點上沒法忍受的污點數量，爲全部節點準備優先級列表。此策略將考慮該列表調整節點的排名。
• ImageLocalityPriority：偏向已經擁有本地緩存Pod容器鏡像的節點。
• ServiceSpreadingPriority：對於給定的服務，此策略旨在確保Service的Pods運行在不一樣的節點上。總的結果是，Service對單個節點故障變得更有彈性。
• EqualPriority：賦予全部節點相同的權值1。
• EvenPodsSpreadPriority：實現擇優 pod的拓撲擴展約束

 

自定義調度器

除了Kubernetes自帶的調度器，咱們也能夠編寫本身的調度器。經過spec.schedulername參數指定調度器名字，能夠爲Pod選擇某個調度器進行調度。

以下Pod選擇my-scheduler進行調度，而不是默認的default-scheduler

 1 apiVersion: v1
 2 kind: Pod
 3 metadata:
 4   name: annotation-second-scheduler
 5   labels:
 6     name: multischeduler-example
 7 spec:
 8   schedulername: my-scheduler
 9   containers:
10   - name: pod-with-second-annotation-container
11     image: gcr.io/google_containers/pause:2.0

至於調度器如何編寫，咱們這裏就不詳細說了，工做中幾乎不會使用到，有興趣的同窗能夠自行查閱官網或其餘資料。

 

相關閱讀

一、官網：調度器預選、優選策略

二、k8s調度器kube-scheduler

完畢！

 

---

 

 

———END———
若是以爲不錯就關注下唄 (-^O^-) ！