京東容器集群建設之路
從0誕生
2013年初，京東商城研發(fā)布局虛擬化技術(shù)方向。那時的我們從0起步。從幾人小團隊開始起航。
在物理機時代，應用上線等待分配物理機時間平均在一周。應用混部要看臉看顏值的，沒有隔離的應用混部如履薄冰，所以在物理機時代混部的比例平均每臺物理機低于9個不同應用的tomcat實例。
從痛點入手可以極大提升新項目的落地實踐機會。即刻我們著手規(guī)劃京東虛擬化平臺項目。從痛點以及當時2013-2014年的技術(shù)氛圍可以容易想到，京東是從openstack開始，那個時代openstack研發(fā)人員炙手可熱就像今天深度學習人才一樣。京東強大的人才自培養(yǎng)傳統(tǒng)發(fā)揮作用，在6個月內(nèi)，就組建了一支14人的研發(fā)團隊，并迅速掌握了openstack的核心代碼。
Openstack對VM支持是天生的***，所以接入***個核心業(yè)務，就發(fā)現(xiàn)了問題。業(yè)務是一個并發(fā)量非常大又對延遲要求40ms以內(nèi)的0級系統(tǒng)，我們對VM做了所有我們能知道的優(yōu)化，依然無法達到預期，一直徘徊在60ms左右，但從VM切到物理機上運行性能穩(wěn)穩(wěn)的在40ms以內(nèi)，期間動用了多種性能定位工具，如systemtap等。 在那2周只有黑夜和香煙的日子里面是漫無目的的郁悶，團隊骨干已經(jīng)殺紅了眼做各種try。結(jié)果是殘酷的，核心系統(tǒng)研發(fā)同事安慰著：兄弟，我們等你。在整個2013年夏到2014年夏，退而求其次支撐了幾百個非核心系統(tǒng)運行在KVM環(huán)境。在團隊看來這是一個不小的挫折和壓力。這一年是郁悶是壓力也是積攢經(jīng)驗;這一年團隊對京東業(yè)務有了極其深刻的了解，在openstack的掌控能力已經(jīng)到了極高的段位并在此期間代表京東主導了openstack幾個BP研發(fā)。
時光來到2014年秋，公司安排研發(fā)***架構(gòu)師劉海鋒帶領(lǐng)虛擬化團隊，***架構(gòu)師帶來新的啟發(fā)和規(guī)劃。團隊重新出發(fā)，新的方案，新的思路。Docker進入我們的視野，那時候docker非常單薄，單薄到只有鏡像和對cgroup簡便的操作等功能是可用之外，其他基本是無法生產(chǎn)環(huán)境使用的。稍加改造做了基本性能測試，tp99可以有部分降低到40ms范圍，這就是曙光。雖然還不***，只是部分請求可以滿足40ms要求，但是這就是未來。
雖然有了Docker，拿什么來管理數(shù)以萬計的Docker容器實例。14年秋，沒有k8s，沒有swarm，沒有，，，。通過2013—2014推廣KVM所了解的業(yè)務，不難發(fā)現(xiàn)，直接徹底按容器的方式太過脫離業(yè)務研發(fā)的現(xiàn)狀。作為***層的計算層，穩(wěn)定性，可靠性等質(zhì)量要求極高，質(zhì)量承諾堅如磐石。如果自研一套容器集群管理平臺，時間是***的成本，并且團隊積累的openstack經(jīng)驗。最終團隊選擇openstack+Docker的架構(gòu)，并定義為京東***代容器引擎平臺JDOS1.0(JD DataCenter OS)。后面的故事京東研發(fā)同事基本是知曉。
基礎平臺部推出的京東***代容器引擎平臺推廣速度極快，從15年的起步到到16年618完成100%應用運行環(huán)境容器化。
研發(fā)上線申請計算資源由之前的一周縮短到分鐘級，不管是1臺容器還是1千臺容器，在京東IDC經(jīng)過計算資源池化后隨時不限量秒級供應。京東***代容器引擎強隔離特點，解決了研發(fā)同事再也不用靠顏值來爭取和別的業(yè)務混合部署了。所有的研發(fā)同事從部署艱難選擇求合體中解放出來，0級系統(tǒng)不再有vip待遇，應用不分0級和非0級，是否混部完全依靠京東***代容器引擎平臺通過算法預測和部署之后動態(tài)調(diào)度。
平均部署應用密度提升3倍，近似可以認為物理機使用率提升3倍，帶來極大的經(jīng)濟收益。在容器化過程中，我們創(chuàng)造的容器新世界有效借力了京東已經(jīng)運行了多年的多個穩(wěn)定系統(tǒng)，包括數(shù)據(jù)庫，緩存JIMDB，JMQ，服務框架JSF等。在容器化之前，基礎設施以物理機為主。因此，京東容器落地的***件主要工作是基礎設施容器化，同時在應用的運維方面，兼用了之前的配套系統(tǒng)。
當我們向研發(fā)同事講述什么是容器的時候，常常用虛擬機作類比。在給用戶進行普及的時候，我們可以告訴他，容器是一種輕量級的虛擬機。但是在真正的落地實踐的時候，我們要讓用戶明白這是容器，而不是虛擬機。這兩者是有本質(zhì)的區(qū)別的。虛擬機的本質(zhì)上是模擬。通過模擬物理機上的硬件，向用戶提供資源。容器的基石是經(jīng)過隔離與限制的linux進程。容器提供的是性能損失更小的原生物理機的計算能力，容器之間唯一共享的是linux內(nèi)核。
成長之痛
京東***代容器引擎(JDOS)1.0版本從2015年開始部署，并在10月份陸續(xù)將部分業(yè)務遷移到彈性云平臺。***批業(yè)務包括核心和非核心系統(tǒng)如單品頁，圖片處理，訂單等。
JDOS1.0架構(gòu)
京東***代容器引擎基于openstack Icehouse + Docker1.3 + OVS2.1.3架構(gòu)簡單，可靠。但隨著集群規(guī)模越來越大，痛就開始顯現(xiàn)。
openstack集群規(guī)模受限
很快openstack就遇到集群規(guī)模的問題，發(fā)生嚴重的不可靠問題;如：創(chuàng)建容器消息在MQ傳輸過程丟失，容器狀態(tài)掛起，DB連接數(shù)過大，計算節(jié)點各種agent定時任務hang，部署升級無法核對升級結(jié)果。
京東基礎平臺部團隊在openstack領(lǐng)域已經(jīng)深入遨游許久，社區(qū)暫時沒有遇到這么大規(guī)模，那研發(fā)團隊只能自己動手創(chuàng)造了。如上圖，設計目標單個集群1萬臺物理節(jié)點，對的，單個openstack集群管理1萬臺物理計算節(jié)點。首先改造的是MQ，原理也簡單，自己實現(xiàn)一個python版本的RPC(brood)，解除對MQ依賴。特別是依賴MQ操作DB的全部替代使用京東自研的python版本RPC框架，對數(shù)據(jù)庫的全部操作均使用RPC自帶支持的京東JIMDB(內(nèi)存緩存集群)。這樣計算節(jié)點的定時任務無需直接update數(shù)據(jù)庫，支持透明通過京東的RPC update到JIMDB。
我們采用多IDC部署方式，使用同一的全局API開放對接到上線系統(tǒng)。支撐業(yè)務跨IDC部署。
可運維性挑戰(zhàn)
單個openstack集群京東***是1萬臺物理計算節(jié)點，最小是4K臺計算節(jié)點。京東容器化戰(zhàn)略是非常徹底的，應用運行環(huán)境100%全部容器化。這么多物理機和容器，運維是一個非常有意思的挑戰(zhàn)。在研發(fā)京東***代容器引擎之初，即定下來一個特點可運維性，所以目前運維這幾萬臺物理機和幾十萬容器的運維工程師共2人，把日常運維工作系統(tǒng)歸類。
- 京東***代容器引擎擴容，一套基于chef的自動部署，在大促前集中上線擴容時候核算過，從機器上架加電完后開始計算到新的節(jié)點加入集群資源池可用的效率是 4千臺物理節(jié)點/天/每人。
- 物理機硬件故障，值得一提的是京東統(tǒng)一監(jiān)控平臺也是基礎平臺部設計研發(fā)推出。全新設計，跨IDC，基于容器部署，監(jiān)控效率高效，故障信息自動收斂。特別是對硬件故障的感知特別靠譜，網(wǎng)卡CRC錯誤，內(nèi)核信息關(guān)于硬件故障，ILO口獲得的硬件狀態(tài)等途徑，還特別與機器學習Team合作，對硬件故障智能預測，特別對磁盤故障預測收獲極大。這些信息都會自動通知到機房現(xiàn)場IDC同事進行處理，并自動通知受影響業(yè)務方，并預測給出恢復時間。
- 新一代容器引擎平臺自身故障，設計之初所有組件都是無狀態(tài)，停止新一代容器引擎的組件，不影響已經(jīng)正在運行容器的正常運行提供服務。
- 每日X光檢查所有集群。從物理機，OS，openstack，依賴的組件，內(nèi)核日志，進程，京東***代容器引擎的一切都檢查一遍。
性能&穩(wěn)定性是最致命的
規(guī)模大之后，遇到很多低概率但是實實在在發(fā)生了性能和穩(wěn)定性問題;如 mac表滿導致無法網(wǎng)絡通信，UDP大報文硬塞，丟包，中斷異常，系統(tǒng)slab集中回收性內(nèi)存申請鎖住時間過長;很快我們意識到原來做容器其實是在做Linux kernel，一切性能和穩(wěn)定性問題都回歸到最根本的點—Linux kernel。
即刻組建了Linux Kernel團隊，當然最應該感謝的是京東所有研發(fā)同事，在大家的包容與呵護下，京東***代容器引擎才有機會不斷實踐不斷改進。特別是組建Linux Kernel團隊之前，很多性能&穩(wěn)定性問題，雖然解決但是并不能知其所以然。作為京東所有業(yè)務運行依賴之基石，不之所以然是非常不踏實的。任何性能瓶頸，穩(wěn)定性現(xiàn)象，一定能找到那段代碼，做到知其所以然。
該圖是京東一個優(yōu)化slab回收策略和機制原理。大家知道容器雖然隔離了CPU，內(nèi)存，各種IO，但是依然是一個內(nèi)核，內(nèi)核要做內(nèi)存回收是統(tǒng)一的策略，類比到很多的資源。京東Linux Kernel團隊一條一條梳理，一點一滴建設，調(diào)優(yōu)，最終維護京東Linux Kernel分支。踏實感油然而生。
至此，基礎平臺部完成了京東***代容器引擎的研發(fā)&推廣&運營。
快速發(fā)展
——15萬容器助力16年京東618大促
經(jīng)過近兩年的運營，容器集群團隊的技術(shù)能力也得到了業(yè)務研發(fā)團隊的普遍認可。京東已經(jīng)將所有業(yè)務遷移到容器集群平臺中，并且***代容器引擎平臺也順利保障了本年度618和雙11大促活動。
當下，我們生產(chǎn)環(huán)境中的容器數(shù)量已超過15萬，我們不知道這個規(guī)模是不是全球***的，但能肯定的是，這應該是國內(nèi)容器規(guī)模***的。越努力，越上進。***代容器引擎平臺收獲的不僅僅是成功上線和運營，更大的收獲是研發(fā)同事對容器技術(shù)的認可和信任。
在***代容器引擎正直壯年時候，團隊又接受新的挑戰(zhàn)，把京東數(shù)據(jù)庫遷移到容器環(huán)境上，把京東實時計算storm，spark集群遷移到容器環(huán)境上。在團隊內(nèi)部，京東數(shù)據(jù)庫容器化叫CDS，同樣解決2個痛點，物理機資源利用率和申請DB速度。JDOS1.0解決這2個痛點，做的非常好。只是做了2方面改進，即可直接支持：
- Local disk使用SSD做了磁盤調(diào)度算法優(yōu)化，更適合SSD
- 調(diào)度算法適合主從，多從的創(chuàng)建調(diào)度
項目很快上線，也很快見到成果收益。數(shù)據(jù)庫實例創(chuàng)建時間縮短到現(xiàn)在的1分鐘，機器資源利用率提升5倍。到16年雙11期間，70%的db實例運行在容器環(huán)境上。
當下，實時計算平臺，上容器平臺是水到渠成的事，資源彈性伸縮的便利性，是***的吸引。目前***代容器集群運行的***storm集群是1K容器實例，充分的容器資源伸縮，鏡像發(fā)布，極大方便實時計算平臺的對部署和資源的訴求。
回望-不忘初心
在完成的***代容器引擎落地實踐中，我們更多的是使用IAAS的思維，管理VM的方式來管理容器。
這種方式有利于業(yè)務的轉(zhuǎn)變，從物理機和虛擬機上直接遷移到云上來。但是弊端在于，我們是一種“重”型的思維，因此JDOS1.0是一個基礎設施層而不是應用平臺。私有云的彈性更多的是空殼容器的彈性伸縮，并沒有真正意義上的應用的伸縮。但是京東***代容器引擎的實踐是非常有意義的，其意義在于把業(yè)務遷到了容器中，已經(jīng)盡可能的踩過了應用容器化的坑，容器的網(wǎng)絡、存儲都逐漸磨合成熟。而這些都為我們后面基于1.0的經(jīng)驗，開發(fā)一個全新的應用平臺打下了堅實的基礎。
不畏將來，不念過往，我們的征途是星辰大海。當JDOS1.0從一千、兩千的容器規(guī)模，逐漸增長到六萬、十萬的規(guī)模時，基礎平臺部已經(jīng)啟動新一代容器引擎平臺研發(fā)。這次我們的目標不僅僅是一個基礎設施的管理平臺，更是一個直面應用的容器平臺，整合了1.0的存儲、網(wǎng)絡，打通從源碼到鏡像，再到上線部署的CI/CD全流程，提供從日志、監(jiān)控、排障，終端，編排等一站式的功能。
讓研發(fā)同事專注產(chǎn)品快速交付，讓運維同事專注于系統(tǒng)線上高質(zhì)量運行;京東新一代容器引擎平臺已經(jīng)上線，并在快速推廣階段。
新一代容器引擎項目在原1.0基礎上，支持應用研發(fā)上線全流程：應用構(gòu)建、鏡像倉庫、配置中心、應用上線、運維、監(jiān)控、日志、排障等。
新一代容器引擎項目架構(gòu)
版本預發(fā)布
新一代容器引擎平臺目標體現(xiàn)在：
調(diào)度數(shù)據(jù)中心全部計算資源;
不僅僅線上生產(chǎn)環(huán)境的資源調(diào)度，還希望可以把整個數(shù)據(jù)中心的全部資源都統(tǒng)一調(diào)度，包括測試環(huán)境，預發(fā)環(huán)境，借助京東***代容器引擎在虛擬化網(wǎng)絡的積累和優(yōu)勢，有信心在確保網(wǎng)絡隔離安全情況下，在大促期間借助測試環(huán)境，預發(fā)環(huán)境的計算能力一起為大促貢獻計算能力。
- 開發(fā)者一站式解決平臺
- 應用廣泛
不僅僅應用，數(shù)據(jù)庫，實時計算。我們還計劃支持離線計算，深度學習，中間件等系統(tǒng)，做數(shù)據(jù)中心計算的統(tǒng)一載體。
- 靈活調(diào)度
特別是搶占式調(diào)度，有效支撐離線大數(shù)據(jù)計算任務，深度學習算法訓練?；?**代容器引擎帶來的業(yè)務100%容器化的紅利，新一代容器引擎從調(diào)度IaaS資源提升到調(diào)度應用業(yè)務為中心。
【本文來自51CTO專欄作者張開濤的微信公眾號(開濤的博客)，公眾號id: kaitao-1234567】
