# IT明星不是夢(mèng) # kubernetes調(diào)度器學(xué)習(xí)基礎(chǔ)概

scheudler是kubernetes中的核心組件，負(fù)責(zé)為用戶聲明的pod資源選擇合適的node,同時(shí)保證集群資源的最大化利用，這里先介紹下資源調(diào)度系統(tǒng)設(shè)計(jì)里面的一些基礎(chǔ)概念

基礎(chǔ)任務(wù)資源調(diào)度

基礎(chǔ)的任務(wù)資源調(diào)度通常包括三部分：

通用的調(diào)度框架往往還會(huì)包含一個(gè)上層的集群管理器，負(fù)責(zé)針對(duì)集群中scheduler的管理和資源分配工作，同時(shí)負(fù)責(zé)scheduler集群狀態(tài)甚至resource manager的保存

資源調(diào)度設(shè)計(jì)的挑戰(zhàn)

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

傳統(tǒng)的IDC集群資源利用：
在IDC環(huán)境中我們通常希望機(jī)器利用率能夠平均,讓機(jī)器保持在某個(gè)平均利用率，然后根據(jù)資源的需要預(yù)留足夠的buffer, 來應(yīng)對(duì)集群的資源利用高峰，畢竟采購?fù)ǔ６加兄芷冢覀兗炔荒茏寵C(jī)器空著，也不能讓他跑滿(業(yè)務(wù)無法彈性)

云環(huán)境下的資源利用：
而云環(huán)境下我們可以按需分配，而且云廠商通常都支持秒級(jí)交付，那其實(shí)下面的這種資源利用率其實(shí)也可以

可以看到僅僅是環(huán)境的不一致，就可能會(huì)導(dǎo)致不同的調(diào)度結(jié)果，所有針對(duì)集群資源利用最大化這個(gè)目標(biāo)，其實(shí)會(huì)有很多的不同

調(diào)度: 任務(wù)最少等待時(shí)間與優(yōu)先級(jí)

在集群任務(wù)繁忙的時(shí)候，可能會(huì)導(dǎo)致集群資源部足以分配給當(dāng)前集群中的所有任務(wù)，在讓所有任務(wù)都能夠盡快完成的同時(shí)，我們還要保證高優(yōu)先級(jí)的任務(wù)優(yōu)先被完成

調(diào)度: 任務(wù)本地性

本地性是指在大數(shù)據(jù)處理中常用的一種機(jī)制，其核心是盡可能將任務(wù)分配到包含其任務(wù)執(zhí)行資源的節(jié)點(diǎn)上，避免數(shù)據(jù)的復(fù)制

集群: 高可用性

在調(diào)度過程中可能由于硬件、系統(tǒng)或者軟件導(dǎo)致任務(wù)的不可用，通常會(huì)由需要一些高可用機(jī)制，來保證當(dāng)前集群不會(huì)因?yàn)椴糠止?jié)點(diǎn)宕機(jī)而導(dǎo)致整個(gè)系統(tǒng)不可用

系統(tǒng): 可擴(kuò)展性

擴(kuò)展機(jī)制主要是指的，系統(tǒng)如何如何應(yīng)對(duì)業(yè)務(wù)需求的變化，提供的一種可擴(kuò)展機(jī)制，在集群默認(rèn)調(diào)度策略不滿足業(yè)務(wù)需求時(shí)，通過擴(kuò)展接口，來進(jìn)行系統(tǒng)的擴(kuò)展?jié)M足業(yè)務(wù)需求

Pod調(diào)度場(chǎng)景的挑戰(zhàn)

Pod調(diào)度場(chǎng)景其實(shí)可以看做一類特殊的任務(wù)，除了上面資源調(diào)度的挑戰(zhàn)，還有一些針對(duì)pod調(diào)度這個(gè)具體的場(chǎng)景(有些是共同的,這里通過pod來描述會(huì)比較清晰)

親和與反親和

在kubernetes中的親和性主要體現(xiàn)pod和node兩種資源，主要體現(xiàn)在兩個(gè)方面:
1.親和性: 1)pod之間的親和性 2)pod與node之間的親和性
2.反親和: 1)pod之間的反親和性? 2)pod與node之間的反親和
簡(jiǎn)單舉例：
1.pod之間的反親和: 為了保證高可用我們通常會(huì)將同一業(yè)務(wù)的多個(gè)節(jié)點(diǎn)分散在不通的數(shù)據(jù)中心和機(jī)架
2.pod與node親和性: 比如某些需要磁盤io操作的pod，我們可以調(diào)度到具有ssd的機(jī)器上，提高IO性能

多租戶與容量規(guī)劃

多租戶通常是為了進(jìn)行集群資源的隔離，在業(yè)務(wù)系統(tǒng)中，通常會(huì)按照業(yè)務(wù)線來進(jìn)行資源的隔離，同時(shí)會(huì)給業(yè)務(wù)設(shè)定對(duì)應(yīng)的容量，從而避免單個(gè)業(yè)務(wù)線資源的過度使用影響整個(gè)公司的所有業(yè)務(wù)

Zone與node選擇

zone通常是在業(yè)務(wù)容災(zāi)中常見的概念，通過將服務(wù)分散在多個(gè)數(shù)據(jù)中心，避免因?yàn)閱蝹€(gè)數(shù)據(jù)中心故障導(dǎo)致業(yè)務(wù)完全不可用

因?yàn)橹坝H和性的問題，如何在多個(gè)zone中的所有node中選擇出一個(gè)合適的節(jié)點(diǎn)，則是一個(gè)比較大的挑戰(zhàn)

多樣化資源的擴(kuò)展

系統(tǒng)資源除了cpu、內(nèi)存還包括網(wǎng)絡(luò)、磁盤io、gpu等等，針對(duì)其余資源的分配調(diào)度，kubernetes還需要提供額外的擴(kuò)展機(jī)制來進(jìn)行調(diào)度擴(kuò)展的支持

資源混部

kubernetes初期是針對(duì)pod調(diào)度場(chǎng)景而生，主要其實(shí)是在線web業(yè)務(wù)，這類任務(wù)的特點(diǎn)大部分都是無狀態(tài)的，那如何針對(duì)離線場(chǎng)景的去支持離線的批處理計(jì)算等任務(wù)

kubernetes中的調(diào)度初識(shí)

中心化數(shù)據(jù)集中存儲(chǔ)

中心化的數(shù)據(jù)存儲(chǔ)

kubernetes是一個(gè)數(shù)據(jù)中心化存儲(chǔ)的系統(tǒng)，集群中的所有數(shù)據(jù)都通過apiserver存儲(chǔ)到etcd中，包括node節(jié)點(diǎn)的資源信息、節(jié)點(diǎn)上面的pod信息、當(dāng)前集群的所有pod信息，在這里其實(shí)apiserver也充當(dāng)了resource manager的角色，存儲(chǔ)所有的集群資源和已經(jīng)分配的資源

調(diào)度數(shù)據(jù)的存儲(chǔ)與獲取

kubernetes中采用了一種list watch的機(jī)制，用于集群中其他節(jié)點(diǎn)從apiserver感知數(shù)據(jù)，scheduler也采用該機(jī)制，通過在感知apiserver的數(shù)據(jù)變化，同時(shí)在本地memory中構(gòu)建一份cache數(shù)據(jù)(資源數(shù)據(jù))，來提供調(diào)度使用，即SchedulerCache

scheduler的高可用

大多數(shù)系統(tǒng)的高可用機(jī)制都是通過類似zookeeper、etcd等AP系統(tǒng)實(shí)現(xiàn)，通過臨時(shí)節(jié)點(diǎn)或者鎖機(jī)制機(jī)制來實(shí)現(xiàn)多個(gè)節(jié)點(diǎn)的競(jìng)爭(zhēng)，從而在主節(jié)點(diǎn)宕機(jī)時(shí)，能夠快速接管， scheduler自然也是這種機(jī)制，通過apiserver底層的etcd來實(shí)現(xiàn)鎖的競(jìng)爭(zhēng)，然后通過apiserver的數(shù)據(jù)，就可以保證調(diào)度器的高可用

調(diào)度器內(nèi)部組成

調(diào)度隊(duì)列

當(dāng)從apiserver感知到要調(diào)度的pod的時(shí)候,scheduler會(huì)根據(jù)pod的優(yōu)先級(jí)，來講其加入到內(nèi)部的一個(gè)優(yōu)先級(jí)隊(duì)列中，后續(xù)調(diào)度的時(shí)候，會(huì)先獲取優(yōu)先級(jí)比較高的pod來進(jìn)行優(yōu)先滿足調(diào)度

這里還有一個(gè)點(diǎn)就是如果優(yōu)先調(diào)度了優(yōu)先級(jí)比較低的pod，其實(shí)在后續(xù)的搶占過程中，也會(huì)被驅(qū)逐出去

調(diào)度與搶占調(diào)度

前面提到過搶占,kubernetes默認(rèn)會(huì)對(duì)所有的pod來嘗試進(jìn)行調(diào)度，當(dāng)集群資源部滿足的時(shí)候，則會(huì)嘗試搶占調(diào)度，通過搶占調(diào)度，為高優(yōu)先級(jí)的pod來進(jìn)行優(yōu)先調(diào)度 其核心都是通過調(diào)度算法實(shí)現(xiàn)即ScheduleAlgorithm

這里的調(diào)度算法實(shí)際上是一堆調(diào)度算法和調(diào)度配置的集合

外部擴(kuò)展機(jī)制

scheduler extender是k8s對(duì)調(diào)度器的一種擴(kuò)展機(jī)制，我們可以定義對(duì)應(yīng)的extender,在對(duì)應(yīng)資源的調(diào)度的時(shí)候，k8s會(huì)檢查對(duì)應(yīng)的資源，如果發(fā)現(xiàn)需要調(diào)用外部的extender,則將當(dāng)前的調(diào)度數(shù)據(jù)發(fā)送給extender,然后匯總調(diào)度數(shù)據(jù)，決定最終的調(diào)度結(jié)果

內(nèi)部擴(kuò)展機(jī)制

上面提到調(diào)度算法是一組調(diào)度算法和調(diào)度配置的集合，kubernetes scheduler framework是則是一個(gè)框架聲明對(duì)應(yīng)插件的接口，從而支持用戶編寫自己的plugin,來影響調(diào)度決策，個(gè)人感覺這并不是一種好的機(jī)制，因?yàn)橐薷拇a，或者通過修改kubernetes scheduler啟動(dòng)來進(jìn)行自定義插件的加載

調(diào)度基礎(chǔ)架構(gòu)

結(jié)合上面所說的就得到了一個(gè)最簡(jiǎn)單的架構(gòu)，主要調(diào)度流程分為如下幾部分：
0.通過apiserver來進(jìn)行主節(jié)點(diǎn)選舉，成功者進(jìn)行調(diào)度業(yè)務(wù)流程處理
1.通過apiserver感知集群的資源數(shù)據(jù)和pod數(shù)據(jù)，更新本地schedulerCache
2.通過apiserver感知用戶或者controller的pod調(diào)度請(qǐng)求，加入本地調(diào)度隊(duì)列
3.通過調(diào)度算法來進(jìn)行pod請(qǐng)求的調(diào)度，分配合適的node節(jié)點(diǎn)，此過程可能會(huì)發(fā)生搶占調(diào)度
4.將調(diào)度結(jié)果返回給apiserver,然后由kubelet組件進(jìn)行后續(xù)pod的請(qǐng)求處理

這是一個(gè)最簡(jiǎn)單的調(diào)度流程和基礎(chǔ)的組件模塊，所以沒有源碼,后續(xù)這個(gè)系列會(huì)詳細(xì)分析每個(gè)關(guān)鍵的調(diào)度數(shù)據(jù)結(jié)構(gòu)和一些有趣的調(diào)度算法的具體實(shí)現(xiàn)，祝我好運(yùn)，good luck

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