一、概述
調度器是kubernetes中獨特而又重要的一個模塊,獨特是因為scheduler是唯一一個以plugin形式存在的組件，重要是因為kubernetes中最重要的基礎單元pod的部署是通過scheduler完成的。
正常情況下，scheduler為pod通過算法篩選合適的node，然后綁定pod與node關系，而相應的node上的kubelet在完成綁定之后才會啟動pod，此過程中，scheduler的功能很明確，就是篩選出合適的node，如果找到了就綁定node信息，如果沒有找到，pod則會一直處於pending狀態，一旦一個合適的Node接入到kubernetes cluster，調度器會將pod調度到該Node上。
我們知道在k8s中有個非常主要的對象叫做Replication Controller，簡稱RC.在部署pod時候，通常是通過RC指定pod類型以及副本數量來實現，而並非是部署單pod。為什么需要借助RC來部署呢？首先就是快速方便，只需指定副本數量即可，RC可以部署指定數量的副本pod，另外就是一旦某個pod fail掉，RC可以通過調度器再次拉起與失敗個數相同的副本以確保running的副本個數與指定的個數一致。
這里我們可能有個疑問，既然調度器的目的是為pod篩選合適的node，那么在pod中能否指定node呢? 答案是可以的，如果在pod中指定node，則不會經過調度器，node上的kubelet會拉起pod。這時候問題又來了，沒有經過調度器的算法篩選，這個由用戶指定的node如果不滿足Pod的要求，比如資源要求，那又會出現什么樣的情況呢? 答案其實很簡單，這個pod會被kubelet設置成fail狀態，那么這么說來，kubelet會像scheduler一樣對node做一些判斷，以確保pod適合當前的node。下面我們會分析這個判斷的過程。
二、scheduler模塊分析
調度的過程分兩步，首先是做篩選(predict)，其次是排序(priorities)。篩選的過程是決定是否，排序的過程是區分優劣。算法是調度的依據，這個算法其中的一部分-GeneralPredicates也會被kubelet用到，這個在第二節中提到過。算法加載的過程比較巧妙，是通過包的引用來作為算法加載的入口的：