排程

在Kubernetes中，排程（Scheduling），指的是為 Pod 找到一個合适的節點，并由該節點上的 kubelet 運作 Pod。

# 概述

每當叢集中有新的 Pod 建立時，Kubernetes 排程器将負責為其找到最合适的節點去運作。排程器按照本文後面描述的原則執行執行排程工作。如果您想了解為什麼 Pod 被配置設定到了具體的某一個節點，或者您打算自己實作一個定制化的排程器，本文可以幫助您更好的了解 Kubernetes 的排程工作。

# kube-scheduler

kube-scheduler

是 Kubernetes 中預設的排程器，并且運作在 Master 元件中。kube-scheduler 雖然是預設的排程器，但是，在您需要的時候，您可以實作自己的排程器以替代 kube-scheduler。

對于每一個新建立的或者未排程的 Pod，kube-scheduler 為其選擇一個合适的節點去運作。問題是，每一個 Pod 以及其中的每一個容器，都有不同的資源需求，在排程時，必須選擇那些能夠滿足 Pod 的資源需求的節點才可以。

叢集中能夠滿足某一個 Pod 的資源需求的節點，我們稱其為 可選節點（feasible node）。如果某一個 Pod 沒有合适的 可選節點，則該 Pod 将一直停留在 Pending 狀态，直到叢集中出現了對于該 Pod 來說合适的 可選節點。

排程器在執行排程時，執行的步驟如下：

1. 找出該 Pod 的所有 可選節點
2. 按照某種方式對每一個 可選節點 評分
3. 選擇評分最高的 可選節點
4. 将最終選擇結果通知 API Server，這個過程，我們稱其為綁定（binding）

在為 可選節點 評分時，需要考慮的因素有：

• 單個 Pod 和所有 Pod 的資源需求
• 硬體、軟體、政策（Policy，例如Limit Range、Resource Quota等）
• 親和與反親和（affinity and anti-affinity）
• 資料存儲的位置
• 工作負載之間的互相影響
• 其他

# 使用kube-scheduler排程

kube-schduler在執行排程時，将上述過程分成兩個階段來執行：

1. Filtering （篩選/過濾）
2. Scoring （評分）

Filtering（篩選/過濾）階段，kube-scheduler找出所有對待排程的 Pod 來說合适的 可選節點。例如，PodFitsResources 過濾器檢查候選節點是否具備足夠的資源可以滿足 Pod 的資源需求。在篩選階段結束後，通常可以找出多個 可選節點，如果沒有找到，則 Pod 一直停留在 Pending 狀态。

# Filtering

• PodFitsHostPorts: 檢查Pod需要的 hostPort 在該節點上是否可用
• PodFitsHost：檢查 Pod 是否通過 hostname 指定了節點，參考 将容器組排程到指定的節點
• PodFitsResource：檢查節點是否滿足 Pod 的資源需求（例如，CPU 和 Memory），參考 管理容器的計算資源
• PodMatchNodeSelector：檢查 Pod 的節點選擇器（nodeSelector）是否和節點的标簽比對，參考 将容器組排程到指定的節點
• NoVolumeZoneConflict：評估 Pod 所需要的 資料卷是否在節點上可用（資料卷的 failure zone restrictions）
• NoDiskConflict：評估Pod請求的資料卷是否和節點已經加載的資料卷沖突
• MaxCSIVolumeCount：計算節點可以挂載多少個 CSI（Container Storage Interface）資料卷，確定不會超出限定的數字
• CheckNodeMemoryPressure：檢查節點是否有記憶體緊張的情況
• CheckNodePIDPressure：檢查節點是否有 PID 短缺的情況
• CheckNodeDiskPressure：檢查節點是否有存儲空間吃緊的情況（檔案系統已滿，或者将要滿）
• CheckNodeCondition：檢查節點的 Condition 字段，該字段中包含關于 檔案系統已滿、網絡不可用、kubelet未就緒 等相關的條件
• PodToleratesNodeTaints：檢查 Pod 是否容忍 Pod 的污點，請參考 污點和容忍
• CheckVolumeBinding：檢查存儲卷聲明是否可綁定

# Scoring

• SelectorSpreadPriority：将 Pod 分散到不同的節點，主要考慮同屬于一個 Service、StatefulSet、Deployment的情況
• InterPodAffinityPriority：周遊 weightedPodAffinityTerm 并求和，找出結果最高的節點
• LeastRequestedPriority：已被消耗的資源最少的節點得分最高。如果節點上的 Pod 越多，被消耗的資源越多，則評分約低
• MostRequestedPriority：已被消耗的資源最多的節點得分最高。此政策會把 Pod 盡量集中到叢集中的少數節點上
• RequestedToCapacityRatioPriority：按 requested / capacity 的百分比評分
• BalancedResourceAllocation：資源使用均衡的節點評分高
• NodePreferAvoidPodsPriority：根據節點的 annotation scheduler.alpha.kubernetes.io/preferAvoidPods 評分。可使用此 annotation 辨別哪些 Pod 不能夠運作在同一個節點上
• NodeAffinityPriority：基于 PreferredDuringSchedulingIgnoredDuringExecution 指定的 node affinity 偏好評分。參考 将容器組排程到指定的節點
• TaintTolerationPriority： 根據節點上不可容忍的污點數評分
• ImageLocalityPriority：有限選擇已經有該 Pod 所需容器鏡像的節點
• ServiceSpreadingPriority：確定 Service 的所有 Pod 盡量分布在不同的節點上。
• CalculateAntiAffinityPriorityMap：anti-affinty，參考将容器組排程到指定的節點
• EqualPriorityMap：為每個節點指定相同的權重