京東構建了全球最大的Kubernetes集群，沒有之一

從 2014 年開始，InfoQ 就一直在追蹤京東 618 相關的技術報道，在我們的系列文章中，你肯定也能察覺到京東在技術上的成長速度。5 年之前，每逢大促，我的朋友圈中好似有很多人在看笑話，因為在高并發大流量面前，那時的京東總是有些脆弱，特別是對于淘寶 / 天貓。

幾年時間，一晃而過。這次 618，我刻意搜索了下自己的朋友圈，發現基本沒有人再去吐槽京東『逢促必掛』的技術笑話了，轉而大家都在夸贊京東的送貨速度以及服務品質。是的，當用戶的目光聚焦到一家公司的業務本身時，這也證明他的技術已經相對成熟，起碼足以支撐業務的發展速度。也就是說，對于京東來說，技術已經不再是業務增長的瓶頸。

我現在還清晰記得自己在 2015 年 618 當天去京東總部采訪京東商城總架構師劉海鋒時的情景，他當時激情澎湃地向我介紹了京東基于 Docker 容器和 OpenStack 的彈性計算云項目的種種優勢，并笑著說，再過幾年，隨著這個項目的成熟，京東的技術人員面對大促，再也不用這么辛苦，這么緊張了。

我應該也是被他的話所感動，亦或者作為一個外行，我似乎也能理解一個技術人應有的技術信仰。所以在當時的采訪文章里，我寫下了這樣的話：京東彈性計算云項目將深刻影響京東未來幾年的基礎架構。

然而，一年之后的 2016 年京東 618，當再次采訪彈性云項目負責人鮑永成時，我們才明白，彈性云對于京東的真正價值和意義。永成說，這一年是彈性云在京東全面戰略落地的重要一年，它也將全面提升京東的基礎設施利用效率。

緊接著的 2017 年，京東的業務，以及相關的中間件已經全部遷移到了彈性云之上，并且永成表示，他們開始了新的技術升級，將會引入 Google 開源的 Kubernetes 技術來重構相關技術棧，并且自己也會為開源添磚加瓦，回饋社區。

2018 年 4 月底，我看到了京東宣布加入 CNCF 云原生計算基金會的消息。這時，我才明白，京東的 Kubernetes 集群已經是全球最大了，并且沒有之一。

感慨之余，我又翻出了過去幾年 InfoQ 對京東 618 的特別報道，當我站在歷史的角度去審視這些采訪時，我也才真正理解媒體記錄的價值。我想，若干年后在去看這一系列的技術升級，你只要看這幾年 InfoQ 的文章標題就足以理解變化的關鍵點。

• 2015 年京東 618：Docker 扛大旗，彈性伸縮成重點

• 2016 年京東 618：15 萬個 Docker 實例，所有業務全部容器化

• 2017 年京東 618：容器技法日趨嫻熟，數個項目即將開源回饋社區

2018 年的 618，鮑永成和他的同事們寫下了這篇文章，他們希望能夠系統梳理過去幾年京東在基礎架構方面的點擊探索，也希望這系列文章能夠幫助到更多的中小公司少走彎路。以下為系列文章的第一篇。

不在江湖久已。這兩年來我們（京東）完成了從Kubernetes的落地、推廣，到大規模運營的歷程。走過了那些山水，看過了那些風景，現在，我想，是時候講講我們的故事了。

故事要從四年前講起，JDOS(Jingdong Datacenter Operating System) 1.0于2014年推出，基于OpenStack進行了深度定制，并在國內率先將容器引入生產環境。經歷了2015年6.18/11.11的考驗。團隊積累了大量的容器運營經驗，對Linux內核、網絡、存儲等深度定制，實現了容器秒級分配。

2016年，我們將精力集中與了完善容器的監控、網絡、存儲，鏡像中心等容器生態建設，并積累了豐富的運營監控數據。也是在這一年，我們漸漸意識到了OpenStack架構的笨重，啟動了新一代容器引擎平臺(JDOS 2.0)的研發。

2017年，JDOS2.0全面推出，JDOS從基礎設施升華到應用平臺。2.0推進了業務從源碼到編譯打包構建鏡像到上線的全流程，建設了一站式應用運行平臺。 這一年，我們逐步完善了容器的監控、網絡、存儲，鏡像中心等容器生態建設，開發了基于BGP的Skynet網絡、ContainerLB、ContainerDNS、ContainerFS等多個項目。

并將其中部分項目進行了開源( https://github.com/tiglabs/ )。我們為我們的容器生態起了一個全新的名字：阿基米德，意為撬動數據中心的人。

羅馬不是一天建成的。在容器化的過程中，我們經歷了很多，在這里我認為有必要回顧一下我們的經驗和教訓，有資于后來者借鑒與參考。

1. 不輕易放棄用戶。如果大量的改造工作都由業務方來承擔，那么容器化的推動將會是一件極其艱難的事情。許多老的業務可能沒有那么無狀態，甚而有一些諸如ip不變等的特殊需求。為用戶的定制和改造，不僅是一種妥協，更是提供一個兼容老的業務方式以使其容器化的方案。如果總是拒絕用戶，那么在失去用戶的同時，也失去了與他們一起成長的機會。貼近用戶，了解用戶的需求，進行分析、歸類和適應性的改造。在成就了業務的同時，也是成就了自己。

2. 幻想一蹴而就和急功近利，都是容器化過程中的大忌。對于應用進行改造的理想很豐滿，現實卻總是很骨感。因為這需要業務的大量的人力、物力、財力的支持。我們在容器化的過程中，采用了漸進式的策略。在開始，允許用戶將容器以虛擬機/物理機的使用方式進行使用，由其傳統的應用運維使用以往的工具進行部署和維護。同時，我們也提供了編譯構建上線的一站式服務，支持滾動升級、灰度發布、負載均衡、域名解析等等服務。用便捷的運維管理方式吸引用戶自主進行轉變。再后來，我們放開了鏡像的構建過程。已經有越來越多的用戶愿意自己去學習Dockerfile，以便構建起屬于自己業務的鏡像了。

3. 對于技術上的質疑要用技術來解決。新技術的推廣難免受到質疑與挑戰。要用于接受這些質疑和挑戰，并用技術和數據來證明自己。當然這也對團隊自身提出了更高的要求。對于新技術不是了解就可以了，而是能夠吃深吃透，進而根據場景進行定制。

4. 架構要能化繁為簡，易于維護運營和排障。社區的功能總是大而全，而對于我們具體的落地實踐來說，我們更多要做的是減法，將原本繁雜的架構和流程梳理清晰，剪除不必要的功能，保證整個平臺良好的可維護性。

5. 守住穩定的底線。穩定才是作為平臺賴以生存的基礎。將平臺進行加固，確保其穩定，不是說說而已，這其中有大量的工作需要做。穩定不是保守，不是守住現在的版本不再研發。而是要對于整個平臺的每個環節都能進行代碼級的精準掌握，對于上線前功能、性能進行充分測試，對于突發狀況有預案處理。從流程上能抑制雪崩問題的發生，并能夠控制故障的影響范圍。這些我們的具體工作將在未來的章節進行詳述。

調度的意義與難點

在實現了99.9%的業務容器化后，阿基米德迎來了全新的挑戰。近幾年硬件成本上漲帶來的ROI壓力以及建設異地多活的數據中心的實際需求，使得阿基米德JDOS的重點從容器集群管理轉向了調度，JDOS也從集群管理平臺的角色逐漸轉換為了調度平臺。

調度的意義從微觀上來說，是為每個容器尋找到一個合適的落腳點，也就是節點。但是從宏觀角度來說，其意義在于將整個數據中心計算效能的提升。具體來說，調度可以在縮減資源碎片，資源時空復用，節能降耗以及提升計算效率方面取得巨大收益。而且該收益隨著集群規模的擴大，會有更為明顯的提升。

調度雖然收益頗豐，但是要實現也非輕而易舉。調度不是空中樓閣，它依賴于大量的基礎工作。這其中一些典型的問題，需要一一解決，比如異構、隔離、監控、評估等問題。

在JDOS 1.0中，因為容器更多的是以胖容器的形式存在，因此容器的使用相對來說是靜態的，也就是一次調度完成后容器不會輕易遷移。除非節點故障、維護等特殊情況，則將其遷移到別的節點。而在JDOS 2.0中，情況就變得更為復雜了。JDOS 2.0允許用戶自動或者手動地進行應用的擴容縮容。并且，由于大數據、AI、serverless等任務的引入，平臺在將其與業務容器進行混合部署的同時，也需要具備對相關任務進行實時監控和異常驅逐的能力。而這些，對于調度平臺的動態處理能力、時間規劃能力都提出了更高的要求。

接下來，我們將用一系列的文章，深入解剖阿基米德調度平臺。下一章預告《第一章：事非經過不知難，Kubernetes的定制與優化》，歡迎關注聊聊架構微信公眾號，第一時間閱讀系列文章。

來自： http://www.infoq.com/cn/news/2018/06/jd-biggest-kubernetes-cluster