如何理解kubernetes scheduler架構設計

這期內容當中小編將會給大家帶來有關如何理解kubernetes scheduler架構設計，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

資源調度基礎

scheudler是kubernetes中的核心組件，負責為用戶聲明的pod資源選擇合適的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的請求處理

這是一個最簡單的調度流程和基礎的組件模塊，所以沒有源碼,后續這個系列會詳細分析每個關鍵的調度數據結構和一些有趣的調度算法的具體實現。

上述就是小編為大家分享的如何理解kubernetes scheduler架構設計了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。