Docker調度器Kubernetes使用過程-魔扣目錄

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

調度流程

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

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

Docker調度器Kubernetes使用過程

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

如何保證全部的節點調度的公平性？要知道并不是說有節點資源配置都是一樣的
如何保證每個節點都能被分配資源？
集群資源如何能夠被高效利用？
集群資源如何才能被最大化使用？
如何保證 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 應用。

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

Docker調度器Kubernetes使用過程

更詳細的流程是這樣的：

首先，客戶端通過 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 的調度過程是不是就清晰很多了：

Docker調度器Kubernetes使用過程