Docker容器技術(shù)信息傳播和服務(wù)平臺(tái)
您目前處于：
>
>
【有容云干貨-容器系列】Kubernetes調(diào)度核心解密:從Google Borg說起
【有容云干貨-容器系列】Kubernetes調(diào)度核心解密:從Google Borg說起
2017-03-03分類：Kubernetes閱讀(871)評(píng)論(0)有容云
在之前“容器生態(tài)圈腦圖大放送”文章中我們根據(jù)容器生態(tài)圈腦圖，從下至上從左至右，依次介紹了容器生態(tài)圈中8個(gè)組件，其中也提到Kubernetes ，是一個(gè)以 Google Borg 為原型的開源項(xiàng)目?？蓪?shí)現(xiàn)大規(guī)模、分布式、高可用的容器集群。本篇我們重點(diǎn)介紹Kubernetes前世今生。
目前三大主流的容器平臺(tái)Swarm, Mesos和Kubernetes具有不同的容器調(diào)度系統(tǒng)：
Swarm的特點(diǎn)是直接調(diào)度Docker容器，并且提供和標(biāo)準(zhǔn)Docker API一致的API。
Mesos針對(duì)不同的運(yùn)行框架采用相對(duì)獨(dú)立的調(diào)度系統(tǒng)，其中Marathon框架提供了Docker容器的原生支持。
Kubernetes則采用了Pod和Label這樣的概念把容器組合成一個(gè)個(gè)的互相存在依賴關(guān)系的邏輯單元。
相關(guān)容器被組合成Pod后被共同部署和調(diào)度，形成服務(wù)（Service）。這個(gè)是Kubernetes和Swarm，Mesos的主要區(qū)別。相對(duì)來說，Kubernetes采用這樣的方式簡化了集群范圍內(nèi)相關(guān)容器被共同調(diào)度管理的復(fù)雜性。換一種角度來看，Kubernetes采用這種方式能夠相對(duì)容易的支持更強(qiáng)大，更復(fù)雜的容器調(diào)度算法。
談到Kubernetes, 我們就不能不提到Google的Borg系統(tǒng)。Google的Borg系統(tǒng)群集管理器負(fù)責(zé)管理幾十萬個(gè)以上的jobs，來自幾千個(gè)不同的應(yīng)用，跨多個(gè)集群，每個(gè)集群有上萬個(gè)機(jī)器。它通過管理控制、高效的任務(wù)包裝、超售、和進(jìn)程級(jí)別性能隔離實(shí)現(xiàn)了高利用率。它支持高可用性應(yīng)用程序與運(yùn)行時(shí)功能，最大限度地減少故障恢復(fù)時(shí)間，減少相關(guān)故障概率的調(diào)度策略。Kubernetes的架構(gòu)設(shè)計(jì)基本上是參照了Google Borg。
本文結(jié)合Google發(fā)布的相關(guān)論文和視頻，初步介紹了Google Borg的資源調(diào)度，以及它對(duì)Kubernetes容器調(diào)度系統(tǒng)產(chǎn)生的影響和未來走向。關(guān)于本文內(nèi)容的具體技術(shù)細(xì)節(jié)描述請(qǐng)參見Google論文以及Kubernetes文檔。
Borg調(diào)度介紹
本文的第一部分我們先介紹一下看看Borg。 Google的Borg系統(tǒng)運(yùn)行幾十萬個(gè)以上的任務(wù)，來自幾千個(gè)不同的應(yīng)用，跨多個(gè)集群，每個(gè)集群（cell））有上萬個(gè)機(jī)器。它通過管理控制、高效的任務(wù)包裝、超售、和進(jìn)程級(jí)別性能隔離實(shí)現(xiàn)了高利用率。它支持高可用性應(yīng)用程序與運(yùn)行時(shí)功能，最大限度地減少故障恢復(fù)時(shí)間，減少相關(guān)故障概率的調(diào)度策略。以下就是Borg的系統(tǒng)架構(gòu)圖。其中Scheduler負(fù)責(zé)任務(wù)的調(diào)度。
Borg調(diào)度測(cè)試
Borg對(duì)開發(fā)者隱藏了系統(tǒng)資源管理和故障處理細(xì)節(jié)，我們來從開發(fā)者的角度來看如何在Borg中運(yùn)行一萬個(gè)Hello World的任務(wù)。開發(fā)者只需要完成以下config file并且提交給Borg。
大家可以看到這樣的一個(gè)config file包含了集群名稱，任務(wù)二進(jìn)制, 資源要求以及Replica數(shù)量。Kubernetes的YAML文件很大程度上繼承了這些配置項(xiàng)。
當(dāng)我們提交這樣一個(gè)Hello World 任務(wù)給Borg后，調(diào)度器Scheduler會(huì)根據(jù)系統(tǒng)資源自動(dòng)部署一萬個(gè)Hello World任務(wù)到主機(jī)上。下圖是一個(gè)部署時(shí)間表。
可以看到經(jīng)過了3分鐘后大約一萬個(gè)任務(wù)就開始運(yùn)行了。原因在于其中會(huì)有一些任務(wù)因?yàn)楦鞣N各樣的原因停止運(yùn)行。
下圖可以看到3分鐘后大概只有9993個(gè)任務(wù)在運(yùn)行。Borg會(huì)自動(dòng)進(jìn)行錯(cuò)誤處理并且部署新的任務(wù)。
Borg調(diào)度核心
那么如何提升整個(gè)Borg系統(tǒng)的資源利用率呢？核心的解決方案就是根據(jù)主機(jī)資源合理的調(diào)度任務(wù)，提高系統(tǒng)效率。Borg主要從以下幾個(gè)方面著手：
1、在同一臺(tái)主機(jī)上跑多個(gè)任務(wù)
2、采用最優(yōu)的打包算法
合理的把成比例的CPU、Memory資源分配給任務(wù)，避免資源阻塞造成浪費(fèi)。下圖橙色標(biāo)識(shí)的主機(jī)就是因?yàn)镃PU或者內(nèi)存資源占用超過合理比例而造成另外一種資源的浪費(fèi)。
3、在系統(tǒng)中同時(shí)跑生成和非生產(chǎn)任務(wù)
Borg系統(tǒng)的任務(wù)分為生產(chǎn)型（Prod）任務(wù)，即高優(yōu)先級(jí)任務(wù)和非生產(chǎn)的（non-prod）任務(wù)。大多數(shù)長期服務(wù)是Prod的，大部分批處理任務(wù)是non-prod的。通常情況下，生產(chǎn)型任務(wù)會(huì)保留一部分資源以應(yīng)付極端情況，這些資源可以被用來跑非生產(chǎn)型應(yīng)用，當(dāng)生產(chǎn)型任務(wù)需要更多資源的時(shí)候，非生產(chǎn)型任務(wù)會(huì)被調(diào)度出系統(tǒng)。
4、資源回收
從下圖可以看到，Borg會(huì)根據(jù)現(xiàn)有資源消耗情況評(píng)估任務(wù)對(duì)未來資源的需求作為Reservation，把綠色部分的資源回收再利用給那些可以忍受低質(zhì)量資源的工作。Borg調(diào)度器使用限制資源（limit）來計(jì)算Prod任務(wù)的可用性，這些Prod任務(wù)從來不依賴于回收的資源，也不提供超售的資源；對(duì)于non-prod的任務(wù)則使用了目前運(yùn)行任務(wù)的Reservation，新的任務(wù)也可以被調(diào)度到回收資源上去。當(dāng)一臺(tái)主機(jī)因?yàn)閷?duì)資源預(yù)估不足時(shí)，Borg會(huì)限制或者殺掉non-prod任務(wù)。資源預(yù)估可以采用激進(jìn)或者保守的策略，Borg目前采用的介于兩者之間的中庸策略。
Kubernetes借鑒了Borg的整體架構(gòu)思想。如下圖，其中Pod調(diào)度也是由Scheduler組件完成的。
有一種情況下，Scheduler不參與Pod調(diào)度，那就是用NodeName指定部署主機(jī)。
Kubernetes資源調(diào)度
和Borg類似，Kubernetes的資源分為兩種屬性?？蓧嚎s資源（例如CPU循環(huán)，Disk I/O帶寬）都是可以被限制和被回收的，對(duì)于一個(gè)Pod來說可以降低這些資源的使用量而不去殺掉Pod。不可壓縮資源（例如內(nèi)存、硬盤空間）一般來說不殺掉Pod就沒法回收。未來Kubernetes會(huì)加入更多資源，如網(wǎng)絡(luò)帶寬，存儲(chǔ)IOPS的支持。
Kubernetes調(diào)度器使用Predicates和Priorites來決定一個(gè)Pod應(yīng)該運(yùn)行在哪一個(gè)節(jié)點(diǎn)上。Predicates是強(qiáng)制性規(guī)則，用來形容主機(jī)匹配Pod所需要的資源，如果沒有任何主機(jī)滿足該P(yáng)redicates, 則該P(yáng)od會(huì)被掛起，直到有主機(jī)能夠滿足?？捎玫腜redicates如下：
PodFitPorts：沒有任何端口沖突
PodFitsResurce：有足夠的資源運(yùn)行Pod
NoDiskConflict：有足夠的空間來滿足Pod和鏈接的數(shù)據(jù)卷
MatchNodeSelector：能夠匹配Pod中的選擇器查找參數(shù)。
HostName：能夠匹配Pod中的Host參數(shù)
如果調(diào)度器發(fā)現(xiàn)有多個(gè)主機(jī)滿足條件，那么Priorities就用來判斷哪一個(gè)主機(jī)最適合運(yùn)行Pod。Priorities是一個(gè)鍵值對(duì)，key表示名稱，value表示權(quán)重?？捎玫腜riorities如下：
LeastRequestdPriority：計(jì)算Pods需要的CPU和內(nèi)存在當(dāng)前節(jié)點(diǎn)可用資源的百分比，具有最小百分比的節(jié)點(diǎn)就是最優(yōu)的。
BalanceResourceAllocation：擁有類似內(nèi)存和CPU使用的節(jié)點(diǎn)。
ServicesSpreadingPriority：優(yōu)先選擇擁有不同Pods的節(jié)點(diǎn)。
EqualPriority：給所有集群的節(jié)點(diǎn)同樣的優(yōu)先級(jí)，僅僅是為了做測(cè)試。
Kubernetes調(diào)度總結(jié)
為了對(duì)pod所運(yùn)行時(shí)要求的資源做出限制，Kubernetes通過配額YAML文件來設(shè)置Resource quotas和limit，從而管理獨(dú)立Pod以及項(xiàng)目中所有Pod（即Namespace）的資源要求。未來Kubernetes會(huì)針對(duì)Pod資源QoS做出更多功能增強(qiáng)，以應(yīng)對(duì)日益復(fù)雜的容器應(yīng)用需求。
我們可以看到基于資源分配的任務(wù)調(diào)度是Borg和Kubernetes的核心組件。兩者的調(diào)度模塊都處于整個(gè)系統(tǒng)的核心位置。Kubernetes的調(diào)度策略源自Borg, 但是為了更好的適應(yīng)新一代的容器應(yīng)用，以及各種規(guī)模的部署，Kubernetes的調(diào)度策略相應(yīng)做的更加靈活，也更加容易理解和使用。
干貨大放送
請(qǐng)大家掃描以下二維碼關(guān)注本公眾號(hào)并回復(fù)【進(jìn)群】，有容云小助手會(huì)第一時(shí)間拉您進(jìn)入【有容云Docker技術(shù)交流群】，干貨大放送正在敬候您的光臨，期待大家就技術(shù)的更多細(xì)節(jié)和疑問與群里的大牛們進(jìn)行咨詢探討。掃描以下二維碼
往期回顧：【干貨-容器系列】補(bǔ)腦專用，容器生態(tài)圈腦圖大放送
感謝各界朋友支持，更多精彩內(nèi)容敬請(qǐng)期待！
上一篇:將Rancher Catalog的Prometheus模板從Cattle環(huán)境轉(zhuǎn)換到Kubernetes環(huán)境下一篇:在開啟TLS的Kubernetes1.6集群上安裝Dashboard
相關(guān)推薦
CoreOS和Docker分別要將rkt和containerd捐贈(zèng)給CNCF
Docker容器的自動(dòng)化監(jiān)控實(shí)現(xiàn)
生產(chǎn)環(huán)境部署容器的五大挑戰(zhàn)及應(yīng)對(duì)之策
數(shù)據(jù)庫容器化的價(jià)值——反駁數(shù)據(jù)庫不適合容器化的錯(cuò)誤觀點(diǎn)
容器網(wǎng)絡(luò)：盤點(diǎn)，解釋與分析
登錄
還沒有評(píng)論，快來搶沙發(fā)吧！
程序員理解的定義：Docker是Docker Inc.公司開源的一個(gè)基于Linux技術(shù)構(gòu)建容器的容器引擎，普通人能理解的定義：“沒有集裝箱，就不會(huì)有全球化。
