本文已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Inside JD.com 從 OpenStack 轉移到 Kubernetes

編輯註：今天的文章是由 JD.com 的基礎架構平台部門團隊撰寫，內容關於他們從 OpenStack 過渡到 Kubernetes 的過程。JD.com 是中國最大的公司之一，也是第一家進入全球財富 500 強榜單的中國網路公司。

叢集建置歷史

實體機器時代 (2004-2014)

在 2014 年之前，我們公司的應用程式都部署在實體機器上。在實體機器時代，應用程式上線平均需要等待一周才能完成分配。由於缺乏隔離，應用程式會互相影響，導致許多潛在風險。當時，每台實體機器上的 tomcat 實例平均不超過九個。實體機器的資源被嚴重浪費，調度也不靈活。由於實體機器故障，應用程式遷移需要數小時。而且無法實現自動擴展。為了提高應用程式部署的效率，我們開發了編譯-封裝、自動部署、日誌收集、資源監控和其他一些系統。

容器化時代 (2014-2016)

由 JD.COM 首席架構師劉海峰領導的基礎架構平台部門 (IPD) 在 2014 年秋季尋求新的解決方案。Docker 進入了我們的視野。當時，docker 正在興起，但略顯薄弱，缺乏生產環境的經驗。我們多次測試了 docker。此外，我們客製化了 docker 以修復一些問題，例如 device mapper 導致的系統崩潰和一些 Linux 核心錯誤。我們還在 docker 中添加了許多新功能，包括磁碟速度限制、容量管理以及映像建置中的圖層合併等等。

為了適當管理容器叢集，我們選擇了 OpenStack + Novadocker 驅動程式的架構。容器被作為虛擬機器管理。這被稱為第一代 JD 容器引擎平台--JDOS1.0（JD 資料中心作業系統）。JDOS 1.0 的主要目的是容器化基礎架構。從那時起，所有應用程式都在容器而不是實體機器中運行。至於應用程式的運營和維護，我們充分利用了現有工具。開發人員在生產環境中請求計算資源的時間縮短到幾分鐘而不是一周。在計算資源池化之後，即使擴展 1,000 個容器也將在幾秒鐘內完成。應用程式實例已彼此隔離。應用程式的平均部署密度和實體機器利用率都提高了三倍，這帶來了巨大的經濟效益。

我們在每個 IDC 中部署了叢集，並提供統一的全球 API 以支援跨 IDC 部署。在我們的生產環境中，單個 OpenStack 分散式容器叢集中最多有 10,000 個計算節點，最少有 4,000 個。第一代容器引擎平台 (JDOS 1.0) 成功支援了 2015 年和 2016 年的「6.18」和「11.11」促銷活動。截至 2016 年 11 月，已經有 150,000 個容器在線運行。

「6.18」和「11.11」被稱為 JD.COM 最受歡迎的兩次線上促銷活動，類似於黑色星期五促銷活動。2016 年 11 月 11 日的已完成訂單達到 3000 萬筆。

在開發和推廣 JDOS 1.0 的實踐中，應用程式直接從實體機器遷移到容器。本質上，JDOS 1.0 是 IaaS 的一種實作。因此，應用程式的部署仍然嚴重依賴編譯-封裝和自動部署工具。然而，JDOS1.0 的實踐非常有意義。首先，我們成功地將業務遷移到容器中。其次，我們對容器網路和儲存有了深入的了解，並知道如何將它們打磨到最佳狀態。最後，所有經驗都為我們開發全新的應用程式容器平台奠定了堅實的基礎。

新容器引擎平台 (JDOS 2.0)

平台架構

當 JDOS 1.0 從 2,000 個容器成長到 100,000 個時，我們推出了新的容器引擎平台 (JDOS 2.0)。JDOS 2.0 的目標不僅僅是一個基礎架構管理平台，而且還是一個面向應用程式的容器引擎平台。在 JDOS 1.0 和 Kubernetes 的基礎上，JDOS 2.0 整合了 JDOS 1.0 的儲存和網路，貫穿了從原始碼到映像，再到部署的 CI/CD 流程。此外，JDOS 2.0 還提供日誌、監控、故障排除、終端和編排等一站式服務。JDOS 2.0 的平台架構如下所示。

D:\\百度云同步盘\\徐新坤-新人培训计划\\docker\\MAE\\分享\\arc.png

功能產品
原始碼管理Gitlab
容器工具Docker
容器網路Cane
容器引擎Kubernetes
映像註冊表Harbor
CI 工具Jenkins
日誌管理Logstash + Elastic Search
監控Prometheus

在 JDOS 2.0 中，我們定義了兩個層級：系統和應用程式。一個系統由多個應用程式組成，一個應用程式由多個提供相同服務的 Pod 組成。一般來說，一個部門可以申請一個或多個系統，這些系統直接對應於 Kubernetes 的命名空間。這意味著同一個系統的 Pod 將位於同一個命名空間中。

大多數 JDOS 2.0 組件 (GitLab / Jenkins / Harbor / Logstash / Elastic Search / Prometheus) 也被容器化並部署在 Kubernetes 平台上。

一站式解決方案

D:\\百度云同步盘\\徐新坤-新人培训计划\\docker\\MAE\\分享\\cicd.png

  1. 1.JDOS 2.0 以 docker 映像為核心，實現持續整合和持續部署。
  2. 2.開發人員將程式碼推送到 git。
  3. 3.Git 觸發 jenkins master 以產生建置工作。
  4. 4.Jenkins master 調用 Kubernetes 以建立 jenkins slave Pod。
  5. 5.Jenkins slave 拉取原始碼，進行編譯和封裝。
  6. 6.Jenkins slave 將封裝和 Dockerfile 發送到帶有 docker 的映像建置節點。
  7. 7.映像建置節點建置映像。
  8. 8.映像建置節點將映像推送到映像註冊表 Harbor。
  9. 9.使用者在不同區域建立或更新應用程式 Pod。

JDOS 1.0 中的 docker 映像主要由作業系統和應用程式的運行時軟體堆疊組成。因此，應用程式的部署仍然依賴於自動部署和其他一些工具。而在 JDOS 2.0 中，應用程式的部署是在映像建置期間完成的。映像包含完整的軟體堆疊，包括 App。透過映像，我們可以實現讓應用程式在任何環境中都按照設計運行的目標。

D:\\百度云同步盘\\徐新坤-新人培训计划\\docker\\MAE\\分享\\image.png

網路和外部服務負載平衡

JDOS 2.0 採用 JDOS 1.0 的網路解決方案，該解決方案使用 OpenStack Neutron 的 VLAN 模型實作。此解決方案實現了容器之間的高效通訊，使其成為公司內部叢集環境的理想選擇。每個 Pod 在 Neutron 中佔用一個埠，並具有單獨的 IP。基於容器網路介面標準 (CNI) 標準，我們開發了一個名為 Cane 的新專案，用於整合 kubelet 和 Neutron。

D:\\百度云同步盘\\徐新坤-新人培训计划\\docker\\MAE\\分享\\network.png

同時，Cane 也負責 Kubernetes 服務中 LoadBalancer 的管理。當建立/刪除/修改 LoadBalancer 時，Cane 將調用 Neutron 中 lbaas 服務的建立/移除/修改介面。此外，Cane 專案中的 Hades 組件為 Pod 提供內部 DNS 解析服務。

Cane 專案的原始碼目前正在完成中，並將很快在 GitHub 上發布。

彈性調度

D:\\百度云同步盘\\徐新坤-新人培训计划\\docker\\MAE\\分享\\schedule.pngJDOS 2.0 存取應用程式，包括大數據、Web 應用程式、深度學習和其他一些類型，並採用更多樣化和靈活的調度方法。在某些 IDC 中，我們實驗性地混合部署線上任務和離線任務。與 JDOS 1.0 相比，整體資源利用率提高了約 30%。

總結

Kubernetes 的豐富功能使我們能夠更多地關注平台的整個生態系統，例如網路效能，而不是平台本身。特別是，SRE 非常讚賞 replication controller 的功能。有了它，應用程式的擴展可以在幾秒鐘內完成。JDOS 2.0 現在已經存取了大約 20% 的應用程式，並部署了 2 個叢集，每天運行大約 20,000 個 Pod。我們計劃存取我們公司更多的應用程式，以取代目前的 JDOS 1.0。我們也很樂意與社群分享我們在這個過程中的經驗。

感謝 Kubernetes 和其他開源專案的所有貢獻者。

--JD.com 基礎架構平台部門團隊