京東容器集群建設(shè)之路

作者：鮑永成 2017-01-10 15:22:34

在物理機(jī)時(shí)代，應(yīng)用上線等待分配物理機(jī)時(shí)間平均在一周。應(yīng)用混部要看臉看顏值的，沒有隔離的應(yīng)用混部如履薄冰，所以在物理機(jī)時(shí)代混部的比例平均每臺物理機(jī)低于9個(gè)不同應(yīng)用的tomcat實(shí)例。

從0誕生

2013年初，京東商城研發(fā)布局虛擬化技術(shù)方向。那時(shí)的我們從0起步。從幾人小團(tuán)隊(duì)開始起航。

從痛點(diǎn)入手可以極大提升新項(xiàng)目的落地實(shí)踐機(jī)會。即刻我們著手規(guī)劃京東虛擬化平臺項(xiàng)目。從痛點(diǎn)以及當(dāng)時(shí)2013-2014年的技術(shù)氛圍可以容易想到，京東是從openstack開始，那個(gè)時(shí)代openstack研發(fā)人員炙手可熱就像今天深度學(xué)習(xí)人才一樣。京東強(qiáng)大的人才自培養(yǎng)傳統(tǒng)發(fā)揮作用，在6個(gè)月內(nèi)，就組建了一支14人的研發(fā)團(tuán)隊(duì)，并迅速掌握了openstack的核心代碼。

Openstack對VM支持是天生的***，所以接入***個(gè)核心業(yè)務(wù)，就發(fā)現(xiàn)了問題。業(yè)務(wù)是一個(gè)并發(fā)量非常大又對延遲要求40ms以內(nèi)的0級系統(tǒng)，我們對VM做了所有我們能知道的優(yōu)化，依然無法達(dá)到預(yù)期，一直徘徊在60ms左右，但從VM切到物理機(jī)上運(yùn)行性能穩(wěn)穩(wěn)的在40ms以內(nèi)，期間動用了多種性能定位工具，如systemtap等。在那2周只有黑夜和香煙的日子里面是漫無目的的郁悶，團(tuán)隊(duì)骨干已經(jīng)殺紅了眼做各種try。結(jié)果是殘酷的，核心系統(tǒng)研發(fā)同事安慰著：兄弟，我們等你。在整個(gè)2013年夏到2014年夏，退而求其次支撐了幾百個(gè)非核心系統(tǒng)運(yùn)行在KVM環(huán)境。在團(tuán)隊(duì)看來這是一個(gè)不小的挫折和壓力。這一年是郁悶是壓力也是積攢經(jīng)驗(yàn);這一年團(tuán)隊(duì)對京東業(yè)務(wù)有了極其深刻的了解，在openstack的掌控能力已經(jīng)到了極高的段位并在此期間代表京東主導(dǎo)了openstack幾個(gè)BP研發(fā)。

時(shí)光來到2014年秋，公司安排研發(fā)***架構(gòu)師劉海鋒帶領(lǐng)虛擬化團(tuán)隊(duì)，***架構(gòu)師帶來新的啟發(fā)和規(guī)劃。團(tuán)隊(duì)重新出發(fā)，新的方案，新的思路。Docker進(jìn)入我們的視野，那時(shí)候docker非常單薄，單薄到只有鏡像和對cgroup簡便的操作等功能是可用之外，其他基本是無法生產(chǎn)環(huán)境使用的。稍加改造做了基本性能測試，tp99可以有部分降低到40ms范圍，這就是曙光。雖然還不***，只是部分請求可以滿足40ms要求，但是這就是未來。

雖然有了Docker，拿什么來管理數(shù)以萬計(jì)的Docker容器實(shí)例。14年秋，沒有k8s，沒有swarm，沒有，，，。通過2013—2014推廣KVM所了解的業(yè)務(wù)，不難發(fā)現(xiàn)，直接徹底按容器的方式太過脫離業(yè)務(wù)研發(fā)的現(xiàn)狀。作為***層的計(jì)算層，穩(wěn)定性，可靠性等質(zhì)量要求極高，質(zhì)量承諾堅(jiān)如磐石。如果自研一套容器集群管理平臺，時(shí)間是***的成本，并且團(tuán)隊(duì)積累的openstack經(jīng)驗(yàn)。最終團(tuán)隊(duì)選擇openstack+Docker的架構(gòu)，并定義為京東***代容器引擎平臺JDOS1.0(JD DataCenter OS)。后面的故事京東研發(fā)同事基本是知曉。

基礎(chǔ)平臺部推出的京東***代容器引擎平臺推廣速度極快，從15年的起步到到16年618完成100%應(yīng)用運(yùn)行環(huán)境容器化。

研發(fā)上線申請計(jì)算資源由之前的一周縮短到分鐘級，不管是1臺容器還是1千臺容器，在京東IDC經(jīng)過計(jì)算資源池化后隨時(shí)不限量秒級供應(yīng)。京東***代容器引擎強(qiáng)隔離特點(diǎn)，解決了研發(fā)同事再也不用靠顏值來爭取和別的業(yè)務(wù)混合部署了。所有的研發(fā)同事從部署艱難選擇求合體中解放出來，0級系統(tǒng)不再有vip待遇，應(yīng)用不分0級和非0級，是否混部完全依靠京東***代容器引擎平臺通過算法預(yù)測和部署之后動態(tài)調(diào)度。

平均部署應(yīng)用密度提升3倍，近似可以認(rèn)為物理機(jī)使用率提升3倍，帶來極大的經(jīng)濟(jì)收益。在容器化過程中，我們創(chuàng)造的容器新世界有效借力了京東已經(jīng)運(yùn)行了多年的多個(gè)穩(wěn)定系統(tǒng)，包括數(shù)據(jù)庫，緩存JIMDB，JMQ，服務(wù)框架JSF等。在容器化之前，基礎(chǔ)設(shè)施以物理機(jī)為主。因此，京東容器落地的***件主要工作是基礎(chǔ)設(shè)施容器化，同時(shí)在應(yīng)用的運(yùn)維方面，兼用了之前的配套系統(tǒng)。

當(dāng)我們向研發(fā)同事講述什么是容器的時(shí)候，常常用虛擬機(jī)作類比。在給用戶進(jìn)行普及的時(shí)候，我們可以告訴他，容器是一種輕量級的虛擬機(jī)。但是在真正的落地實(shí)踐的時(shí)候，我們要讓用戶明白這是容器，而不是虛擬機(jī)。這兩者是有本質(zhì)的區(qū)別的。虛擬機(jī)的本質(zhì)上是模擬。通過模擬物理機(jī)上的硬件，向用戶提供資源。容器的基石是經(jīng)過隔離與限制的linux進(jìn)程。容器提供的是性能損失更小的原生物理機(jī)的計(jì)算能力，容器之間唯一共享的是linux內(nèi)核。

成長之痛

京東***代容器引擎(JDOS)1.0版本從2015年開始部署，并在10月份陸續(xù)將部分業(yè)務(wù)遷移到彈性云平臺。***批業(yè)務(wù)包括核心和非核心系統(tǒng)如單品頁，圖片處理，訂單等。

JDOS1.0架構(gòu)

京東***代容器引擎基于openstack Icehouse + Docker1.3 + OVS2.1.3架構(gòu)簡單，可靠。但隨著集群規(guī)模越來越大，痛就開始顯現(xiàn)。

openstack集群規(guī)模受限

很快openstack就遇到集群規(guī)模的問題，發(fā)生嚴(yán)重的不可靠問題;如：創(chuàng)建容器消息在MQ傳輸過程丟失，容器狀態(tài)掛起，DB連接數(shù)過大，計(jì)算節(jié)點(diǎn)各種agent定時(shí)任務(wù)hang，部署升級無法核對升級結(jié)果。

京東基礎(chǔ)平臺部團(tuán)隊(duì)在openstack領(lǐng)域已經(jīng)深入遨游許久，社區(qū)暫時(shí)沒有遇到這么大規(guī)模，那研發(fā)團(tuán)隊(duì)只能自己動手創(chuàng)造了。如上圖，設(shè)計(jì)目標(biāo)單個(gè)集群1萬臺物理節(jié)點(diǎn)，對的，單個(gè)openstack集群管理1萬臺物理計(jì)算節(jié)點(diǎn)。首先改造的是MQ，原理也簡單，自己實(shí)現(xiàn)一個(gè)python版本的RPC(brood)，解除對MQ依賴。特別是依賴MQ操作DB的全部替代使用京東自研的python版本RPC框架，對數(shù)據(jù)庫的全部操作均使用RPC自帶支持的京東JIMDB(內(nèi)存緩存集群)。這樣計(jì)算節(jié)點(diǎn)的定時(shí)任務(wù)無需直接update數(shù)據(jù)庫，支持透明通過京東的RPC update到JIMDB。

我們采用多IDC部署方式，使用同一的全局API開放對接到上線系統(tǒng)。支撐業(yè)務(wù)跨IDC部署。

可運(yùn)維性挑戰(zhàn)

單個(gè)openstack集群京東***是1萬臺物理計(jì)算節(jié)點(diǎn)，最小是4K臺計(jì)算節(jié)點(diǎn)。京東容器化戰(zhàn)略是非常徹底的，應(yīng)用運(yùn)行環(huán)境100%全部容器化。這么多物理機(jī)和容器，運(yùn)維是一個(gè)非常有意思的挑戰(zhàn)。在研發(fā)京東***代容器引擎之初，即定下來一個(gè)特點(diǎn)可運(yùn)維性，所以目前運(yùn)維這幾萬臺物理機(jī)和幾十萬容器的運(yùn)維工程師共2人，把日常運(yùn)維工作系統(tǒng)歸類。

京東***代容器引擎擴(kuò)容，一套基于chef的自動部署，在大促前集中上線擴(kuò)容時(shí)候核算過，從機(jī)器上架加電完后開始計(jì)算到新的節(jié)點(diǎn)加入集群資源池可用的效率是 4千臺物理節(jié)點(diǎn)/天/每人。
物理機(jī)硬件故障，值得一提的是京東統(tǒng)一監(jiān)控平臺也是基礎(chǔ)平臺部設(shè)計(jì)研發(fā)推出。全新設(shè)計(jì)，跨IDC，基于容器部署，監(jiān)控效率高效，故障信息自動收斂。特別是對硬件故障的感知特別靠譜，網(wǎng)卡CRC錯(cuò)誤，內(nèi)核信息關(guān)于硬件故障，ILO口獲得的硬件狀態(tài)等途徑，還特別與機(jī)器學(xué)習(xí)Team合作，對硬件故障智能預(yù)測，特別對磁盤故障預(yù)測收獲極大。這些信息都會自動通知到機(jī)房現(xiàn)場IDC同事進(jìn)行處理，并自動通知受影響業(yè)務(wù)方，并預(yù)測給出恢復(fù)時(shí)間。
新一代容器引擎平臺自身故障，設(shè)計(jì)之初所有組件都是無狀態(tài)，停止新一代容器引擎的組件，不影響已經(jīng)正在運(yùn)行容器的正常運(yùn)行提供服務(wù)。
每日X光檢查所有集群。從物理機(jī)，OS，openstack，依賴的組件，內(nèi)核日志，進(jìn)程，京東***代容器引擎的一切都檢查一遍。

性能&穩(wěn)定性是最致命的

規(guī)模大之后，遇到很多低概率但是實(shí)實(shí)在在發(fā)生了性能和穩(wěn)定性問題;如 mac表滿導(dǎo)致無法網(wǎng)絡(luò)通信，UDP大報(bào)文硬塞，丟包，中斷異常，系統(tǒng)slab集中回收性內(nèi)存申請鎖住時(shí)間過長;很快我們意識到原來做容器其實(shí)是在做Linux kernel，一切性能和穩(wěn)定性問題都回歸到最根本的點(diǎn)—Linux kernel。

即刻組建了Linux Kernel團(tuán)隊(duì)，當(dāng)然最應(yīng)該感謝的是京東所有研發(fā)同事，在大家的包容與呵護(hù)下，京東***代容器引擎才有機(jī)會不斷實(shí)踐不斷改進(jìn)。特別是組建Linux Kernel團(tuán)隊(duì)之前，很多性能&穩(wěn)定性問題，雖然解決但是并不能知其所以然。作為京東所有業(yè)務(wù)運(yùn)行依賴之基石，不之所以然是非常不踏實(shí)的。任何性能瓶頸，穩(wěn)定性現(xiàn)象，一定能找到那段代碼，做到知其所以然。

該圖是京東一個(gè)優(yōu)化slab回收策略和機(jī)制原理。大家知道容器雖然隔離了CPU，內(nèi)存，各種IO，但是依然是一個(gè)內(nèi)核，內(nèi)核要做內(nèi)存回收是統(tǒng)一的策略，類比到很多的資源。京東Linux Kernel團(tuán)隊(duì)一條一條梳理，一點(diǎn)一滴建設(shè)，調(diào)優(yōu)，最終維護(hù)京東Linux Kernel分支。踏實(shí)感油然而生。

至此，基礎(chǔ)平臺部完成了京東***代容器引擎的研發(fā)&推廣&運(yùn)營。

快速發(fā)展

——15萬容器助力16年京東618大促

經(jīng)過近兩年的運(yùn)營，容器集群團(tuán)隊(duì)的技術(shù)能力也得到了業(yè)務(wù)研發(fā)團(tuán)隊(duì)的普遍認(rèn)可。京東已經(jīng)將所有業(yè)務(wù)遷移到容器集群平臺中，并且***代容器引擎平臺也順利保障了本年度618和雙11大促活動。

當(dāng)下，我們生產(chǎn)環(huán)境中的容器數(shù)量已超過15萬，我們不知道這個(gè)規(guī)模是不是全球***的，但能肯定的是，這應(yīng)該是國內(nèi)容器規(guī)模***的。越努力，越上進(jìn)。***代容器引擎平臺收獲的不僅僅是成功上線和運(yùn)營，更大的收獲是研發(fā)同事對容器技術(shù)的認(rèn)可和信任。

在***代容器引擎正直壯年時(shí)候，團(tuán)隊(duì)又接受新的挑戰(zhàn)，把京東數(shù)據(jù)庫遷移到容器環(huán)境上，把京東實(shí)時(shí)計(jì)算storm，spark集群遷移到容器環(huán)境上。在團(tuán)隊(duì)內(nèi)部，京東數(shù)據(jù)庫容器化叫CDS，同樣解決2個(gè)痛點(diǎn)，物理機(jī)資源利用率和申請DB速度。JDOS1.0解決這2個(gè)痛點(diǎn)，做的非常好。只是做了2方面改進(jìn)，即可直接支持：

Local disk使用SSD做了磁盤調(diào)度算法優(yōu)化，更適合SSD
調(diào)度算法適合主從，多從的創(chuàng)建調(diào)度

項(xiàng)目很快上線，也很快見到成果收益。數(shù)據(jù)庫實(shí)例創(chuàng)建時(shí)間縮短到現(xiàn)在的1分鐘，機(jī)器資源利用率提升5倍。到16年雙11期間，70%的db實(shí)例運(yùn)行在容器環(huán)境上。

當(dāng)下，實(shí)時(shí)計(jì)算平臺，上容器平臺是水到渠成的事，資源彈性伸縮的便利性，是***的吸引。目前***代容器集群運(yùn)行的***storm集群是1K容器實(shí)例，充分的容器資源伸縮，鏡像發(fā)布，極大方便實(shí)時(shí)計(jì)算平臺的對部署和資源的訴求。

回望-不忘初心

在完成的***代容器引擎落地實(shí)踐中，我們更多的是使用IAAS的思維，管理VM的方式來管理容器。

這種方式有利于業(yè)務(wù)的轉(zhuǎn)變，從物理機(jī)和虛擬機(jī)上直接遷移到云上來。但是弊端在于，我們是一種“重”型的思維，因此JDOS1.0是一個(gè)基礎(chǔ)設(shè)施層而不是應(yīng)用平臺。私有云的彈性更多的是空殼容器的彈性伸縮，并沒有真正意義上的應(yīng)用的伸縮。但是京東***代容器引擎的實(shí)踐是非常有意義的，其意義在于把業(yè)務(wù)遷到了容器中，已經(jīng)盡可能的踩過了應(yīng)用容器化的坑，容器的網(wǎng)絡(luò)、存儲都逐漸磨合成熟。而這些都為我們后面基于1.0的經(jīng)驗(yàn)，開發(fā)一個(gè)全新的應(yīng)用平臺打下了堅(jiān)實(shí)的基礎(chǔ)。

不畏將來，不念過往，我們的征途是星辰大海。當(dāng)JDOS1.0從一千、兩千的容器規(guī)模，逐漸增長到六萬、十萬的規(guī)模時(shí)，基礎(chǔ)平臺部已經(jīng)啟動新一代容器引擎平臺研發(fā)。這次我們的目標(biāo)不僅僅是一個(gè)基礎(chǔ)設(shè)施的管理平臺，更是一個(gè)直面應(yīng)用的容器平臺，整合了1.0的存儲、網(wǎng)絡(luò)，打通從源碼到鏡像，再到上線部署的CI/CD全流程，提供從日志、監(jiān)控、排障，終端，編排等一站式的功能。

讓研發(fā)同事專注產(chǎn)品快速交付，讓運(yùn)維同事專注于系統(tǒng)線上高質(zhì)量運(yùn)行;京東新一代容器引擎平臺已經(jīng)上線，并在快速推廣階段。

新一代容器引擎項(xiàng)目在原1.0基礎(chǔ)上，支持應(yīng)用研發(fā)上線全流程：應(yīng)用構(gòu)建、鏡像倉庫、配置中心、應(yīng)用上線、運(yùn)維、監(jiān)控、日志、排障等。

新一代容器引擎項(xiàng)目架構(gòu)

版本預(yù)發(fā)布

新一代容器引擎平臺目標(biāo)體現(xiàn)在：

調(diào)度數(shù)據(jù)中心全部計(jì)算資源;

不僅僅線上生產(chǎn)環(huán)境的資源調(diào)度，還希望可以把整個(gè)數(shù)據(jù)中心的全部資源都統(tǒng)一調(diào)度，包括測試環(huán)境，預(yù)發(fā)環(huán)境，借助京東***代容器引擎在虛擬化網(wǎng)絡(luò)的積累和優(yōu)勢，有信心在確保網(wǎng)絡(luò)隔離安全情況下，在大促期間借助測試環(huán)境，預(yù)發(fā)環(huán)境的計(jì)算能力一起為大促貢獻(xiàn)計(jì)算能力。

開發(fā)者一站式解決平臺

應(yīng)用廣泛

不僅僅應(yīng)用，數(shù)據(jù)庫，實(shí)時(shí)計(jì)算。我們還計(jì)劃支持離線計(jì)算，深度學(xué)習(xí)，中間件等系統(tǒng)，做數(shù)據(jù)中心計(jì)算的統(tǒng)一載體。

靈活調(diào)度

特別是搶占式調(diào)度，有效支撐離線大數(shù)據(jù)計(jì)算任務(wù)，深度學(xué)習(xí)算法訓(xùn)練。基于***代容器引擎帶來的業(yè)務(wù)100%容器化的紅利，新一代容器引擎從調(diào)度IaaS資源提升到調(diào)度應(yīng)用業(yè)務(wù)為中心。