京東雲架構如何從OpenStack遷移至Kubernetes平臺

中國最大電商公司之一的京東,最近分享了自己通過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註冊表存儲所創建的映像。

 

爲了在Kubelets和OpenStack Neutron之間實現更好的集成,京東根據Container Networking Interface標準自行開發了一個名爲Cane的解決方案。在創建、刪除或修改Kubernetes負載均衡器後,Cane可以通知Neutron負載均衡即服務(LBaaS)系統。此外他們通過在Cane內部運行的Hades組件爲Pod提供內部的DNS解析服務。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章