218      阿裏雲  技術社區[雲棲]

從0到15萬，回望京東容器集群的3年建設之路

2013年初，京東商城研發布局虛擬化技術方向。那時的我們從0起步。從幾人小團隊開始起航。

在物理機時代，應用上線等待分配物理機時間平均在一周。應用混部要看臉看顏值的，沒有隔離的應用混部如履薄冰，所以在物理機時代混部的比例平均每台物理機低於9個不同應用的tomcat實例。

從痛點入手可以極大提升新項目的落地實踐機會。即刻我們著手規劃京東虛擬化平台項目。從痛點以及當時2013-2014年的技術氛圍可以容易想到，京東是從Openstack開始，那個時代Openstack研發人員炙手可熱就像今天深度學習人才一樣。京東強大的人才自培養傳統發揮作用，在6個月內，就組建了一支14人的研發團隊，並迅速掌握了Openstack的核心代碼。

Openstack對VM支持是天生的最好，但是接入第一個核心業務，就發現了問題。業務是一個並發量非常大又對延遲要求40ms以內的0級係統，我們對VM做了所有我們能知道的優化，依然無法達到預期，一直徘徊在60ms左右，但從VM切到物理機上運行性能穩穩的在40ms以內，期間動用了多種性能定位工具，如systemtap等。 在那2周隻有黑夜和香煙的日子裏麵是漫無目的的鬱悶，團隊骨幹已經殺紅了眼做各種try。

結果是殘酷的，核心係統研發同事安慰著：兄弟，我們等你。在整個2013年夏到2014年夏，退而求其次支撐了幾百個非核心係統運行在KVM環境。在團隊看來這是一個不小的挫折和壓力。這一年是鬱悶是壓力也是積攢經驗；這一年團隊對京東業務有了極其深刻的了解，在Openstack的掌控能力已經到了極高的段位並在此期間代表京東主導了Openstack幾個BP研發。

時光來到2014年秋，公司安排研發首席架構師劉海鋒帶領虛擬化團隊，首席架構師帶來新的啟發和規劃。團隊重新出發，新的方案，新的思路。Docker進入我們的視野，那時候Docker非常單薄，單薄到隻有鏡像和對cgroup簡便的操作等功能是可用之外，其他基本是無法生產環境使用的。稍加改造做了基本性能測試，tp99可以有部分降低到40ms範圍，這就是曙光。雖然還不完美，隻是部分請求可以滿足40ms要求，但是這就是未來。

雖然有了Docker，但拿什麼來管理數以萬計的Docker容器實例？2014年秋，沒有k8s，沒有swarm，沒有……通過2013-2014年推廣KVM所了解的業務，不難發現，直接徹底按容器的方式太過脫離業務研發的現狀。作為最底層的計算層，穩定性，可靠性等質量要求極高，質量承諾堅如磐石。如果自研一套容器集群管理平台，時間是最大的成本，並且團隊積累的Openstack經驗。最終團隊選擇Openstack+Docker的架構，並定義為京東第一代容器引擎平台JDOS1.0（JD DataCenter OS）。後麵的故事京東研發同事基本是知曉。

基礎平台部推出的京東第一代容器引擎平台推廣速度極快，從2015年的起步到2016年618完成100%應用運行環境容器化。

研發上線申請計算資源由之前的一周縮短到秒級，不管是1台容器還是1千台容器，在京東IDC經過計算資源池化後隨時不限量秒級供應。京東第一代容器引擎強隔離特點，解決了研發同事再也不用靠顏值來爭取和別的業務混合部署了。所有的研發同事從部署艱難選擇求合體中解放出來，0級係統不再有VIP待遇，應用不分0級和非0級，是否混部完全依靠京東第一代容器引擎平台通過算法預測和部署之後動態調度。

平均部署應用密度提升3倍，近似可以認為物理機使用率提升3倍，帶來極大的經濟收益。在容器化過程中，我們創造的容器新世界有效借力了京東已經運行了多年的多個穩定係統，包括數據庫、緩存JIMDB、JMQ、服務框架JSF等。在容器化之前，基礎設施以物理機為主。因此，京東容器落地的第一件主要工作是基礎設施容器化，同時在應用的運維方麵，兼用了之前的配套係統。

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

京東第一代容器引擎（JDOS）1.0版本從2015年開始部署，並在10月份陸續將部分業務遷移到彈性雲平台。第一批業務包括核心和非核心係統如單品頁，圖片處理，訂單等。

JDOS1.0架構

京東第一代容器引擎基於Openstack Icehouse + Docker1.3 + OVS2.1.3架構簡單、可靠。但隨著集群規模越來越大，痛就開始顯現；

Openstack集群規模受限

很快Openstack就遇到集群規模的問題，發生嚴重的不可靠問題；如：創建容器消息在MQ傳輸過程丟失、容器狀態掛起、DB連接數過大、計算節點各種agent定時任務hang、部署升級無法核對升級結果。

京東基礎平台部團隊在Openstack領域已經深入遨遊許久，社區暫時沒有遇到這麼大規模，那研發團隊隻能自己動手創造了。如上圖，設計目標單個集群1萬台物理節點，對的，單個Openstack集群管理1萬台物理計算節點。首先改造的是MQ，原理也簡單，自己實現一個python版本的RPC（brood），解除對MQ依賴。特別是依賴MQ操作DB的全部替代使用京東自研的python版本RPC框架，對數據庫的全部操作均使用RPC自帶支持的京東JIMDB（內存緩存集群）。這樣計算節點的定時任務無需直接update數據庫，支持透明通過京東的RPC update到JIMDB。

我們采用多IDC部署方式，使用統一的全局API開放對接到上線係統。支撐業務跨IDC部署。

可運維性挑戰

單個Openstack集群京東最大是1萬台物理計算節點，最小是4K台計算節點。京東容器化戰略是非常徹底的，應用運行環境100%全部容器化。這麼多物理機和容器，運維是一個非常有意思的挑戰。在研發京東第一代容器引擎之初，即定下來一個特點可運維性，所以目前運維這幾萬台物理機和幾十萬容器的運維工程師共2人，把日常運維工作係統歸類。

• 京東第一代容器引擎擴容，一套基於chef的自動部署，在大促前集中上線擴容時候核算過，從機器上架加電完後開始計算到新的節點加入集群資源池可用的效率是 4千台物理節點/天/每人。

   

• 物理機硬件故障，值得一提的是京東統一監控平台也是基礎平台部設計研發推出。全新設計，跨IDC，基於容器部署，監控效率高效，故障信息自動收斂。特別是對硬件故障的感知特別靠譜，網卡CRC錯誤，內核信息關於硬件故障，ILO口獲得的硬件狀態等途徑，還特別與機器學習Team合作，對硬件故障智能預測，特別對磁盤故障預測收獲極大。這些信息都會自動通知到機房現場IDC同事進行處理，並自動通知受影響業務方，並預測給出恢複時間。

   

• 第一代容器引擎平台自身故障，設計之初所有組件都是無狀態，停止第一代容器引擎的組件，不影響已經正在運行容器的正常運行提供服務。

   

• 每日X光檢查所有集群。從物理機，OS，Openstack，依賴的組件，內核日誌，進程，京東第一代容器引擎的一切都檢查一遍。

性能&穩定性是最致命的

規模大之後，遇到很多低概率但是實實在在發生了性能和穩定性問題；如 mac表滿導致無法網絡通信，UDP大報文硬塞，丟包，中斷異常，係統slab集中回收性內存申請鎖住時間過長；很快我們意識到原來做容器其實是在做Linux kernel，一切性能和穩定性問題都回歸到最根本的點——Linux Kernel。

即刻組建了Linux Kernel團隊，當然最應該感謝的是京東所有研發同事，在大家的包容與嗬護下，京東第一代容器引擎才有機會不斷實踐不斷改進。特別是組建Linux Kernel團隊之前，很多性能&穩定性問題，雖然解決但是並不能知其所以然。作為京東所有業務運行依賴之基石，不之所以然是非常不踏實的。任何性能瓶頸，穩定性現象，一定能找到那段代碼，做到知其所以然。

該圖是京東一個優化slab回收策略和機製原理。大家知道容器雖然隔離了CPU、內存、各種IO，但是依然是一個內核，內核要做內存回收是統一的策略，類比到很多的資源。京東Linux Kernel團隊一條一條梳理，一點一滴建設，調優，最終維護京東Linux Kernel分支。踏實感油然而生。

至此，基礎平台部完成了京東第一代容器引擎的研發&推廣&運營。

經過近兩年的運營，容器集群團隊的技術能力也得到了業務研發團隊的普遍認可。京東已經將所有業務遷移到容器集群平台中，並且第一代容器引擎平台也順利保障了本年度618和雙11大促活動。

當下，我們生產環境中的容器數量已超過15萬，我們不知道這個規模是不是全球最大的，但能肯定的是，這應該是國內容器規模最大的。越努力，越上進。第一代容器引擎平台收獲的不僅僅是成功上線和運營，更大的收獲是研發同事對容器技術的認可和信任。

在第一代容器引擎正值壯年時，團隊又接受了新的挑戰，把京東數據庫遷移到容器環境上，把京東實時計算Storm、Spark集群遷移到容器環境上。在團隊內部，京東數據庫容器化叫CDS，同樣解決2個痛點，物理機資源利用率和申請DB速度。JDOS1.0解決這2個痛點，做得非常好。隻是做了2方麵改進，即可直接支持：

• Local disk使用SSD做了磁盤調度算法優化，更適合SSD

• 調度算法適合主從，多從的創建調度

項目很快上線，也很快見到成果收益。數據庫實例創建時間縮短到現在的1分鍾，機器資源利用率提升5倍。到16年雙11期間，70%的db實例運行在容器環境上。

當下，實時計算平台，上容器平台是水到渠成的事，資源彈性伸縮的便利性，是最大的吸引。目前第一代容器集群運行的最大Storm集群是1K容器實例，充分的容器資源伸縮，鏡像發布，極大方便實時計算平台的對部署和資源的訴求。

在完成的第一代容器引擎落地實踐中，我們更多的是使用IaaS的思維，管理VM的方式來管理容器。

這種方式有利於業務的轉變，從物理機和虛擬機上直接遷移到雲上來。但是弊端在於，我們是一種“重”型的思維，因此JDOS1.0是一個基礎設施層而不是應用平台。私有雲的彈性更多的是空殼容器的彈性伸縮，並沒有真正意義上的應用的伸縮。但是京東第一代容器引擎的實踐是非常有意義的，其意義在於把業務遷到了容器中，已經盡可能地踩過了應用容器化的坑，容器的網絡、存儲都逐漸磨合成熟。而這些都為我們後麵基於1.0的經驗，開發一個全新的應用平台打下了堅實的基礎。

不畏將來，不念過往，我們的征途是星辰大海。當JDOS1.0從一千、兩千的容器規模，逐漸增長到六萬、十萬的規模時，基礎平台部已經啟動新一代容器引擎平台研發。這次我們的目標不僅僅是一個基礎設施的管理平台，更是一個直麵應用的容器平台，整合了1.0的存儲、網絡，打通從源碼到鏡像，再到上線部署的CI/CD全流程，提供從日誌、監控、排障，終端，編排等一站式的功能。

讓研發同事專注產品快速交付，讓運維同事專注於係統線上高質量運行；京東新一代容器引擎平台已經上線，並在快速推廣階段。

新一代容器引擎項目整體架構

新一代容器引擎項目角色流程架構

版本預發布流程

新一代容器引擎平台目標體現在：

• 調度數據中心全部計算資源；

不僅僅線上生產環境的資源調度，還希望可以把整個數據中心的全部資源都統一調度，包括測試環境，預發環境，借助京東第一代容器引擎在虛擬化網絡的積累和優勢，有信心在確保網絡隔離安全情況下，在大促期間借助測試環境，預發環境的計算能力一起為大促貢獻計算能力。（測試資源，預發布資源，占總資源35%，是非常可觀的資源池）

• 開發者一站式解決平台

• 應用廣泛

不僅僅應用，數據庫，實時計算。我們還計劃支持離線計算，深度學習，中間件等係統，做數據中心計算的統一載體。

• 靈活調度

特別是搶占式調度，有效支撐離線大數據計算任務，深度學習算法訓練。基於第一代容器引擎帶來的業務100%容器化的紅利，新一代容器引擎從調度IaaS資源提升到調度應用業務為中心。

京東第一代容器引擎借助Openstack和Docker社區的力量快速上線&演進，打磨。新一代容器引擎基於k8s、Docker、OVS等等開源社區項目，京東研發經過一線大規模實踐的檢驗，目前是一個非常好的時機與社區互動，貢獻社區。京東參與CNCF-JD在社區貢獻top30，希望可以繼續多多與社區互動。把京東一線大規模實踐的經驗與社區分享，並主動開源一批生產環境正在使用的項目：

• Hades：分布式智能DNS，基於DPDK對UDP加速能力，實現一個性能極高的DNS服務；

• Cane：k8s網絡項目集中了京東在兩代容器引擎平台上高性能網絡經驗；

• JNX：京東維護的nginx分支，特別加強適應容器集群平衡切換功能，以及防刷模塊；

• JLK：京東維護的Linux kernel分支，在大規模容器實踐過程對內核的心得和改進；

• MDC：京東統一監控平台，適應應用cloud native設計注重告警聚合&收斂，集中了高效運維所需的功能支持；

• Spider：京東東西向無阻塞網絡，有效支持分布式係統在容器運行。

引路靠貴人，走路靠自己；

成長靠學習，成就靠團隊。

人生的奔跑，不在於瞬間的爆發，

而在於途中堅持。

很多時候，

成功就是多持續一分鍾！

作者介紹  鮑永成

• 京東商城基礎平台部集群技術部副總監，運營多個中大規模IaaS集群，包括京東公有雲、私有雲、混合雲等產品，在OpenStack研發&性能優化、自動化部署、KVM、Docker、分布式係統等方麵有深厚的實踐經驗。

• 曾在土豆網、思科中國研發中心（CRDC）等公司從事CDN、分布式視頻編碼、分布式文件係統等方向。

• 原文發布時間為：2017-01-03

  本文來自雲棲社區合作夥伴DBAplus

最後更新：2017-05-13 08:43:15

  上一篇：  Greenplum 最佳實踐 - 什麼時候選擇bitmap索引

  下一篇：  PostgreSQL 異步IO實測