中國最大電商公司之一的京東，最近分享了自己通過Kubernetes對基于應用程序容器的基礎架構進行革新，取代OpenStack托管的IaaS基礎架構過程中所獲得的經驗。本次遷移同時涉及內部網絡組件，借此可將資源利用率提高30%。
在采用應用程序容器技術之前，京東的基礎架構部署經歷了兩個階段：物理機（2004 – 2014）以及操作系統容器（2014 – 2016）。第一階段主要使用手工管理的裸機硬件，但這一階段遇到了很多問題，例如上線前的準備時間過長（從分配到應用程序上線約需要一周時間），缺乏隔離機制，資源利用率不足，調度機制不夠靈活。計算機失敗后往往需要花費數小時遷移應用，且缺乏自動縮放能力。工程團隊針對日志收集、自動化部署、編譯和打包，以及資源監視等常用任務開發了內部工具。
京東基礎架構的第二階段開始采用容器技術。當時使用了操作系統容器，這意味著需要將現有應用程序和部署架構整體遷入容器中。當時的容器可以看作是對他們原本采用的物理機進行精簡后一種運行速度更快的“物理機”，并未采用已經完全成熟的“容器哲學”。
盡管如此，通過采用容器技術，他們已經在第二階段從時間和資源的使用率方面獲得了巨大的收益。當時他們使用OpenStack作為編排層，并使用nova Docker驅動實現容器的管理。該團隊選擇Docker作為自己的容器平臺，并逐漸向其中增添新的功能。所有應用陸續遷移到容器中，借此將計算資源請求的實現時間從原本的一周縮短至幾分鐘。應用程序的平均部署密度和物理機的利用率提升了三倍。該團隊還針對部署任務構建了統一的API，公司內部將其稱之為JDOS（JD Datacenter Operating System）1.0。
他們基于OpenStack的平臺通過一個群集承載了大約4000至10000個計算節點。截至2016年11月，京東團隊共運行了將近150,000個容器。這個平臺幫助他們順利度過了兩次大流量在線促銷活動，包括2016年雙十一活動，共完成大約3千萬個訂單。
在第二階段遷移至容器技術后，該工程團隊已經可以對部署架構進行改動，使用容器作為基本的部署單位。公司內部將其稱之為JDOS 2.0。這個方法關注的并非基礎架構本身的管理，而在于可感知應用程序的容器管理。他們的平臺設計包含兩個抽象：系統和應用程序。一個“系統”可包含多個“應用程序”，每個應用程序可包含多個提供相同服務的Pod。一個系統對應著一個Kubernetes名稱空間。
其他組件還包括部署流程和容器化的DevOps工具，這些內容均部署在Kubernetes管理的平臺上，此外還包括Gitlab、Jenkins、Logstash、Harbor、Elasticsearch，以及Prometheus。部署過程中，源代碼和Dockerfile會被推送至代碼庫和Jenkins構建。Jenkins被配置為主從模式，其中從節點負責構建和打包應用程序，此外還有一個類似的節點負責構建容器映像。他們使用了Harbor這一開源的Docker注冊表存儲所創建的映像。
圖片來源：http://blog.kubernetes.io/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack.html
為了在Kubelets和OpenStack Neutron之間實現更好的集成，京東根據Container Networking Interface標準自行開發了一個名為Cane的解決方案。在創建、刪除或修改Kubernetes負載均衡器后，Cane可以通知Neutron負載均衡即服務（LBaaS）系統。此外他們通過在Cane內部運行的Hades組件為Pod提供內部的DNS解析服務。
閱讀英文原文：How JD.com Moved to Kubernetes from OpenStack
京公網安備 11010502049343號