Kubernetes K8S之調度器kube-scheduler詳解

本文轉載自查看原文 2020-10-25 21:02 1280 kubernetes/ devops/ k8s/ linux/ ci/cd/ 自動化/ docker

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

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