您目前處于：
>
>
【有容云干貨-容器系列】Kubernetes調(diào)度核心解密:從Google Borg說起
【有容云干貨-容器系列】Kubernetes調(diào)度核心解密:從Google Borg說起
2017-03-03分類：Kubernetes閱讀(871)評論(0)有容云
在之前“容器生態(tài)圈腦圖大放送”文章中我們根據(jù)容器生態(tài)圈腦圖读虏，從下至上從左至右痪署，依次介紹了容器生態(tài)圈中8個組件朵锣，其中也提到Kubernetes 很钓，是一個以 Google Borg 為原型的開源項目谤饭《簦可實現(xiàn)大規(guī)模蛀柴、分布式拉一、高可用的容器集群。本篇我們重點介紹Kubernetes前世今生唧龄。
目前三大主流的容器平臺Swarm, Mesos和Kubernetes具有不同的容器調(diào)度系統(tǒng)：
Swarm的特點是直接調(diào)度Docker容器兼砖，并且提供和標準Docker API一致的API。
Mesos針對不同的運行框架采用相對獨立的調(diào)度系統(tǒng)，其中Marathon框架提供了Docker容器的原生支持讽挟。
Kubernetes則采用了Pod和Label這樣的概念把容器組合成一個個的互相存在依賴關(guān)系的邏輯單元懒叛。
相關(guān)容器被組合成Pod后被共同部署和調(diào)度，形成服務(wù)（Service）耽梅。這個是Kubernetes和Swarm薛窥，Mesos的主要區(qū)別。相對來說褐墅，Kubernetes采用這樣的方式簡化了集群范圍內(nèi)相關(guān)容器被共同調(diào)度管理的復(fù)雜性拆檬。換一種角度來看，Kubernetes采用這種方式能夠相對容易的支持更強大妥凳，更復(fù)雜的容器調(diào)度算法竟贯。
談到Kubernetes, 我們就不能不提到Google的Borg系統(tǒng)。Google的Borg系統(tǒng)群集管理器負責(zé)管理幾十萬個以上的jobs逝钥，來自幾千個不同的應(yīng)用屑那，跨多個集群，每個集群有上萬個機器艘款。它通過管理控制持际、高效的任務(wù)包裝、超售哗咆、和進程級別性能隔離實現(xiàn)了高利用率蜘欲。它支持高可用性應(yīng)用程序與運行時功能，最大限度地減少故障恢復(fù)時間晌柬，減少相關(guān)故障概率的調(diào)度策略姥份。Kubernetes的架構(gòu)設(shè)計基本上是參照了Google Borg。
本文結(jié)合Google發(fā)布的相關(guān)論文和視頻年碘，初步介紹了Google Borg的資源調(diào)度澈歉，以及它對Kubernetes容器調(diào)度系統(tǒng)產(chǎn)生的影響和未來走向。關(guān)于本文內(nèi)容的具體技術(shù)細節(jié)描述請參見Google論文以及Kubernetes文檔屿衅。
Borg調(diào)度介紹
本文的第一部分我們先介紹一下看看Borg埃难。 Google的Borg系統(tǒng)運行幾十萬個以上的任務(wù)，來自幾千個不同的應(yīng)用涤久，跨多個集群涡尘，每個集群（cell））有上萬個機器。它通過管理控制响迂、高效的任務(wù)包裝悟衩、超售、和進程級別性能隔離實現(xiàn)了高利用率栓拜。它支持高可用性應(yīng)用程序與運行時功能，最大限度地減少故障恢復(fù)時間，減少相關(guān)故障概率的調(diào)度策略幕与。以下就是Borg的系統(tǒng)架構(gòu)圖挑势。其中Scheduler負責(zé)任務(wù)的調(diào)度。
Borg調(diào)度測試
Borg對開發(fā)者隱藏了系統(tǒng)資源管理和故障處理細節(jié)啦鸣，我們來從開發(fā)者的角度來看如何在Borg中運行一萬個Hello World的任務(wù)潮饱。開發(fā)者只需要完成以下config file并且提交給Borg。
大家可以看到這樣的一個config file包含了集群名稱诫给，任務(wù)二進制, 資源要求以及Replica數(shù)量香拉。Kubernetes的YAML文件很大程度上繼承了這些配置項。
當我們提交這樣一個Hello World 任務(wù)給Borg后中狂，調(diào)度器Scheduler會根據(jù)系統(tǒng)資源自動部署一萬個Hello World任務(wù)到主機上凫碌。下圖是一個部署時間表。
可以看到經(jīng)過了3分鐘后大約一萬個任務(wù)就開始運行了胃榕。原因在于其中會有一些任務(wù)因為各種各樣的原因停止運行盛险。
下圖可以看到3分鐘后大概只有9993個任務(wù)在運行。Borg會自動進行錯誤處理并且部署新的任務(wù)勋又。
Borg調(diào)度核心
那么如何提升整個Borg系統(tǒng)的資源利用率呢苦掘？核心的解決方案就是根據(jù)主機資源合理的調(diào)度任務(wù)，提高系統(tǒng)效率楔壤。Borg主要從以下幾個方面著手：
1鹤啡、在同一臺主機上跑多個任務(wù)
2、采用最優(yōu)的打包算法
合理的把成比例的CPU蹲嚣、Memory資源分配給任務(wù)递瑰，避免資源阻塞造成浪費。下圖橙色標識的主機就是因為CPU或者內(nèi)存資源占用超過合理比例而造成另外一種資源的浪費端铛。
3泣矛、在系統(tǒng)中同時跑生成和非生產(chǎn)任務(wù)
Borg系統(tǒng)的任務(wù)分為生產(chǎn)型（Prod）任務(wù)，即高優(yōu)先級任務(wù)和非生產(chǎn)的（non-prod）任務(wù)禾蚕。大多數(shù)長期服務(wù)是Prod的您朽，大部分批處理任務(wù)是non-prod的。通常情況下换淆，生產(chǎn)型任務(wù)會保留一部分資源以應(yīng)付極端情況哗总，這些資源可以被用來跑非生產(chǎn)型應(yīng)用，當生產(chǎn)型任務(wù)需要更多資源的時候倍试，非生產(chǎn)型任務(wù)會被調(diào)度出系統(tǒng)讯屈。
4、資源回收
從下圖可以看到县习，Borg會根據(jù)現(xiàn)有資源消耗情況評估任務(wù)對未來資源的需求作為Reservation涮母，把綠色部分的資源回收再利用給那些可以忍受低質(zhì)量資源的工作谆趾。Borg調(diào)度器使用限制資源（limit）來計算Prod任務(wù)的可用性，這些Prod任務(wù)從來不依賴于回收的資源叛本，也不提供超售的資源沪蓬；對于non-prod的任務(wù)則使用了目前運行任務(wù)的Reservation，新的任務(wù)也可以被調(diào)度到回收資源上去来候。當一臺主機因為對資源預(yù)估不足時跷叉，Borg會限制或者殺掉non-prod任務(wù)。資源預(yù)估可以采用激進或者保守的策略营搅，Borg目前采用的介于兩者之間的中庸策略云挟。
Kubernetes借鑒了Borg的整體架構(gòu)思想。如下圖转质，其中Pod調(diào)度也是由Scheduler組件完成的园欣。
有一種情況下，Scheduler不參與Pod調(diào)度峭拘，那就是用NodeName指定部署主機俊庇。
Kubernetes資源調(diào)度
和Borg類似，Kubernetes的資源分為兩種屬性鸡挠』员ィ可壓縮資源（例如CPU循環(huán)，Disk I/O帶寬）都是可以被限制和被回收的拣展，對于一個Pod來說可以降低這些資源的使用量而不去殺掉Pod彭沼。不可壓縮資源（例如內(nèi)存、硬盤空間）一般來說不殺掉Pod就沒法回收备埃。未來Kubernetes會加入更多資源姓惑，如網(wǎng)絡(luò)帶寬，存儲IOPS的支持按脚。
Kubernetes調(diào)度器使用Predicates和Priorites來決定一個Pod應(yīng)該運行在哪一個節(jié)點上于毙。Predicates是強制性規(guī)則，用來形容主機匹配Pod所需要的資源辅搬，如果沒有任何主機滿足該Predicates, 則該Pod會被掛起唯沮，直到有主機能夠滿足】八欤可用的Predicates如下：
PodFitPorts：沒有任何端口沖突
PodFitsResurce：有足夠的資源運行Pod
NoDiskConflict：有足夠的空間來滿足Pod和鏈接的數(shù)據(jù)卷
MatchNodeSelector：能夠匹配Pod中的選擇器查找參數(shù)介蛉。
HostName：能夠匹配Pod中的Host參數(shù)
如果調(diào)度器發(fā)現(xiàn)有多個主機滿足條件，那么Priorities就用來判斷哪一個主機最適合運行Pod溶褪。Priorities是一個鍵值對币旧，key表示名稱，value表示權(quán)重猿妈〈盗猓可用的Priorities如下：
LeastRequestdPriority：計算Pods需要的CPU和內(nèi)存在當前節(jié)點可用資源的百分比巍虫，具有最小百分比的節(jié)點就是最優(yōu)的。
BalanceResourceAllocation：擁有類似內(nèi)存和CPU使用的節(jié)點毁葱。
ServicesSpreadingPriority：優(yōu)先選擇擁有不同Pods的節(jié)點垫言。
EqualPriority：給所有集群的節(jié)點同樣的優(yōu)先級，僅僅是為了做測試倾剿。
Kubernetes調(diào)度總結(jié)
為了對pod所運行時要求的資源做出限制，Kubernetes通過配額YAML文件來設(shè)置Resource quotas和limit蚌成，從而管理獨立Pod以及項目中所有Pod（即Namespace）的資源要求前痘。未來Kubernetes會針對Pod資源QoS做出更多功能增強，以應(yīng)對日益復(fù)雜的容器應(yīng)用需求担忧。
我們可以看到基于資源分配的任務(wù)調(diào)度是Borg和Kubernetes的核心組件芹缔。兩者的調(diào)度模塊都處于整個系統(tǒng)的核心位置。Kubernetes的調(diào)度策略源自Borg, 但是為了更好的適應(yīng)新一代的容器應(yīng)用瓶盛，以及各種規(guī)模的部署最欠，Kubernetes的調(diào)度策略相應(yīng)做的更加靈活，也更加容易理解和使用惩猫。
干貨大放送
請大家掃描以下二維碼關(guān)注本公眾號并回復(fù)【進群】芝硬，有容云小助手會第一時間拉您進入【有容云Docker技術(shù)交流群】，干貨大放送正在敬候您的光臨轧房，期待大家就技術(shù)的更多細節(jié)和疑問與群里的大牛們進行咨詢探討拌阴。掃描以下二維碼
往期回顧：【干貨-容器系列】補腦專用，容器生態(tài)圈腦圖大放送
感謝各界朋友支持奶镶，更多精彩內(nèi)容敬請期待迟赃！
上一篇:將Rancher Catalog的Prometheus模板從Cattle環(huán)境轉(zhuǎn)換到Kubernetes環(huán)境下一篇:在開啟TLS的Kubernetes1.6集群上安裝Dashboard
相關(guān)推薦
CoreOS和Docker分別要將rkt和containerd捐贈給CNCF
生產(chǎn)環(huán)境部署容器的五大挑戰(zhàn)及應(yīng)對之策
數(shù)據(jù)庫容器化的價值——反駁數(shù)據(jù)庫不適合容器化的錯誤觀點
登錄
還沒有評論，快來搶沙發(fā)吧捺信！
程序員理解的定義：Docker是Docker Inc.公司開源的一個基于Linux技術(shù)構(gòu)建容器的容器引擎酌媒，普通人能理解的定義：“沒有集裝箱，就不會有全球化残黑。
