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

至于調度器如何撰寫，我們這里就不詳細說了，作業中幾乎不會使用到，有興趣的同學可以自行查閱官網或其他資料，

Kubernetes K8S之調度器kube-scheduler詳解

kube-scheduler調度概述

kube-scheduler調度流程

預選策略（Predicates）

優選策略（Priorities）

自定義調度器

相關閱讀