【云駐共創】華為云原生之Kubernetes高級調度器原理詳解（華為云 kubernetes）

前言

《云原生王者之路集訓營》是華為云云原生團隊精心打磨的云原生學習技術公開課，分為黃金、鉆石、王者三個階段，幫助廣大技術愛好者快速掌握云原生相關技能。本課程為黃金課程的第三課，由容器基礎設施團隊，容器批量計算架構師William Wang主講，為大家深入講解Kubernetes調度流程原理以及典型調度算法。

目標學員：計算機、軟件工程等專業的大學生，涉及Kubernetes、Istio等技術的應用開發者，其他的云原生技術興趣愛好。學完本課程后，您將能夠：了解Kubernetes調度器的工作原理及典型的調度算法；理解常見的Kubernetes的高級調度特性；理解華為云 Volcano 的典型批量調度算法。

一 kubernetes scheduling

1.1 kubernetes調度模式

調度器是主節點上的組件，該組件監視那些新創建的未指定運行節點的 Pod，并選擇節點讓 Pod 在特定Node上面運行。

1.2 kubernetes default schedule 特點

kube-scheduler 是 Kubernetes 集群的默認調度器，并且是集群控制面的一部分，kube-scheduler 在設計上是允許用戶自己編寫調度組件并替換原有的 kube-scheduler。

對每一個新創建的 Pod 或者是未被調度的 Pod，kube-scheduler 會選擇一個最優的 Node 去運行這個 Pod。然而，Pod 內的每一個容器對資源都有不同的需求，而且 Pod 本身也有不同的資源需求。因此，Pod 在被調度到 Node 上之前，根據這些特定的資源調度需求，需要對集群中的 Node 進行一次過濾。

在一個集群中，滿足一個 Pod 調度請求的所有 Node 稱之為 可調度節點。如果沒有任何一個 Node 能滿足 Pod 的資源請求，那么這個 Pod 將一直停留在未調度狀態直到調度器能夠找到合適的 Node。

調度器先在集群中找到一個 Pod 的所有可調度節點，然后根據一系列函數對這些可調度節點打分，然后選出其中得分最高的 Node 來運行 Pod。之后，調度器將這個調度決定通知給 kube-apiserver，這個過程叫做綁定。

在做調度決定時需要考慮的因素包括：單獨和整體的資源請求、硬件/軟件/策略限制、親和以及反親和要求、數據局域性、負載間的干擾等等。

1.3 調度框架和調度流程

Informer list/watch資源變化，更新queue和cache;NextPod()從待調度隊列獲取隊首的Pod;

從cache中獲取Node列表;

針對Pod和NodeList執行Predicate算法,過濾掉不合適的節點;

針對Pod和NodeList執行Priority算法,給節點打分;

根據打分，計算出得分最高的節點;

當高優先級的Pod沒有找到合適的節點時,調度器嘗試為其搶占優先級低的Pod;

當調度器為Pod選擇了一個合適的節點時,通過Bind將Pod和節點進行綁定;

通過cache機制可以對在進行執行Predicate的時候提升效率。

在節點綁定bind操作不是這直接操作apiserver的bind，而是在緩存至執行bind操作node的pod信息。之后啟動golang的協程異步向apiserver發請求，這種機制可以大大加快調度器處理pod的速度和效率。

1.3 調度策略與算法

Predicates，篩選不合格的節點。

預選階段：排除完全不符合運行這個 POD 的節點、例如資源最低要求、資源最高限額、端口是否被占用。

Priorities

優選階段：基于一系列的算法函數計算出每個節點的優先級，按照優先級排序，取得分最高的 node。

選中階段：如果優選階段產生多個結果，那么隨機挑選一個節點。

優選：調度器會為 Pod 從所有可調度節點中選取一個最合適的 Node。根據當前啟用的打分規則，調度器會給每一個可調度節點進行打分。最后，kube-scheduler 會將 Pod 調度到得分最高的 Node 上。如果存在多個得分最高的 Node，kube-scheduler 會從中隨機選取一個。

優先級選項包括：

LeastRequestedPriority ：通過計算 CPU 和 Memory 的使用率來決定權重，使用率越低權重越高。換句話說，這個優先級指標傾向于資源使用比例更低的節點 ；

BalancedResourceAllocation ：節點上 CPU 和 Memory 使用率越接近，權重越高。這個應該和上面的一起使用，不應該單獨使用；

ImageLocalityPriority ：傾向于已經有要使用鏡像的節點，鏡像總大小值越大，權重越高

通過算法對所有的優先級項目和權重進行計算，得出最終的結果。

二 Kubernetes的高級調度特性

2.1 kubernetes中的Label，selector機制

kubernetes中的Label，selector機制通常用于對Pod進行過濾，分離和篩選。

任意的metadata，所有API對象都有Label，通常用來標記“身份”，可以查詢時用selectors過濾

類似SQL 'select .. where... '

Label是kubernetes系統中的一個重要概念。它的作用就是在資源上添加標識，用來對它們進行區分和選擇。Label的特點:

一個Label會以key/value鍵值對的形式附加到各種對象上，如Node、Pod、Service等等。

一個資源對象可以定義任意數量的Label，同一個Label也可以被添加到任意數量的資源對象上去。

Label通常在資源對象定義時確定，當然也可以在對象創建后勃態添加或者刪除。

可以通過Label實現資源的多維度分組，以便靈活、方便地進行資源分配、調度、配置、部署等管理工作。

Label用于給某個資源對象定義標識

Label Selector用于查詢和篩選擁有某些標簽的資源對象

App:標識app的名稱

Phase：表示運行環境

Role：表示角色

可以通過App，Role進行組合進行pod的調度。

2.2 Node Affinity

希望pod可以調度到一些特定的節點上，有些node支持gpu或性能比較好。通過selector機制，可以將pod運行在某些選定的節點上。

2.3 Pod Affinity

POD 和 POD 出于高效的通信這種需求，所以需要將 POD 和 POD 組織在同一臺機器，同一個機房，例如：LNMT 如果能運行在同一個主機上更好。想把一組 POD 運行在一起，使用節點親和性就可以實現，為了達成這個目的，我們需要：把節點標簽精心編排，希望在一起運行的 POD，就使用同一組標簽選擇器來選擇節點，這種方式需要管理節點標簽和 POD 親和性才能做到。

想把一組 POD 運行在一起，使用 POD 親和性，我們可以設置 POD 對某個 POD 的親和性，那么比如：LNMT，那么 MySQL 和 Tomcat 可以設置為更加親和 Ngninx 所在的主機或機柜，所以必須有個前提就是 POD 和 POD 怎么才是最近的，這個標準是什么，也就是什么是同一位置，怎么才能知道 node 和 node 是在一個機柜。所以可以為同一個機柜的 node 節點打上相同的標簽。

MySQL 和 Tomcat 一定不能和 Nginx 運行在一起，這就是反親和性。

POD 對其他 POD 的親和性，

詳見：kubectl explain pods.spec.affinity.podAffinity

podAffinity