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
至於調度器如何編寫，我們這裡就不詳細說了，工作中幾乎不會使用到，有興趣的同學可以自行查閱官網或其他資料。
相關閱讀
完畢！
———END———
如果覺得不錯就關注下唄 (-^O^-) ！
