kubernetes負載均衡包括集群外負載均衡和集群內負載均衡，專業術語叫南北流量和東西流量，本文主要講述集群內負載均衡（東西流量），本文第一部分會講述kubernetes組件總覽，第二部分會講述kuber-scheduler是什么，第三部分會講述kuber-scheduler核心概念，第四部分會講述kuber-scheduler是如何實作負載均衡調度的，最后一部分會講述kuber-scheduler的高可用選舉機制，在講到高可用和分部署集群leader選舉時，會對知識點做適當遷移應用，引申一下，

一、Kubernetes組件總覽

1、kubectl：命令列方式操作Kubernetes API Server

2、client-go：編程式客戶端

3、kube-apiserver：暴露資源組/資源版本/資源

4、kube-controller-manager（高可用）：管理節點（Node）、Pod副本、服務、端點（Endpoint）、命名空間（Namespace）、服務賬戶（ServiceAccount）、資源定額（ResourceQuota）等

5、kube-scheduler（高可用）：監控Pod資源物件和Node資源物件，為一個Pod資源物件找到合適的節點并在該節點上運行，

6、kubelet：接收、處理、上報kube-apiserver組件下發的任務

7、kube-proxy：監控kube-apiserver的服務和端點資源變化，并通過iptables/ipvs等配置負載均衡器，為一組Pod提供統一的TCP/UDP流量轉發和負載均衡功能，

二、什么是kube-scheduler

kube-scheduler用來監控Pod資源物件和Node資源物件，為一個Pod資源物件找到合適的節點并在該節點上運行，在整個系統中承擔了“承上啟下”的重要功能，“承上”是指它負責接收Controller Manager創建的新Pod，為其安排一個落腳的“家”——目標Node；“啟下”是指安置作業完成后，目標Node上的kubelet服務行程接管后繼作業，負責Pod生命周期中的“下半生”，

三、kube-scheduler核心概念

1、優先級與搶占機制

Pod資源物件實作了兩種機制，包括優先級（Priority）與搶占（Preempt）機制，通過Pod資源物件的優先級可控制kube-scheduler的調度決策，被驅逐走的低優先級的Pod資源物件會重新進入調度佇列并等待再次選擇合適的節點Node，在生產環境中，可以對不同業務進行分級，重要業務可擁有高優先級策略，以提升重要業務的可用性，

搶占機制的搶占演算法函式的運行流程如下：

（1）、判斷當前Pod資源物件是否有資格搶占其他Pod資源物件所在的節點，

（2）、從預選調度失敗的節點中嘗試找到能夠調度成功的節點串列（潛在的節點串列），

（3）、從潛在的節點串列中嘗試找到能夠搶占成功的節點串列（驅逐的節點串列），

（4）、從驅逐的節點串列中選擇一個節點用于最終被搶占的節點（被搶占節點），

（5）、獲取被搶占節點上的所有NominatedPods串列，

需要注意的是，當集群面對資源短缺的壓力時，高優先級的Pod將依賴于調度程式搶占低優先級的Pod的方式進行調度，這樣可以優先保證高優先級的業務運行，因此建議不要禁用搶占機制，

kube-scheduler優先級與搶占機制的場景示例如下圖所示，在SchedulingQueue調度佇列中擁有高優先級（HighPriority）、中優先級（MidPriority）、低優先級（LowPriority）3個Pod資源物件，

場景1：kube-scheduler調度器將待調度Pod資源物件按照優先級順序調度到可用節點上，

場景2：當調度Pod 3資源物件時，可用節點沒有可用資源運行Pod 3，此時，Pod 3在調度佇列中處于待調度狀態，

場景3：可用節點上已經調度了Pod 2與Pod 3資源物件，當調度Pod 1時，可用節點上已經沒有資源運行Pod 1了，此時高優先級的Pod 1將搶占低優先級的Pod 3，而被搶占后的Pod 3重新進入調度佇列等待再次選擇合適的節點，

2、親和性與反親和性

（1）、NodeAffinity節點親和性支持兩種調度策略：

（a）沒有滿足條件的節點時，資源物件創建失敗并不斷重試，該策略也被稱為硬（Hard）策略，

（b）沒有滿足條件的節點時，從其他節點中選擇較優的節點，該策略也被稱為軟（Soft）模式，

（2）、PodAffinity資源物件親和性支持兩種調度策略：

（a）沒有滿足條件的節點時，資源物件創建失敗并不斷重試，該策略也被稱為硬（Hard）策略，

（b）沒有滿足條件的節點時，從其他節點中選擇較優的節點，該策略也被稱為軟（Soft）模式，

（3）、PodAntiAffinity（Pod資源物件反親和性）支持兩種調度策略：

（a）沒有滿足條件的節點時，資源物件創建失敗并不斷重試，該策略也被稱為硬（Hard）策略，

（b）沒有滿足條件的節點時，從其他節點中選擇較優的節點，該策略也被稱為軟（Soft）模式，

下面講述親和性和反親和性的使用場景，

1、節點親和性適用場景：

（1）調度到指定機房，

（2）調度到具有GPU硬體資源的節點上，

（3）調度到I/O密集型的節點上，

2、Pod物件資源親和性適用場景：

（1）調度到同一主機，

（2）調度到同一硬體集群，

（3）調度到同一機房，

其目的就是縮短網路傳輸延時，增加性能，

3、Pod資源物件反親和性適用場景：

避免有同一標簽的Pod資源調度到同一個節點，一般用于容災，實作高可用，

這種負載均衡方式本質是7層負載均衡，

需要注意的是，因為親和性和反親和性需要大量邏輯處理，在超過百個節點的集群，不要使用親和性和反親和性調度，

3、bind系結機制

bind（系結）操作是將通過調度演算法計算出來的最佳節點與Pod資源物件進行系結，該程序是異步操作，無須等待bind操作完成即可進入下一輪的調度周期，

此操作之后，運行Pod資源物件的作業交給系結節點上的kubelet組件，實作啟下的承接，

四、kube-scheduler是怎樣實作搶占式調度的

1、默認所有Pod的優先級都為0，設定優先級的方式是在yaml檔案里，kind設定為 PriorityClass，value的值越高，優先級越高，

yaml示例如下：

apiVersion: scheduling.k8s.io/v1

kind: PriorityClass

metadata:

    name: high-priority

value: 100000

globalDefault: false

description: "This priority class should be used for hello service pods only."

2、組件架構設計

3、組件啟動流程

4、組件調度流程

五、kuber-scheduler的高可用選舉機制

分布式集群的高可用，都離不開選舉，

常見分布式選舉場景包括：

（1）主從，如MySQL，Redis，kafka，Zookeeper，

（2）對等，如Eureka，

常見選舉演算法原理包括：

（1）欺負演算法（最大的行程id演算法總是獲勝），

（2）環演算法，

常見的選舉演算法包括：

（1）最簡單的選舉演算法：選舉因子包括IP地址、CPU核數、記憶體大小、自定義序列號等等，不考慮選舉程序中的例外，

（2）拜占庭將軍問題：實則是一個協議問題，

（3）Paxos演算法.

（4）Raft分布式選舉演算法，

（5）Zookeeper，ZooKeeper Atomic Broadcast（ZAB，ZooKeeper原子訊息廣播協議），

在Kubernetes集群中，允許同時運行多個kube-scheduler節點，其中正常作業的只有一個kube-scheduler節點（即領導者節點），其他kube-scheduler節點為候選（Candidate）節點并處于阻塞狀態，使用的選舉演算法為：創建鎖標識-簡單選舉演算法，

kube-scheduler組件在Etcd上實作分布式鎖的原理如下，

（1）分布式鎖依賴于Etcd上的一個key，key的操作都是原子操作，將key作為分布式鎖，它有兩種狀態——存在和不存在，

（2）key（分布式鎖）不存在時：多節點中的一個節點成功創建該key（獲得鎖）并寫入自身節點的資訊，獲得鎖的節點被稱為領導者節點，領導者節點會定時更新（續約）該key的資訊，

（3）key（分布式鎖）存在時：其他節點處于阻塞狀態并定時獲取鎖，這些節點被稱為候選節點，候選節點定時獲取鎖的程序如下：定時獲取key的資料，驗證資料中領導者租約是否到期，如果未到期則不能搶占它，如果已到期則更新key并寫入自身節點的資訊，更新成功則成為領導者節點，

附錄參考：

1、《Kubernetes原始碼剖析》，鄭東旭

2、《Kubernetes進階實戰》，馬永亮

3、《Kubernetes權威指南：從Docker到Kubernetes實踐全接觸（第4版）》，龔正等

4、分布式選舉演算法