# IT明星不是夢 # kubernetes調度器學習基礎概覽

scheudler是kubernetes中的核心組件，負責爲用戶聲明的pod資源選擇合適的node,同時保證集羣資源的最大化利用，這裏先介紹下資源調度系統設計裏面的一些基礎概念

基礎任務資源調度

基礎的任務資源調度一般包括三部分：

角色類型	功能
node	node負責具體任務的執行,同時對包彙報本身擁有的資源
resource manager	彙總當前集羣中全部node提供的資源,供上層的scheduler的調用獲取,同時根據node彙報的任務信息來進行當前集羣資源的更新
scheduler	結合當前集羣的資源和用戶提交的任務信息,選擇合適的node節點當前的資源，分配節點任務，儘量保證任務的運行

通用的調度框架每每還會包含一個上層的集羣管理器，負責針對集羣中scheduler的管理和資源分配工做，同時負責scheduler集羣狀態甚至resource manager的保存

資源調度設計的挑戰

資源：集羣資源利用的最大化與平均

傳統的IDC集羣資源利用：
在IDC環境中咱們一般但願機器利用率可以平均,讓機器保持在某個平均利用率，而後根據資源的須要預留足夠的buffer, 來應對集羣的資源利用高峯，畢竟採購一般都有周期，咱們既不能讓機器空着，也不能讓他跑滿(業務沒法彈性)

雲環境下的資源利用：
而云環境下咱們能夠按需分配，並且雲廠商一般都支持秒級交付，那其實下面的這種資源利用率其實也能夠

能夠看到僅僅是環境的不一致，就可能會致使不一樣的調度結果，全部針對集羣資源利用最大化這個目標，其實會有不少的不一樣

調度: 任務最少等待時間與優先級

在集羣任務繁忙的時候，可能會致使集羣資源部足以分配給當前集羣中的全部任務，在讓全部任務都可以儘快完成的同時，咱們還要保證高優先級的任務優先被完成

調度: 任務本地性

本地性是指在大數據處理中經常使用的一種機制，其核心是儘量將任務分配到包含其任務執行資源的節點上，避免數據的複製

集羣: 高可用性

在調度過程當中可能因爲硬件、系統或者軟件致使任務的不可用，一般會由須要一些高可用機制，來保證當前集羣不會由於部分節點宕機而致使整個系統不可用

系統: 可擴展性

擴展機制主要是指的，系統如何如何應對業務需求的變化，提供的一種可擴展機制，在集羣默認調度策略不知足業務需求時，經過擴展接口，來進行系統的擴展知足業務需求

Pod調度場景的挑戰

Pod調度場景其實能夠看作一類特殊的任務，除了上面資源調度的挑戰，還有一些針對pod調度這個具體的場景(有些是共同的,這裏經過pod來描述會比較清晰)

親和與反親和

在kubernetes中的親和性主要體現pod和node兩種資源，主要體如今兩個方面:
1.親和性: 1)pod之間的親和性 2)pod與node之間的親和性
2.反親和: 1)pod之間的反親和性  2)pod與node之間的反親和
簡單舉例：
1.pod之間的反親和: 爲了保證高可用咱們一般會將同一業務的多個節點分散在不通的數據中心和機架
2.pod與node親和性: 好比某些須要磁盤io操做的pod，咱們能夠調度到具備ssd的機器上，提升IO性能

多租戶與容量規劃

多租戶一般是爲了進行集羣資源的隔離，在業務系統中，一般會按照業務線來進行資源的隔離，同時會給業務設定對應的容量，從而避免單個業務線資源的過分使用影響整個公司的全部業務

Zone與node選擇

zone一般是在業務容災中常見的概念，經過將服務分散在多個數據中心，避免由於單個數據中心故障致使業務徹底不可用

由於以前親和性的問題，如何在多個zone中的全部node中選擇出一個合適的節點，則是一個比較大的挑戰

多樣化資源的擴展

系統資源除了cpu、內存還包括網絡、磁盤io、gpu等等，針對其他資源的分配調度，kubernetes還須要提供額外的擴展機制來進行調度擴展的支持

資源混部

kubernetes初期是針對pod調度場景而生，主要實際上是在線web業務，這類任務的特色大部分都是無狀態的，那如何針對離線場景的去支持離線的批處理計算等任務

kubernetes中的調度初識

中心化數據集中存儲

中心化的數據存儲

kubernetes是一個數據中心化存儲的系統，集羣中的全部數據都經過apiserver存儲到etcd中，包括node節點的資源信息、節點上面的pod信息、當前集羣的全部pod信息，在這裏其實apiserver也充當了resource manager的角色，存儲全部的集羣資源和已經分配的資源

調度數據的存儲與獲取

kubernetes中採用了一種list watch的機制，用於集羣中其餘節點從apiserver感知數據，scheduler也採用該機制，經過在感知apiserver的數據變化，同時在本地memory中構建一份cache數據(資源數據)，來提供調度使用，即SchedulerCache

scheduler的高可用

大多數系統的高可用機制都是經過相似zookeeper、etcd等AP系統實現，經過臨時節點或者鎖機制機制來實現多個節點的競爭，從而在主節點宕機時，可以快速接管， scheduler天然也是這種機制，經過apiserver底層的etcd來實現鎖的競爭，而後經過apiserver的數據，就能夠保證調度器的高可用

調度器內部組成

調度隊列

當從apiserver感知到要調度的pod的時候,scheduler會根據pod的優先級，來說其加入到內部的一個優先級隊列中，後續調度的時候，會先獲取優先級比較高的pod來進行優先知足調度

這裏還有一個點就是若是優先調度了優先級比較低的pod，其實在後續的搶佔過程當中，也會被驅逐出去

調度與搶佔調度

前面提到過搶佔,kubernetes默認會對全部的pod來嘗試進行調度，當集羣資源部知足的時候，則會嘗試搶佔調度，經過搶佔調度，爲高優先級的pod來進行優先調度 其核心都是經過調度算法實現即ScheduleAlgorithm

這裏的調度算法其實是一堆調度算法和調度配置的集合

外部擴展機制

scheduler extender是k8s對調度器的一種擴展機制，咱們能夠定義對應的extender,在對應資源的調度的時候，k8s會檢查對應的資源，若是發現須要調用外部的extender,則將當前的調度數據發送給extender,而後彙總調度數據，決定最終的調度結果

內部擴展機制

上面提到調度算法是一組調度算法和調度配置的集合，kubernetes scheduler framework是則是一個框架聲明對應插件的接口，從而支持用戶編寫本身的plugin,來影響調度決策，我的感受這並非一種好的機制，由於要修改代碼，或者經過修改kubernetes scheduler啓動來進行自定義插件的加載

調度基礎架構

結合上面所說的就獲得了一個最簡單的架構，主要調度流程分爲以下幾部分：
0.經過apiserver來進行主節點選舉，成功者進行調度業務流程處理
1.經過apiserver感知集羣的資源數據和pod數據，更新本地schedulerCache
2.經過apiserver感知用戶或者controller的pod調度請求，加入本地調度隊列
3.經過調度算法來進行pod請求的調度，分配合適的node節點，此過程可能會發生搶佔調度
4.將調度結果返回給apiserver,而後由kubelet組件進行後續pod的請求處理

這是一個最簡單的調度流程和基礎的組件模塊，因此沒有源碼,後續這個系列會詳細分析每一個關鍵的調度數據結構和一些有趣的調度算法的具體實現，祝我好運，good luck

k8s源碼閱讀電子書地址: https://www.yuque.com/baxiaoshi/tyado3