此文是2017年5月6日Kubernetes Meetup 2017 成都站忱屑，嘉賓-IBM中國軟件架構(gòu)師馬達的主題演講《Kubernetes 中基于策略的資源分配》溜歪。IT大咖說（id：itdakashuo）作為活動的視頻合作方斯棒，經(jīng)主辦方和嘉賓授權(quán)發(fā)布没龙。

編輯：IT大咖說

閱讀字數(shù)：1322链韭，用時: 5分鐘

摘要

無論是傳統(tǒng)企業(yè)還是如今新興的互聯(lián)網(wǎng)行業(yè)，對于資源管理和調(diào)度的需求都是非常大的窍株。IBM中國系統(tǒng)部軟件架構(gòu)師馬達以Kuberntes為例民轴，全方位詳細解析它基于策略的資源調(diào)度攻柠。

嘉賓分享視頻回顧及PPT：http://suo.im/4ydQGX

User Cases：Runmultiple type of workloads in DataCenter

Mesos最主要是對資源的管理和分配。Kuberntes進行對微服務(wù)的管理和資源調(diào)度后裸。因為Spark沒有資源管理這一層瑰钮，所以我們自己做了Spark SessionScheduler，主要是做資源管理和調(diào)度微驶。

我們希望在數(shù)據(jù)中心里面跑的作業(yè)是多種多樣的浪谴，也希望能跑一些bigdate、HPC因苹、MPI這樣的作業(yè)苟耻。所以對這三塊領(lǐng)域有不同的workload的需求。

Kuberntes features & gaps

Kuberntes現(xiàn)在有一些features去解決用戶的問題扶檐。

Quota

第一個最常用的就是Quota凶杖。Quota現(xiàn)在是一個靜態(tài)的劃分，它有一個上限款筑。我更希望它是一個max智蝠，用類似云計算的想法去做。

multiple Scheduler

還有一個是multiple Scheduler奈梳，這是之前華為提出的功能杈湾。這個功能是希望在一個class里有兩個Scheduler。但Scheduler還沒有解決資源分配的問題攘须，這中間會存在比較多的問題毛秘。

no cluster-level Qos

這個最后還是只是Node-level Qos來做，沒有全局class的調(diào)度阻课。

Re- Scheduling

Kuberntes里面有一個Re- Scheduling叫挟。當(dāng)整個class運行一段時間以后， Re- Scheduling會重新從全局的范圍內(nèi)再去看一下限煞，根據(jù)現(xiàn)在的策略調(diào)一個更優(yōu)的解抹恳。

Preemption & Eviction是支持殺死一個pod。那個pod其實不會真正的刪除署驻，只是把它殺掉了奋献，然后推到Scheduling里重新來做。

現(xiàn)在Kuberntes里有好多object旺上，還有人提不同的需求去添加新的object瓶蚂，所以他們不再添加新的API默認支持的object。而是用ThirdPartyResourcs宣吱。

Kuberntes更像是基于元數(shù)據(jù)窃这，通過修改元數(shù)據(jù)來驅(qū)動彼此間的協(xié)作。Kuberntes用自己寫的Controller只要修改元數(shù)據(jù)的值就可以了征候，不需要修改interface杭攻。

ArchitectOverview

BatchJobController會拿到所有的資源祟敛，然后根據(jù)現(xiàn)在的策略和配置去算一個Queue里應(yīng)該分得多少資源。

之前在討論的時候兆解，我們是想建立一個跟space平級的概念也叫Queue馆铁，但是后來更傾向于通過namespace來做。所以BatchJobController會基于每一個namespace分配里面區(qū)域锅睛。

Quota定義了namespace中能利用的最大資源埠巨，而BatchJobController算的值則在中間來回浮動。

Pre-emption& Reclam in BatchJobController

開始第一步會重新計算namespace的值现拒。這個時候BatchJobController就要把namespace1里面多余的pod殺掉乖订，殺掉了以后再把namespace2起來。所以在整個集群里面具练，ns1和ns2彼此之間的資源就可以共享分配。

Resourcs Requipments of BatchJob

我們不僅做了資源的策略甜无，還做了作業(yè)的策略扛点。這塊大概分為幾種case。

第一種case比較常見岂丘。起一個executor陵究，里面不停的跑task。這是最簡單的一種資源分配奥帘，在創(chuàng)建起來的時候就知道作業(yè)有多少個資源的需求铜邮，可以調(diào)度。

第二個executor是根據(jù)當(dāng)前的這個請求進行動態(tài)調(diào)整寨蹋，就是可能executor里一次跑多個task松蒜，也可能每次只跑一個task，但這個task能多次跑已旧。這樣的話可以做到細力度的調(diào)度秸苗。

第三種和MPI比較像。MPI有一個比較苛刻的要求运褪，它要求所有資源都滿足了以后惊楼，它才能起來。這整個class彼此之間是fix的秸讹。

大概就是這幾種不同的部署方式和結(jié)構(gòu)檀咙。對我們來說，我們最主要看到的是這個資源的請求方式到底是什么樣璃诀，以及它的限制弧可。

具體的討論可以參考：?https://github.com/kubernetes/features/issues/269

謝謝大家！