文章轉自：http://jimmysong.io/docker-practice/docs/jd_transform_to_kubernetes.html
京東從2016年底啓動從OpenStack切換到Kubernetes的工作，截止目前(2017年2月）已遷移完成20%，預計Q2可以完成全部切換工作。Kubernetes方案與OpenStack方案相比，架構更爲簡潔。在這個過程中，有這些經驗可供業界借鑑。
背景介紹
2016年底，京東新一代容器引擎平臺JDOS2.0上線，京東從OpenStack切換到Kubernetes。到目前爲止，JDOS2.0集羣2w+Pod穩定運行，業務按IDC分佈分批遷移到新平臺，目前已遷移20%，計劃Q2全部切換到Kubernetes上，業務研發人員逐漸適應從基於自動部署上線切換到以鏡像爲中心的上線方式。JDOS2.0統一提供京東業務，大數據實時離線，機器學習（GPU）計算集羣。從OpenStack切換到Kubernetes，這中間又有哪些經驗值得借鑑呢？
本文將爲讀者介紹京東商城研發基礎平臺部如何從0到JDOS1.0再到JDOS2.0的發展歷程和經驗總結，主要包括：
- 如何找準痛點作爲基礎平臺系統業務切入點；
- 如何一邊實踐一邊保持技術視野；
- 如何運維大規模容器平臺；
- 如何把容器技術與軟件定義數據中心結合。
集羣建設歷史
物理機時代（2004-2014）
在2014年之前，公司的應用直接部署在物理機上。在物理機時代，應用上線從申請資源到最終分配物理機時間平均爲一週。應用混合部署在一起，沒有隔離的應用混部難免互相影響。爲減少負面影響，在混部的比例平均每臺物理機低於9個不同應用的Tomcat實例，因此造成了物理機資源浪費嚴重，而且調度極不靈活。物理機失效導致的應用實例遷移時間以小時計，自動化的彈性伸縮也難於實現。爲提升應用部署效率，公司開發了諸如編譯打包、自動部署、日誌收集、資源監控等多個配套工具系統。
容器化時代（2014-2016）
2014年第三季度，公司首席架構師劉海鋒帶領基礎平臺團隊對於集羣建設進行重新設計規劃，Docker容器是主要的選型方案。當時Docker雖然已經逐漸興起，但是功能略顯單薄，而且缺乏生產環境，特別是大規模生產環境的實踐。團隊對於Docker進行了反覆測試，特別是進行了大規模長時間的壓力和穩定性測試。根據測試結果，對於Docker進行了定製開發，修復了Device Mapper導致crash、Linux內核等問題，並增加了外掛盤限速、容量管理、鏡像構建層級合併等功能。
對於容器的集羣管理，團隊選擇了OpenStack＋nova-docker的架構，用管理虛擬機的方式管理容器，並定義爲京東第一代容器引擎平臺JDOS1.0（JD DataCenter OS）。JDOS1.0的主要工作是實現了基礎設施容器化，應用上線統一使用容器代替原來的物理機。
在應用的運維方面，兼用了之前的配套工具系統。研發上線申請計算資源由之前的一週縮短到分鐘級，不管是1臺容器還是1千臺容器，在經過計算資源池化後可實現秒級供應。同時，應用容器之間的資源使用也得到了有效的隔離，平均部署應用密度提升3倍，物理機使用率提升3倍，帶來極大的經濟收益。
我們採用多IDC部署方式，使用統一的全局API開放對接到上線系統，支撐業務跨IDC部署。單個OpenStack集羣最大是1萬臺物理計算節點，最小是4K臺計算節點，第一代容器引擎平臺成功地支撐了2015和2016年的618和雙十一的促銷活動。至2016年11月，已經有15W+的容器在穩定運行。
在完成的第一代容器引擎落地實踐中，團隊推動了業務從物理機上遷移到容器中來。在JDOS1.0中，我們使用的IaaS的方式，即使用管理虛擬機的方式來管理容器，因此應用的部署仍然嚴重依賴於物理機時代的編譯打包、自動部署等工具系統。但是JDOS1.0的實踐是非常有意義的，其意義在於完成了業務應用的容器化，將容器的網絡、存儲都逐漸磨合成熟，而這些都爲我們後面基於1.0的經驗，開發一個全新的應用容器引擎打下了堅實的基礎。
新一代應用容器引擎（JDOS 2.0）
1.0的痛點
JDOS1.0解決了應用容器化的問題，但是依然存在很多不足。
首先是編譯打包、自動部署等工具脫胎於物理機時代，與容器的開箱即用理念格格不入，容器啓動之後仍然需要配套工具系統爲其分發配置、部署應用等等，應用啓動的速度受到了制約。
其次，線上線下環境仍然存在不一致的情況，應用運行的操作環境，依賴的軟件棧在線下自測時仍然需要進行單獨搭建。線上線下環境不一致也造成了一些線上問題難於在線下復現，更無法達到鏡像的“一次構建，隨處運行”的理想狀態。
再次，容器的體量太重，應用需要依賴工具系統進行部署，導致業務的遷移仍然需要工具系統人工運維去實現，難以在通用的平臺層實現靈活的擴容縮容與高可用。
另外，容器的調度方式較爲單一，只能簡單根據物理機剩餘資源是否滿足要求來進行篩選調度，在提升應用的性能和平臺的使用率方面存在天花板，無法做更進一步提升。
平臺架構
鑑於以上不足，在當JDOS1.0從一千、兩千的容器規模，逐漸增長到六萬、十萬的規模時，我們就已經啓動了新一代容器引擎平臺(JDOS 2.0)研發。JDOS 2.0的目標不僅僅是一個基礎設施的管理平臺，更是一個直面應用的容器引擎。JDOS 2.0在原1.0的基礎上，圍繞Kubernetes，整合了JDOS 1.0的存儲、網絡，打通了從源碼到鏡像，再到上線部署的CI/CD全流程，提供從日誌、監控、排障、終端、編排等一站式的功能。JDOS 2.0的平臺架構如下圖所示。
在JDOS 2.0中，我們定義了系統與應用兩個級別。一個系統包含若干個應用，一個應用包含若干個提供相同服務的容器實例。一般來說，一個大的部門可以申請一個或者多個系統，系統級別直接對應於Kubernetes中的namespace，同一個系統下的所有容器實例會在同一個Kubernetes的namespace中。應用不僅僅提供了容器實例數量的管理，還包括版本管理、域名解析、負載均衡、配置文件等服務。
不僅僅是公司各個業務的應用，大部分的JDOS 2.0組件(Gitlab/Jenkins/Harbor/Logstash/Elastic Search/Prometheus)也實現了容器化，在Kubernetes平臺上進行部署。
開發者一站式解決方案
JDOS 2.0實現了以鏡像爲核心的持續集成和持續部署。
- 開發者提交代碼到源碼管理庫
- 觸發Jenkins Master生成構建任務
- Jenkins Master使用Kubernetes生成Jenkins Slave Pod
- Jenkins Slave拉取源碼進行編譯打包
- 將打包好的文件和Dockerfile發送到構建節點
- 在構建節點中構建生成鏡像
- 將鏡像推送到鏡像中心Harbor
- 根據需要在不同環境生產/更新應用容器
在JDOS 1.0，容器的鏡像主要包含了操作系統和應用的運行時軟件棧。APP的部署仍然依賴於以往運維的自動部署等工具。在2.0中，我們將應用的部署在鏡像的構建過程中完成，鏡像包含了APP在內的完整軟件棧，真正實現了開箱即用。
網絡與外部服務負載均衡
JDOS 2.0繼承了JDOS 1.0的方案，採用OpenStack-Neutron的VLAN模式，該方案實現了容器之間的高效通信，非常適合公司內部的集羣環境。每個Pod佔用Neutron中的一個port，擁有獨立的IP。基於CNI標準，我們開發了新的項目Cane，用於將Kubelet和Neutron集成起來。
同時，Cane負責Kubernetes中service中的LoadBalancer的創建。當有LoadBalancer類型的service創建/刪除/修改時，Cane將對應的調用Neutron中創建/刪除/修改LBaaS的服務接口，從而實現外部服務負載均衡的管理。另外，Cane項目中的Hades京東開源在GitHub上組件爲容器提供了內部的DNS解析服務。
靈活調度
JDOS 2.0接入了包括大數據、Web應用、深度學習等多種類型的應用，併爲每種應用根據類型採用了不同的資源限制方式，並打上了Kubernetes的不同標籤。基於多樣的標籤，我們實現了更爲多樣和靈活的調度方式，並在部分IDC實驗性地混合部署了在線任務和離線任務。相較於1.0，整體資源利用率提升了約30%。
推廣與展望
有了1.0的大規模穩定運營作爲基礎，業務對於使用容器已經給予了相當的信任和支持，但是平臺化的容器和基礎設施化的容器對於應用的要求也不盡相同。比如，平臺化的應用容器IP並不是固定的，因爲當一個容器失效，平臺會自動啓動另一個容器來替代，新的容器IP可能與原IP不同。這就要求服務發現不能再以容器IP作爲主要標識，而是需要採用域名，負載均衡或者服務自注冊等方式。
因此，在JDOS2.0推廣過程中，我們也推動了業務方主要關注應用服務，減少對單個容器等細節的操作，以此自研了全新智能域名解析服務和基於DPDK高性能負載均衡服務，與Kubernetes有效地配合支持。
近兩年，隨着大數據、人工智能等研發規模的擴大，消耗的計算資源也隨之增大。因此，我們將大數據、深度學習等離線計算服務也遷移進入JDOS2.0。目前是主要採用單獨劃分區域的方式，各自的服務仍然使用相對獨立的計算資源，但是已經納入JDOS2.0平臺進行統一管理，並通過機器學習方法，提升計算資源使用效率。
靈活的標籤給予了集羣調度無限的可能。未來我們將豐富調度算法，並配以節能的相關技術，提高集羣整體的ROI，從而爲打造一個低能耗、高性能的綠色數據中心打下基礎。
回望與總結
Kubernetes方案與OpenStack方案相比，架構更爲簡潔。OpenStack整體運營成本較高，因爲牽涉多個項目，每個項目各自有多個不同的組件，組件之間通過RPC（一般使用MQ）進行通訊。爲提高可用性和性能，還需要考慮各個組件的擴展和備份等。這些都加劇了整體方案的複雜性，問題的排查和定位難度也相應提升，對於運維人員的要求也相應提高。
與之相比，Kubernetes的組件較少，功能清晰。其核心理念（對於資源和任務的理解）、靈活的設計（標籤）和聲明式的API是對Google多年來Borg系統的最好總結，而其提供的豐富的功能，使得我們可以投入更多精力在平臺的整個生態上，比如網絡性能的提升、容器的精準調度上，而不是平臺本身。尤其是，副本控制的功能受到了業務線上應用運維工程師的追捧，應用的擴容縮容和高可用實現了秒級完成。JDOS 2.0目前已經接入了約20%的應用，部署有2個集羣，目前日常運行的容器有20000個，仍在逐步推廣中。
真誠感謝Kubernetes社區和相關開源項目的貢獻者，目前京東已經加入CNCF組織，並在社區排名達到TOP30。
作者簡介
鮑永成，京東基礎平臺部技術總監，帶領基礎平臺部集羣技術團隊從2014年上線京東容器引擎平臺JDOS1.0到現在的JDOS2.0，作爲堅實的統一計算運行平臺承載京東全部業務穩定運行。目前主要工作方向是JDOS2.0研發和京東第一代軟件定義數據中心建設。