導(dǎo)讀
服務(wù)器資源利用率較低泳桦，IT基礎(chǔ)設(shè)施的總擁有成本（TCO）逐年上漲汤徽，一直是困擾很多企業(yè)的難題。隨著云原生技術(shù)的發(fā)展灸撰，Kubernetes逐漸成為數(shù)據(jù)中心的一項(xiàng)基礎(chǔ)設(shè)施谒府，將在/離線業(yè)務(wù)統(tǒng)一使用Kubernetes調(diào)度編排日漸成熟。本議題結(jié)合網(wǎng)易輕舟在這一領(lǐng)域的工作實(shí)踐浮毯，介紹如何基于Kubernetes通過混合部署完疫，在不影響在線業(yè)務(wù)的前提下將CPU利用率提高到50%以上，大幅降低企業(yè)數(shù)據(jù)中心成本债蓝。
前言
數(shù)據(jù)分析顯示壳鹤，數(shù)據(jù)中心成本中，服務(wù)器采購(gòu)成本占比超過50% 1, 2 饰迹，而全球服務(wù)器平均資源利用率不到20%芳誓，并且服務(wù)器一般3~5年就會(huì)淘汰余舶，需要購(gòu)置新服務(wù)器，造成了巨大的成本浪費(fèi)锹淌。
如果數(shù)據(jù)中心或者機(jī)房規(guī)模較小匿值，服務(wù)器數(shù)量有限，很少有人會(huì)去關(guān)注資源利用率這個(gè)問題赂摆。因?yàn)樵谛∫?guī)模場(chǎng)景下挟憔，耗費(fèi)人力、物力想辦法提高服務(wù)器資源利用率并不會(huì)獲得太高的收益烟号。如果數(shù)據(jù)中心規(guī)模比較大绊谭，提升數(shù)據(jù)中心資源利用率則能夠顯著降低成本、帶來巨大收益褥符，所以國(guó)內(nèi)外的大型互聯(lián)網(wǎng)公司龙誊，很早就開始投入大量的人力物力進(jìn)行較多的探索實(shí)踐。
近幾年喷楣，隨著云音樂趟大、嚴(yán)選、傳媒铣焊、有道等互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展逊朽，網(wǎng)易內(nèi)部的服務(wù)器數(shù)量不斷攀升，而實(shí)際資源利用率又比較低曲伊，IT基礎(chǔ)設(shè)施成本問題日益嚴(yán)峻叽讳。面對(duì)日益增長(zhǎng)的業(yè)務(wù)，我們希望用最小的基礎(chǔ)設(shè)施資源成本來支撐更大的業(yè)務(wù)需求坟募。提升服務(wù)器資源利用率成為一個(gè)比較重要的解決手段岛蚤。
網(wǎng)易輕舟團(tuán)隊(duì)提出了一套基于kubernetes的業(yè)務(wù)混部方案，目前已經(jīng)在網(wǎng)易內(nèi)部得到廣泛應(yīng)用懈糯，在不影響業(yè)務(wù)SLO（service-level objective）的前提下涤妒，資源利用率得到顯著提升。
本文將從以下幾個(gè)方面逐步展開：
資源利用率現(xiàn)狀和原因分析
如何通過混部提高資源利用率
落地成果
未來展望
1.資源利用率現(xiàn)狀和原因分析
麥肯錫數(shù)據(jù)統(tǒng)計(jì)顯示赚哗，整個(gè)業(yè)界的服務(wù)器平均利用率大約為6%她紫，而Gartner的估計(jì)要樂觀一些，大概在12%屿储。國(guó)內(nèi)一些銀行的數(shù)據(jù)中心的利用率大概在5%左右 3 贿讹。
而造成利用率比較低的原因主要有以下三個(gè)方面：
不同類型的業(yè)務(wù)劃分了獨(dú)立的服務(wù)器資源池
絕大多數(shù)企業(yè)在構(gòu)建數(shù)據(jù)中心或者機(jī)房的時(shí)候，對(duì)于在線服務(wù)（latency-sensitive service）和離線服務(wù)（batch job）是單獨(dú)采購(gòu)機(jī)器并且分開管理部署的够掠，各自采用獨(dú)立的資源調(diào)度管理系統(tǒng)（比如離線業(yè)務(wù)使用Yarn調(diào)度民褂，在線業(yè)務(wù)Mesos調(diào)度），從服務(wù)器采購(gòu)、規(guī)劃到業(yè)務(wù)調(diào)度層面都是完全隔離的助赞。
圖1(b) 是Google 專門運(yùn)行在線應(yīng)用的2萬臺(tái)服務(wù)器CPU利用率分布圖买羞，大部分處于30%左右。圖1? 是Google專門運(yùn)行批處理作業(yè)的2萬臺(tái)服務(wù)器CPU利用率分布圖雹食，大部分在75%左右 3畜普。
在線業(yè)務(wù)SLO要求較高，為了保證服務(wù)的性能和可靠性群叶，通常會(huì)申請(qǐng)大量的冗余資源吃挑，因此，會(huì)導(dǎo)致資源利用率很低街立、浪費(fèi)比較嚴(yán)重舶衬。而離線業(yè)務(wù)，通常關(guān)注吞吐量赎离，SLO要求不高逛犹，容忍一定的失敗，資源利用率很高梁剔。
假如將離線業(yè)務(wù)跑在在線業(yè)務(wù)的機(jī)器上虽画，充分利用在線業(yè)務(wù)的空閑資源，那是不是就能節(jié)省下離線業(yè)務(wù)的服務(wù)器成本了呢荣病？
服務(wù)的reserved資源和實(shí)際used資源存在較大Gap码撰，通常overprovision
業(yè)務(wù)通常是有波峰和波谷的，用戶在部署服務(wù)時(shí)个盆，為了保證服務(wù)的性能和穩(wěn)定性通常都會(huì)按照波峰申請(qǐng)資源脖岛，即 provision resource for the peek load，但是波峰的時(shí)間可能很短颊亮。另外柴梆，也有相當(dāng)一部分用戶對(duì)于自己服務(wù)的資源使用情況不是很了解，在申請(qǐng)資源時(shí)具有較大盲目性终惑，但是通常也是申請(qǐng)過量資源而不是申請(qǐng)的過少轩性。
圖2 是推特?cái)?shù)據(jù)中心資源使用情況，可以看到cpu利用率大約在20%左右狠鸳，但是用戶申請(qǐng)了60%左右的cpu資源；內(nèi)存利用率在40%左右悯嗓，但是用戶申請(qǐng)了80%左右的內(nèi)存資源 4件舵。
服務(wù)A已申請(qǐng)的但是實(shí)際沒有使用的資源，即使是空閑的脯厨，其他服務(wù)也是不能夠使用的铅祸。Reserved - Used差值越大，資源浪費(fèi)越多。所以我們應(yīng)該如何去縮小Reserved - Used的差值临梗，從而提高業(yè)務(wù)部署密度和資源利用率呢涡扼？
業(yè)務(wù)負(fù)載具有明顯的時(shí)間上的波峰波谷，處于波谷時(shí)盟庞，空閑資源其他服務(wù)無法使用
很多面向用戶的在線服務(wù)具有明顯的波峰波谷吃沪，比如白天用戶使用量較多，資源利用率相應(yīng)較高什猖，但是夜間用戶使用量較少票彪，資源利用率相應(yīng)較低。夜間空閑出來的資源不狮，其實(shí)都是浪費(fèi)的降铸。那夜間空閑出來的這部分資源是不是也可以用來跑離線業(yè)務(wù)呢？
2.在/離線業(yè)務(wù)混部
在線業(yè)務(wù)（latency-sensitive service）：和用戶存在交互的摇零、并且對(duì)交互延時(shí)敏感的應(yīng)用稱為在線業(yè)務(wù)推掸。例如：網(wǎng)絡(luò)搜索服務(wù)、即時(shí)通訊服務(wù)驻仅、支付服務(wù)谅畅、游戲服務(wù)等，延遲對(duì)于這些服務(wù)的服務(wù)質(zhì)量至關(guān)重要雾家，故稱為“延時(shí)敏感”铃彰，在線業(yè)務(wù)通常有著嚴(yán)格的SLO（service-level objective）。
離線業(yè)務(wù)(batch job)：和用戶不存在交互芯咧，對(duì)延時(shí)不敏感的應(yīng)用稱為離線業(yè)務(wù)牙捉。例如：Hadoop生態(tài)下的MapReduce作業(yè)、Spark作業(yè)敬飒、機(jī)器學(xué)習(xí)的訓(xùn)練作業(yè)邪铲、視頻轉(zhuǎn)碼服務(wù)等。這些作業(yè)對(duì)于其完成時(shí)間的容忍度較高无拗，故稱為“延時(shí)不敏感”带到。離線業(yè)務(wù)通常沒有嚴(yán)格的SLO 。
混合部署（co-location）：是指將在線業(yè)務(wù)和離線業(yè)務(wù)混合部署在同一集群和服務(wù)器上英染。
傳統(tǒng)的數(shù)據(jù)中心中揽惹，之所以將在/離線服務(wù)分開部署管理，實(shí)屬無奈之舉：
- 混部會(huì)帶來底層共享資源（CPU四康、內(nèi)存搪搏、網(wǎng)絡(luò)、磁盤等）的競(jìng)爭(zhēng)闪金，會(huì)導(dǎo)致在線業(yè)務(wù)性能下降疯溺，并且這種下降是不可預(yù)測(cè)的
- 在/離線服務(wù)分屬不同的研發(fā)论颅、產(chǎn)品團(tuán)隊(duì)，成本管理是分開的
- 在/離線服務(wù)使用不同的資源調(diào)度管理系統(tǒng)囱嫩，無法統(tǒng)一調(diào)度
如果能夠?qū)㈦x線服務(wù)跑在在線服務(wù)的機(jī)器上恃疯，充分利用在線服務(wù)的空閑資源，則能夠顯著提升資源利用率降低服務(wù)器成本墨闲。
隨著云原生理念今妄、容器和微服務(wù)的普及，Kubernetes 逐步統(tǒng)治了容器編排領(lǐng)域损俭，成為數(shù)據(jù)中心的基礎(chǔ)設(shè)施蛙奖。將在/離線業(yè)務(wù)統(tǒng)一使用 Kubernetes 調(diào)度管理，日漸成熟杆兵。
接下來雁仲，本章節(jié)會(huì)詳細(xì)講解如何基于 Kubernetes 實(shí)現(xiàn)在/離線業(yè)務(wù)的混部，在復(fù)雜的基礎(chǔ)設(shè)施架構(gòu)下琐脏，面對(duì)眾多的共享資源攒砖，如何實(shí)現(xiàn)多維度的資源隔離，最小化在/離線業(yè)務(wù)之間的性能干擾日裙，保證在線業(yè)務(wù)的運(yùn)行性能吹艇、提升離線業(yè)務(wù)運(yùn)行效率。
Kubernetes native feature
因?yàn)橐贙ubernetes 實(shí)現(xiàn)在/離線業(yè)務(wù)的混部昂拂，所以需要先了解 Kubernetes 有哪些功能能夠幫助實(shí)現(xiàn)混部受神，以及 Kubernetes 本身存在哪些問題。
Pod Priority
pod是有優(yōu)先級(jí)（pod priority）的格侯，相應(yīng)字段是pod.spec.priority鼻听，它表示了pod的重要程度，值越大優(yōu)先級(jí)越高联四。調(diào)度器調(diào)度的時(shí)候會(huì)優(yōu)先調(diào)度高優(yōu)先級(jí)的pod撑碴，Kubelet在驅(qū)逐過載節(jié)點(diǎn)的pod時(shí)，會(huì)優(yōu)先驅(qū)逐低優(yōu)先級(jí)的pod朝墩。
所以醉拓，可以將離線任務(wù)設(shè)置較小的pod priority。
Pod QoS
Pod有三種QoS class：
- Best Effort： 如果pod的cpu/memory資源的request和limit都沒有設(shè)置收苏，則該pod屬于Best Effort類型
- Guaranteed：如果pod的cpu/memory資源的request和limit都設(shè)置了亿卤，并且每個(gè)資源的request值等于limit值，則該pod屬于Guaranteed類型
- Burstable: 剩下的則是Burstable類型
其中鹿霸，Guaranteed pod對(duì)于 SLO 要求最高排吴，有最高的資源保證；Burstable pod對(duì)于 SLO 要求次之杜跷，僅保證 request 部分的資源；Best Effort pod 對(duì)于 SLO 要求最低，資源無法保證葛闷。
Best Effort類型pod的 OOM Score 是最大的憋槐，也就是說在發(fā)生系統(tǒng)OOM的時(shí)候，首先kill的就是Best Effort類型的pod淑趾。
當(dāng)節(jié)點(diǎn)上內(nèi)存阳仔、磁盤等非可壓縮資源負(fù)載過高時(shí)，kubelet會(huì)驅(qū)逐上面的pod扣泊，保證節(jié)點(diǎn)穩(wěn)定性近范，驅(qū)逐的順序是： Best Effort、Burstable延蟹、Guaranteed评矩。
所以，是不是可以將離線任務(wù)歸為Best Effort class 呢阱飘？
Kubelet CGroup Manager
Kubernetes 是使用 cgroups 來實(shí)現(xiàn)pod的資源限制的斥杜。
圖4 是Kubernetes cpu cgroups的層級(jí)，三種不同的顏色表示三種不同的QoS class：
- kubepods 的cpu.share 只在kubelet啟動(dòng)的時(shí)候設(shè)置一次
- besteffort和burstable的cpu.share沥匈，每隔1分鐘更新一次. 有pod創(chuàng)建刪除也會(huì)觸發(fā)更新
- pod的cpu.share和cfs quota只在創(chuàng)建時(shí)設(shè)置蔗喂，后面不再更新
圖5 是Kubernetes memory cgroups的層級(jí)，三種不同的顏色表示三種不同的QoS class：
- kubepods 的memory.limit_in_bytes 只在kubelet啟動(dòng)時(shí)設(shè)置一次
- besteffort和burstable的memory.limit_in_bytes高帖，后面不會(huì)更新
- pod的memory.limit_in_bytes只在創(chuàng)建時(shí)設(shè)置缰儿，后面不會(huì)更新
之所以在這講一下Kubernetes pod cgroups的層級(jí)組織結(jié)構(gòu)和動(dòng)態(tài)更新策略，是因?yàn)槲覀冮_發(fā)的資源隔離組件也是通過更改cgroups配置來實(shí)現(xiàn)資源隔離的散址。如果不知道Kubernetes原生的cgroups管理策略乖阵，很容易發(fā)生更新失效或者沖突，引發(fā)故障爪飘。
K8S 本身存在的問題
靜態(tài)調(diào)度
Kubernetes是使用的靜態(tài)調(diào)度义起。靜態(tài)調(diào)度是指根據(jù)容器的資源請(qǐng)求（resource request）進(jìn)行調(diào)度，而不考慮節(jié)點(diǎn)的實(shí)際負(fù)載师崎。所以默终，經(jīng)常會(huì)發(fā)生節(jié)點(diǎn)負(fù)載很低，但是調(diào)度不了新的pod上去的情況犁罩。
Kubernetes為什么會(huì)使用靜態(tài)調(diào)度呢齐蔽？因?yàn)橐獙?shí)現(xiàn)一個(gè)基于節(jié)點(diǎn)負(fù)載進(jìn)行動(dòng)態(tài)調(diào)度的通用框架是很困難的。而靜態(tài)調(diào)度實(shí)現(xiàn)簡(jiǎn)單床估、管理方便含滴，但是對(duì)于用戶的要求要高一些，如果 resource request 配置的不合理丐巫，可能會(huì)導(dǎo)致節(jié)點(diǎn)之間負(fù)載不均衡以及利用率較低谈况。
隔離性較弱
Kubernetes 是沒有區(qū)分在線業(yè)務(wù)和離線業(yè)務(wù)的勺美，當(dāng)前的cgroups層級(jí)組織結(jié)構(gòu)也很難將在/離線業(yè)務(wù)區(qū)分開，很難實(shí)現(xiàn)動(dòng)態(tài)的資源分配和動(dòng)態(tài)的資源隔離碑韵。所以赡茸，也無從談起在/離線業(yè)務(wù)的性能隔離，頂多就是不同pod之間的隔離祝闻。
而 Kubernetes 對(duì)于pod之間的資源隔離也是很弱的占卧，僅僅通過cgroups在cpu維度使用cpu.shares控制發(fā)生cpu爭(zhēng)用時(shí)的時(shí)間片分配比例，使用cfs quota限制cpu使用上限联喘；內(nèi)存維度使用memory limit in bytes限制使用上限华蜒。
如果貿(mào)然將在/離線業(yè)務(wù)混部在同一臺(tái)機(jī)器上，是無法保證在線業(yè)務(wù)的SLO的豁遭。
篇幅有限叭喜，下一篇明日同步！
如果你想提前知道他們的經(jīng)驗(yàn)總結(jié)和獨(dú)家干貨堤框，可以私信我域滥，我給你發(fā)本地文檔方便保存噢。
如果你喜歡這篇文章的話蜈抓，別忘了 轉(zhuǎn)發(fā)启绰、收藏、留言互動(dòng)沟使！
還有委可，關(guān)注我！關(guān)注我腊嗡！關(guān)注我着倾！
大佬們分別是：
張曉龍——網(wǎng)易數(shù)帆輕舟技術(shù)總監(jiān)。負(fù)責(zé)基礎(chǔ)設(shè)施研發(fā) /運(yùn)維至今燕少，在虛擬化卡者、網(wǎng)絡(luò)、容器客们、大規(guī)某缇觯基礎(chǔ)設(shè)施管理以及分布式系統(tǒng)等技術(shù)架構(gòu)有多年經(jīng)驗(yàn)，當(dāng)前主要興趣點(diǎn)在云原生技術(shù)方向底挫。
李嵐清——網(wǎng)易數(shù)帆輕舟業(yè)務(wù)部資深系統(tǒng)開發(fā)工程師恒傻。具有多年Kubernetes開發(fā)運(yùn)維經(jīng)驗(yàn)，負(fù)責(zé)在/離線業(yè)務(wù)混部建邓、容器網(wǎng)絡(luò)編排等多個(gè)項(xiàng)目盈厘，推動(dòng)和協(xié)助網(wǎng)易內(nèi)部多個(gè)業(yè)務(wù)實(shí)現(xiàn)容器化。
陳林亮——網(wǎng)易數(shù)帆輕舟資深云計(jì)算開發(fā)工程師官边。具有多年云計(jì)算開發(fā)沸手，運(yùn)維及優(yōu)化經(jīng)驗(yàn)外遇，參與開發(fā)網(wǎng)易云計(jì)算1.0至當(dāng)前3.0多個(gè)云平臺(tái)。目前專注在在/離線業(yè)務(wù)混部契吉、容器編排資源優(yōu)化等方向臀规。
