Kubernetes 是用於編排容器化應用程式的 。最初由 Google 建立，如今由 Cloud Native Computing Foundation（CNCF）維護更新。

Kubernetes 是市面上最/受/歡/迎的 之一。它自動化容器化應用程式的部署、擴充套件和管理，允許管理和協調跨多個主機的 ，提供容錯性和可伸縮性等服務。

簡單點說，如果你的應用程式可以容器化（例如，藉助 Docker），那麼絕對應該使用 Kubernetes 來執行和管理這些應用程式。在 k8s 的支援下，可以大大提高本地或 的利用率，所有計算資源都可以在多個應用程式之間動態而合理地共享。

負責在整個應用生命週期中排程並自動執行與容器相關的任務，包括部署、運維、服務發現、儲存配置、 、自動擴充套件、自我治癒實現高可用性等等。

如今，Kubernetes 和更廣泛的容器生態系統日益成熟，成為通用的計算平臺和生態系統，可與作為現代雲基礎架構和 的虛擬機器 (VM) 一爭高下，甚至大有後來居上之勢。但是 本身是一個比較複雜的平臺，一個運維或者開發人員如果要說快速精通 Kubernetes 是不可能的，所以這就提高了傳統運維開發人員使用其的門檻。

作為一款提供 與 能力的大資料計算引擎產品，我們自然也基於 Kubernetes 部署進行了實踐探索。

EasyMR 基於 Kubernetes 部署的探索

之前我們討論的 都是基於主機叢集的模式下，需要部署服務就需要先接入主機，然後部署對應產品包服務從而完成應用叢集的快速搭建。但是隨著雲原生相關技術棧(容器、微服務、服務網格等)和 Kubernetes 近些年的流行，傳統模式也急需更新換代以適應大趨勢的發展。所以我們決定在 EasyMR 原有的基於產品包部署的產品模式基礎上，全新打造一個 的版本。

前面我們說過，由於 Kubernetes 自身的複雜性，一般開發運維人員使用起來是比較費力的，比如控制器（Deployment/Daemonset/Statefulset/Job/CronJob），儲存（PVC/PV/StorageClass）等等，所以我們還是將複雜性/交給平臺去解決，暴露給使用者的互動則是通俗易懂的。

在主機叢集模式下，部署服務的步驟為下載包->解壓縮安裝包->配置下發->服務啟動，EasyMR 自身的 可以做到服務的全生命週期管理。基於 Kubernetes 的架構下，我們再去開發對應版本的 agent 也是可以做到的，但是經過對市面上一些開源服務的調研，我們發現 kubevela 正好可以彌補我們這部分能力。

使用 OAM（Open Application Model），本質是根據軟體設計的 對負責的 DevOps 流程的高度抽象和封裝，一個以應用為中心的 Kubernetes API 分層，這種模型旨在定義雲原生應用的標準。

作為 平臺，基於 kubevela，我們只需要提供多種可擴充套件的元件型別，便可以對上層使用者遮蔽 Kubernetes 的底層複雜實現邏輯。使用 EasyMR 部署 Kubernetes 服務的使用者只需要關注服務型別以及修改應用配置，便可以實現服務的部署，關於 kubevela/OAM 更詳細的部分我們會在後面的文章中介紹，本文便不多贅述。

對 EasyMR 而言，部署服務的維度始終是產品包，這點我們並沒有去做更改，產品包的核心就是 。因此，我們擴充套件了一些欄位以適應 Kubernetes 部署的要求。

上述表格的 表示服務型別，比如說平臺內建主從 MySQL 的 workload，那麼只需要在產品包中宣告服務型別是 MySQL 以及映象的名稱，當執行部署的時候，平臺會自動建立 MySQL 的有狀態應用 statefulset、配置檔案 configmap、服務 service、儲存 pv/pvc 等等 。大大節省了人力成本，提升了交付效率，後續如果需要擴充套件元件型別也可以在平臺迭代中逐步完善。

EasyMR 雲化部署架構如下圖所示：

架構圖中 是核心部署元件，config-reloader 會動態監測 Pod 使用的 configmap 的更新狀態從而重啟應用 Pod。

EasyMR 基於 Kubernetes 的未來探索

EasyMR 作為基於雲原生技術和 Hadoop、Hive、Spark、Flink、Hbase、Presto 等開源大資料元件構建的 ，做到能部署大資料元件只是里程碑中的第一步，未來我們的目標會投向更長遠的地方—— ：

● 使用 Kubernetes 替代 Yarn 作為排程元件

以 Flink 和 Spark 為代表的分散式流批計算框架的下層資源管理平臺逐漸從 Hadoop 生態的 YARN 轉向 Kubernetes 生態的 Kubernetes原生 scheduler 以及周邊資源排程器，比如 Volcano 和 Yunikorn 等。

● 使用物件儲存+快取加速

隨著雲端計算技術的成熟，企業儲存又多了一個選項—— 。最早從 AWS 開始，後來所有的雲廠商都在向這個方向發展，用物件儲存去替換 HDFS。

但是物件儲存用於支援 Hadoop 這樣複雜的系統，會出現以下問題：檔案 Listing 效能較弱；物件儲存沒有原子 Rename 從而影響任務的穩定性；物件儲存資料最終一致性的機制會降低計算過程中的穩定性和正確性。所以我們還需要 這樣的 來提升我們使用物件儲存的效能。

《資料治理行業實踐白皮書》下載地址：

《數棧V6.0產品白皮書》下載地址：

想了解更多有關袋鼠雲大資料產品、行業解決方案、客戶案例的朋友，瀏覽袋鼠雲官網： https://www.dtstack.com/?src=szitpub