Scheduler 原理解析
前面深入分析了Controller Manager及它所包含的各個組件的運行機制，本節將繼續對Kubernetes中負責Pod調度的重要功能模塊—Kubernetes Scheduler的工作原理和運行機制做深入分析。
Kubernetes Scheduler在整個系統中承擔了“承上啓下”的重要功能，“承上”是指它負責接收Controller Manager創建的新Pod，爲其安排一個落腳的“家”—目標Node；“啓下”是指安置工作完成後，目標Node上的kubelet服務進程接管後繼工作，負責Pod生命週期中的“下半生”。
具體來說，Kubernetes Scheduler的作用是將待調度的Pod（API新創建的Pod、Controller Manager爲補足副本而創建的Pod等）按照特定的調度算法和調度策略綁定（Binding）到集羣中某個合適的Node上，並將綁定信息寫入etcd中。在整個調度過程中涉及三個對象，分別是待調度Pod列表、可用Node列表，以及調度算法和策略。簡單地說，就是通過調度算法調度爲待調度Pod列表中的每個Pod從Node列表中選擇一個最適合的Node。
隨後，目標節點上的kubelet通過API Server監聽到Kubernetes Scheduler產生的Pod綁定事件，然後獲取對應的Pod清單，下載Image鏡像並啓動容器。
Kubernetes Scheduler當前提供的默認調度流程分爲以下兩步。
（1）預選調度過程，即遍歷所有目標Node，篩選出符合要求的候選節點。爲此，Kubernetes內置了多種預選策略（xxx Predicates）供用戶選擇。
（2）確定最優節點，在第1步的基礎上，採用優選策略（xxx Priority）計算出每個候選節點的積分，積分最高者勝出。
Kubernetes Scheduler的調度流程是通過插件方式加載的“調度算法提供者”（AlgorithmProvider）具體實現的。一個AlgorithmProvider其實就是包括了一組預選策略與一組優先選擇策略的結構體，它包含三個參數：name string爲算法名；predicateKeys爲算法用到的預選策略集合；priorityKeys爲算法用到的優選策略集合。
Scheduler中可用的預選策略包含：NoDiskConflict、PodFitsResources、PodSelectorMatches、PodFitsHost、CheckNodeLabelPresence、CheckServiceAffinity和PodFitsPorts策略等。其默認的AlgorithmProvider加載的預選策略Predicates包括：PodFitsPorts（PodFitsPorts）、PodFitsResources（PodFitsResources）、NoDiskConflict（NoDiskConflict）、MatchNodeSelector（PodSelectorMatches）和HostName（PodFitsHost），即每個節點只有通過前面提及的5個默認預選策略後，才能初步被選中，進入下一個流程。
NoDiskConflict
判斷備選Pod的gcePersistentDisk或AWSElasticBlockStore和備選的節點中已存在的Pod是否存在衝突。檢測過程如下。
（1）首先，讀取備選Pod的所有Volume的信息（即pod.Spec.Volumes），對每個Volume執行以下步驟進行衝突檢測。
（2）如果該Volume是gcePersistentDisk，則將Volume和備選節點上的所有Pod的每個Volume都進行比較，如果發現相同的gcePersistentDisk，則返回false，表明存在磁盤衝突，檢查結束，反饋給調度器該備選節點不適合作爲備選Pod；如果該Volume是AWSElasticBlockStore，則將Volume和備選節點上的所有Pod的每個Volume都進行比較，如果發現相同的AWSElasticBlockStore，則返回false，表明存在磁盤衝突，檢查結束，反饋給調度器該備選節點不適合備選Pod。
（3）如果檢查完備選Pod的所有Volume均未發現衝突，則返回true，表明不存在磁盤衝突，反饋給調度器該備選節點適合備選Pod。
PodFitsResources
判斷備選節點的資源是否滿足備選Pod的需求，檢測過程如下。
（1）計算備選Pod和節點中已存在Pod的所有容器的需求資源（內存和CPU）的總和。
（2）獲得備選節點的狀態信息，其中包含節點的資源信息。
（3）如果在備選Pod和節點中已存在Pod的所有容器的需求資源（內存和CPU）的總和，超出了備選節點擁有的資源，則返回false，表明備選節點不適合備選Pod，否則返回true，表明備選節點適合備選Pod。
PodSelectorMatches
判斷備選節點是否包含備選Pod的標籤選擇器指定的標籤。
（1）如果Pod沒有指定spec.nodeSelector標籤選擇器，則返回true。
（2）否則，獲得備選節點的標籤信息，判斷節點是否包含備選Pod的標籤選擇器（spec.nodeSelector）所指定的標籤，如果包含，則返回true，否則返回false。、
PodFitsHost
判斷備選Pod的spec.nodeName域所指定的節點名稱和備選節點的名稱是否一致，如果一致，則返回true，否則返回false。
CheckNodeLabelPresence
如果用戶在配置文件中指定了該策略，則Scheduler會通過RegisterCustomFitPredicate方式註冊該策略。該策略用於判斷策略列出的標籤在備選節點中存在時了，是否選擇該備選節點。
（1）讀取備選節點的標籤列表信息。
（2）如果策略配置的標籤列表存在於備選節點的標籤列表中，且策略配置的presence值爲false，則返回false，否則返回true；如果策略配置的標籤列表不存在於備選節點的標籤列表中，且策略配置的presence值爲true，則返回false，否則返回ture。
CheckServiceAffinity
如果用戶在配置文件中指定了該策略，則Scheduler會通過RegisterCustomFitPredicate方法註冊該策略。該策略用於判斷備選節點是否包含策略指定的標籤，或包含和備選Pod在相同Service和Namesoace下的Pod所在節點的標籤列表。如果存在，則返回true，否則返回false。
PodFitsPorts
判斷備選Pod所用的端口列表中的端口是否在備選節點中已被佔用，如果被佔用，則返回false，否則返回true。
Scheduler中的優選策略包含：LeastRequestedPriority、CalculateNodeLabelPriority和BalancedResourceAllocation等。每個節點通過優先選擇策略時都會算出一個得分，計算各項得分，最終選出得分值最大的節點作爲優選的結果（也是調度算法的結果）。
LeastRequested Priority
該優選策略用於從備選節點列表中選出資源消耗最小的節點。
（1）計算出在所有備選節點上運行的Pod和備選Pod的CPU佔用量totalMilliCPU。
（2）計算出在所有備選節點上運行的Pod和備選Pod的內存佔用量totalMemory。
（3）計算每個節點的得分，計算規則大致如下，其中，NodeCpuCapacity爲節點CPU計算能力，NodeMemoryCapacity爲節點內存大小。
CalculateNodeLabelPriority
如果用戶在配置文件中指定了該策略，則scheduler會通過RegisterCustomPriorityFunction方法註冊該策略。該策略用於判斷策略列出的標籤在備選節點中存在時，是否選擇該備選節點。如果備選節點的標籤在優選策略的標籤列表中且優選策略的presence值爲true，或者備選節點的標籤不在優選策略的標籤列表中且優選策略的presence值爲false，則備選節點score=10，否則備選節點score=0。
BalancedResourceAllocation
該優選策略用於從備選節點列表中選出各項資源使用率最均衡的節點。
（1）計算出在所有備選節點上運行的Pod和備選Pod的CPU佔用量totalMilliCPU。
（2）計算出在所有備選節點上運行的Pod和備選Pod的內存佔用量totalMemory。
（3）計算每個節點的得分，計算規則大致如下，其中，NodeCpuCapacity爲節點的CPU計算能力，NodeMemoryCapacity爲節點的內存大小。
小結：
本節內容到此結束。