kube-scheduler是 kubernetes 系統的核心組件之一，主要負責整個集群資源的調度功能，根據特定的調度算法和策略，將 Pod 調度到最優的工作節點上面去，從而更加合理、更加充分的利用集群的資源，這也是我們選擇使用 kubernetes 一個非常重要的理由。如果一門新的技術不能幫助企業節約成本、提供效率，我相信是很難推進的。

調度流程

默認情況下，kube-scheduler 提供的默認調度器能夠滿足我們絕大多數的要求，我們前面和大家接觸的示例也基本上用的默認的策略，都可以保證我們的 Pod 可以被分配到資源充足的節點上運行。但是在實際的線上項目中，可能我們自己會比 kubernetes 更加了解我們自己的應用，比如我們希望一個 Pod 只能運行在特定的幾個節點上，或者這幾個節點只能用來運行特定類型的應用，這就需要我們的調度器能夠可控。

kube-scheduler 是 kubernetes 的調度器，它的主要作用就是根據特定的調度算法和調度策略將 Pod 調度到合適的 Node 節點上去，是一個獨立的二進制程序，啟動之后會一直監聽 API Server，獲取到 PodSpec.NodeName 為空的 Pod，對每個 Pod 都會創建一個 binding。

這個過程在我們看來好像比較簡單，但在實際的生產環境中，需要考慮的問題就有很多了：

• 如何保證全部的節點調度的公平性？要知道并不是說有節點資源配置都是一樣的
• 如何保證每個節點都能被分配資源？
• 集群資源如何能夠被高效利用？
• 集群資源如何才能被最大化使用？
• 如何保證 Pod 調度的性能和效率？
• 用戶是否可以根據自己的實際需求定制自己的調度策略？

考慮到實際環境中的各種復雜情況，kubernetes 的調度器采用插件化的形式實現，可以方便用戶進行定制或者二次開發，我們可以自定義一個調度器并以插件形式和 kubernetes 進行集成。

kubernetes 調度器的源碼位于 kubernetes/pkg/scheduler 中，大體的代碼目錄結構如下所示：(不同的版本目錄結構可能不太一樣)

kubernetes/pkg/scheduler
-- scheduler.go ? ? ? ? //調度相關的具體實現
|-- algorithm
| ? |-- predicates ? ? ?//節點篩選策略
| ? |-- priorities ? ? ?//節點打分策略
|-- algorithmprovider
| ? |-- defaults ? ? ? ? //定義默認的調度器

其中 Scheduler 創建和運行的核心程序，對應的代碼在 pkg/scheduler/scheduler.go，如果要查看kube-scheduler的入口程序，對應的代碼在 cmd/kube-scheduler/scheduler.go。

調度主要分為以下幾個部分：

• 首先是預選過程，過濾掉不滿足條件的節點，這個過程稱為Predicates
• 然后是優選過程，對通過的節點按照優先級排序，稱之為Priorities
• 最后從中選擇優先級最高的節點，如果中間任何一步驟有錯誤，就直接返回錯誤

Predicates階段首先遍歷全部節點，過濾掉不滿足條件的節點，屬于強制性規則，這一階段輸出的所有滿足要求的 Node 將被記錄并作為第二階段的輸入，如果所有的節點都不滿足條件，那么 Pod 將會一直處于 Pending 狀態，直到有節點滿足條件，在這期間調度器會不斷的重試。

所以我們在部署應用的時候，如果發現有 Pod 一直處于 Pending 狀態，那么就是沒有滿足調度條件的節點，這個時候可以去檢查下節點資源是否可用。

Priorities階段即再次對節點進行篩選，如果有多個節點都滿足條件的話，那么系統會按照節點的優先級(priorites)大小對節點進行排序，最后選擇優先級最高的節點來部署 Pod 應用。

下面是調度過程的簡單示意圖：

更詳細的流程是這樣的：

首先，客戶端通過 API Server 的 REST API 或者 kubectl 工具創建 Pod 資源

API Server 收到用戶請求后，存儲相關數據到 etcd 數據庫中

調度器監聽 API Server 查看為調度(bind)的 Pod 列表，循環遍歷地為每個 Pod 嘗試分配節點，這個分配過程就是我們上面提到的兩個階段：

• 預選階段(Predicates)，過濾節點，調度器用一組規則過濾掉不符合要求的 Node 節點，比如 Pod 設置了資源的 request，那么可用資源比 Pod 需要的資源少的主機顯然就會被過濾掉
• 優選階段(Priorities)，為節點的優先級打分，將上一階段過濾出來的 Node 列表進行打分，調度器會考慮一些整體的優化策略，比如把 Deployment 控制的多個 Pod 副本分布到不同的主機上，使用最低負載的主機等等策略

經過上面的階段過濾后選擇打分最高的 Node 節點和 Pod 進行 binding 操作，然后將結果存儲到 etcd 中最后被選擇出來的 Node 節點對應的 kubelet 去執行創建 Pod 的相關操作

其中Predicates過濾有一系列的算法可以使用，我們這里簡單列舉幾個：

• PodFitsResources：節點上剩余的資源是否大于 Pod 請求的資源
• PodFitsHost：如果 Pod 指定了 NodeName，檢查節點名稱是否和 NodeName 匹配
• PodFitsHostPorts：節點上已經使用的 port 是否和 Pod 申請的 port 沖突
• PodSelectorMatches：過濾掉和 Pod 指定的 label 不匹配的節點
• NoDiskConflict：已經 mount 的 volume 和 Pod 指定的 volume 不沖突，除非它們都是只讀的
• CheckNodeDiskPressure：檢查節點磁盤空間是否符合要求
• CheckNodeMemoryPressure：檢查節點內存是否夠用

除了這些過濾算法之外，還有一些其他的算法，更多更詳細的我們可以查看源碼文件：k8s.io/kubernetes/pkg/scheduler/algorithm/predicates/predicates.go。

而Priorities優先級是由一系列鍵值對組成的，鍵是該優先級的名稱，值是它的權重值，同樣，我們這里給大家列舉幾個具有代表性的選項：

• LeastRequestedPriority：通過計算 CPU 和內存的使用率來決定權重，使用率越低權重越高，當然正常肯定也是資源是使用率越低權重越高，能給別的 Pod 運行的可能性就越大
• SelectorSpreadPriority：為了更好的高可用，對同屬于一個 Deployment 或者 RC 下面的多個 Pod 副本，盡量調度到多個不同的節點上，當一個 Pod 被調度的時候，會先去查找該 Pod 對應的 controller，然后查看該 controller 下面的已存在的 Pod，運行 Pod 越少的節點權重越高
• ImageLocalityPriority：就是如果在某個節點上已經有要使用的鏡像節點了，鏡像總大小值越大，權重就越高
• NodeAffinityPriority：這個就是根據節點的親和性來計算一個權重值，后面我們會詳細講解親和性的使用方法

除了這些策略之外，還有很多其他的策略，同樣我們可以查看源碼文件：k8s.io/kubernetes/pkg/scheduler/algorithm/priorities/ 了解更多信息。每一個優先級函數會返回一個0-10的分數，分數越高表示節點越優，同時每一個函數也會對應一個表示權重的值。最終主機的得分用以下公式計算得出：

finalScoreNode = (weight1 * priorityFunc1) + (weight2 * priorityFunc2) + … + (weightn * priorityFuncn)

自定義調度

上面就是 kube-scheduler 默認調度的基本流程，除了使用默認的調度器之外，我們也可以自定義調度策略。

調度器擴展

kube-scheduler在啟動的時候可以通過 --policy-config-file參數來指定調度策略文件，我們可以根據我們自己的需要來組裝Predicates和Priority函數。選擇不同的過濾函數和優先級函數、控制優先級函數的權重、調整過濾函數的順序都會影響調度過程。

下面是官方的 Policy 文件示例：

{
  "kind" : "Policy",
  "apiVersion" : "v1",
  "predicates" : [
      {"name" : "PodFitsHostPorts"},
      {"name" : "PodFitsResources"},
      {"name" : "NoDiskConflict"},
      {"name" : "NoVolumeZoneConflict"},
      {"name" : "MatchNodeSelector"},
      {"name" : "HostName"}
  ],
  "priorities" : [
      {"name" : "LeastRequestedPriority", "weight" : 1},
      {"name" : "BalancedResourceAllocation", "weight" : 1},
      {"name" : "ServiceSpreadingPriority", "weight" : 1},
      {"name" : "EqualPriority", "weight" : 1}
  ]
}

多調度器

如果默認的調度器不滿足要求，還可以部署自定義的調度器。并且，在整個集群中還可以同時運行多個調度器實例，通過 podSpec.schedulerName 來選擇使用哪一個調度器（默認使用內置的調度器）。

apiVersion: v1
kind: Pod
metadata:
? name: nginx
? labels:
? ? app: nginx
spec:
? schedulerName: my-scheduler ?# 選擇使用自定義調度器 my-scheduler
? containers:
? - name: nginx
? ? image: nginx:1.10

要開發我們自己的調度器也是比較容易的，比如我們這里的 my-scheduler:

• 首先需要通過指定的 API 獲取節點和 Pod
• 然后選擇phase=Pending和schedulerName=my-scheduler的pod
• 計算每個 Pod 需要放置的位置之后，調度程序將創建一個Binding
• 對象然后根據我們自定義的調度器的算法計算出最適合的目標節點

優先級調度

與前面所講的調度優選策略中的優先級（Priorities）不同，前面所講的優先級指的是節點優先級，而我們這里所說的優先級 pod priority 指的是 Pod 的優先級，高優先級的 Pod 會優先被調度，或者在資源不足低情況犧牲低優先級的 Pod，以便于重要的 Pod 能夠得到資源部署。

要定義 Pod 優先級，就需要先定義PriorityClass對象，該對象沒有 Namespace 的限制：

apiVersion: v1
kind: PriorityClass
metadata:
? name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for XYZ service pods only."

其中：

• value為 32 位整數的優先級，該值越大，優先級越高
• globalDefault用于未配置 PriorityClassName 的 Pod，整個集群中應該只有一個PriorityClass將其設置為 true

然后通過在 Pod 的spec.priorityClassName中指定已定義的PriorityClass名稱即可：

apiVersion: v1
kind: Pod
metadata:
? name: nginx
? labels:
? ? app: nginx
spec:
? containers:
? - name: nginx
? ? image: nginx
? ? imagePullPolicy: IfNotPresent
? priorityClassName: high-priority

另外一個值得注意的是當節點沒有足夠的資源供調度器調度 Pod，導致 Pod 處于 pending 時，搶占（preemption）邏輯就會被觸發。Preemption會嘗試從一個節點刪除低優先級的 Pod，從而釋放資源使高優先級的 Pod 得到節點資源進行部署。

現在我們通過下面的圖再去回顧下 kubernetes 的調度過程是不是就清晰很多了：