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

京東從 OpenStack 轉向 Kubernetes 的內幕

編者按：今天的文章由京東基礎設施平臺部門團隊撰寫，講述了他們從 OpenStack 過渡到 Kubernetes 的過程。京東是中國最大的公司之一，也是第一家進入全球財富500強的中國網際網路公司。

叢集建設歷程

物理機時代 (2004-2014)

2014年之前，我們公司的應用都部署在物理機上。在物理機時代，應用上線資源分配平均需要等待一週時間。由於缺乏隔離，應用之間會相互影響，導致許多潛在風險。當時，每臺物理機上的 tomcat 例項平均不超過九個。物理機資源嚴重浪費，排程不靈活。由於物理機故障，應用遷移需要數小時。並且無法實現自動擴縮容。為了提高應用部署效率，我們開發了編譯打包、自動化部署、日誌收集、資源監控等系統。

容器化時代 (2014-2016)

2014年秋，由京東首席架構師劉海峰領導的基礎設施平臺部門 (IPD) 尋求新的解決方案。Docker 進入了我們的視野。當時 Docker 正在興起，但略顯稚嫩，在生產環境中缺乏經驗。我們反覆測試了 Docker。此外，Docker 也被定製化以解決一些問題，例如裝置對映器導致的系統崩潰和一些 Linux 核心 bug。我們還向 Docker 中添加了許多新功能，包括磁碟限速、容量管理以及映象構建中的分層合併等。

為了妥善管理容器叢集，我們選擇了 OpenStack + Novadocker 驅動的架構。容器被當作虛擬機器進行管理。這被稱為京東第一代容器引擎平臺——JDOS1.0 (JD Datacenter Operating System)。JDOS 1.0 的主要目的是將基礎設施容器化。自那時起，所有應用程式都執行在容器中，而不是物理機上。至於應用程式的運維，我們充分利用了現有工具。開發人員在生產環境中請求計算資源的時間從一週縮短到幾分鐘。計算資源池化後，即使是擴容1000個容器也能在幾秒內完成。應用例項之間相互隔離。應用平均部署密度和物理機利用率都提高了三倍，帶來了巨大的經濟效益。

我們在每個 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”是京東最受歡迎的兩次線上促銷活動，類似於黑色星期五促銷。2016年11月11日，完成訂單量達到3000萬。

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

新容器引擎平臺 (JDOS 2.0)

平臺架構

當 JDOS 1.0 從2000個容器增長到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 中，應用程式的部署在映象構建期間完成。映象包含完整的軟體棧，包括應用程式。透過映象，我們可以實現應用程式在任何環境中按設計執行的目標。

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 豐富的功能使我們能夠更多地關注平臺整體生態系統，例如網路效能，而不是平臺本身。特別是，SREs 高度讚賞了複製控制器功能。有了它，應用程式的擴縮容在幾秒鐘內即可完成。JDOS 2.0 目前已接入約20%的應用程式，並部署了2個叢集，每天執行約20,000個 Pod。我們計劃接入更多公司應用程式，以取代當前的 JDOS 1.0。我們也很高興與社群分享在此過程中的經驗。

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

——京東基礎設施平臺部門團隊