Kubernetes Scheduler淺析

2020 年 10 月 29 日
筆記
cloudnative, DevOps, docker, Kubernetes, linux

概述

Kubernetes 調度器(Scheduler)是Kubernetes的核心組件；用戶或者控制器創建Pod之後，調度器通過 kubernetes 的 watch 機制來發現集群中新創建且尚未被調度到 Node 上的 Pod。調度器會將發現的每一個未調度的 Pod 調度到一個合適的 Node 上來運行。調度器會依據下文的調度原則來做出調度選擇。

kube-scheduler 給一個 pod 做調度選擇包含兩個步驟：過濾、打分
過濾階段會將所有滿足 Pod 調度需求的 Node 選出來。例如，PodFitsResources 過濾函數會檢查候選 Node 的可用資源能否滿足 Pod 的資源請求。在過濾之後，得出一個 Node 列表，裡面包含了所有可調度節點；通常情況下，這個 Node 列表包含不止一個 Node。如果這個列表是空的，代表這個 Pod 不可調度。
打分階段，調度器會為 Pod 從所有可調度節點中選取一個最合適的 Node。根據當前啟用的打分規則，調度器會給每一個可調度節點進行打分。
最後，kube-scheduler 會將 Pod 調度到得分最高的 Node 上。如果存在多個得分最高的 Node，kube-scheduler 會從中隨機選取一個。

本文主要對Kubernetes Scheduler做一個簡單介紹，讓大家理解 Pod 為什麼會被調度到特定的 Node 上。

首先來看下Pod生命周期

調度示意圖

Kubernetes Scheduler的任務是選擇一個Pod放置到Node節點。放置是一組Pod對一組Node的部分非注入式分配。

調度是一個優化問題：首先，調度程式確定可行的放置節點集合，即滿足一組給定約束的節點集合。然後，調度程式確定可行的節點集合，這是得分最高的可用節點的集合。

Kubernetes Scheduler是確保局部最優的多步調度程式，而不是確保全局最優的單步調度程式。
如下圖所示，並不保證每個可用node都被分配到pod

Kubernetes Scheduler監視Kubernetes對象存儲並選擇具有最高優先順序的未綁定Pod來執行調度步驟或搶佔步驟。

調度步驟

對於給定的Pod，如果存在至少一個節點，則啟用調度步驟，以使該節點可用於託管Pod。
如果啟用了「調度步驟」，則調度程式會將Pod綁定到可行的節點，這樣綁定將實現最高的生存能力。
如果未啟用「調度步驟」，則調度程式將嘗試執行搶佔步驟。

搶佔步驟

對於給定的Pod，如果存在至少一個節點，則啟用搶佔步驟，以便如果要刪除綁定到該節點的優先順序較低的Pod子集，則該節點可用於託管Pod。
如果啟用了搶佔步驟，則調度程式將觸發刪除綁定到一個節點的具有較低優先順序的Pod子集，搶佔步驟將造成最低的人員傷亡。
（造成的人員傷亡是根據Pod中斷預算（PDB）違規情況進行評估的）
注意，調度程式不保證觸發搶佔步驟的Pod將在後續的調度步驟中綁定到該節點。

1、過濾器

對於每個Pod，Kubernetes Scheduler都會確定可行節點的集合，這是滿足Pod約束的節點的集合。
從概念上講，Kubernetes Scheduler定義了一組過濾器函數，這些過濾器函數在給定Pod和Node的情況下，確定Node是否滿足Pod的約束。所有過濾器函數都必須對節點託管Pod產生true。

1.1 可調度性和生命周期階段（Schedulability and Lifecycle）

此過濾器功能根據節點的可調度性和生命周期階段認為該節點可行。節點條件是通過taints和tolerations考慮的（taints和tolerations後續再介紹）。

1.2 資源需求和資源可用性（Resource）

此過濾器功能根據Pod的資源要求和Node的資源可用性將Node視為可行。

1.3 節點選擇器（Node Selector）

該過濾器功能根據Pod的節點選擇器值和Node的標籤值將Node視為可行。

1.4 Node Taints and Pod Tolerations

此篩選器功能根據Pod的污點的鍵值對和Node的Tolerations的鍵值對將Node視為可行。

1.5 親和力（Required Affinity）

此過濾器功能根據Pod所需的Node Affinity條件，Pod Affinity條件和Pod Anti Affinity條件將Node視為可行。

Node Affinity
必須將Pod分配給Node，以使Node的標籤與Pod的Node Affinity Requirements匹配。此外，不得將Pod分配給節點，以使節點的標籤不符合Pod節點親和性要求。
Pod Affinity
必須將Pod分配給一個節點，以使節點上至少有一個與TopologyKey匹配的Pod符合Pod的Pod相似性要求。
Pod Anti-Affinity
必須將Pod分配給節點，以使與TopologyKey匹配的節點上沒有Pod符合Pod的Pod反親和性要求。

2、可行性

對於每個Pod，Kubernetes Scheduler都會確定可行節點的集合，這是滿足Pod約束的節點的集合。然後，Kubernetes Scheduler確定具有最高生存能力的可行節點集。
從概念上講，Kubernetes Scheduler定義了一組評估函數，給定Pod和Node，它們確定Pod和Node對的生存能力。評分相加。

2.1 首選親和力

此過濾器功能根據Pod的首選Node Affinity條款，Pod Affinity條款和Pod Anti Affinity條款對Node的生存能力進行評估。

更多詳情，請參見官網

Tags: cloudnative DevOps docker Kubernetes linux

Kubernetes Scheduler淺析