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

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

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

Kubernetes 負責在整個應用生命周期中調度並自動執行與容器相關的任務，包括部署、運維、服務發現、存儲配置、負載均衡、自動擴展、自我治愈實現高可用性等等。

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

EasyMR 作為一款提供一站式可視化組件安裝部署與可觀測運維管理能力的大數據計算引擎產品，我們自然也基於 Kubernetes 部署進行了實踐探索。

EasyMR 基於 Kubernetes 部署的探索

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

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

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

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

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

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

上述表格的 workload 表示服務類型，比如說平臺內置主從 MySQL 的 workload，那麼只需要在產品包中聲明服務類型是 MySQL 以及鏡像的名稱，當執行部署的時候，平臺會自動創建 MySQL 的有狀態應用 statefulset、配置文件 configmap、服務 service、存儲 pv/pvc 等等 Kubernetes 底層資源。大大節省了人力成本，提升了交付效率，後續如果需要擴展組件類型也可以在平臺迭代中逐步完善。

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

架構圖中 vela-core 是核心部署組件，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 從而影響任務的穩定性；對象存儲數據最終一致性的機制會降低計算過程中的穩定性和正確性。所以我們還需要 Alluxio/Juicefs 這樣的緩存加速層來提升我們使用對象存儲的性能。

《數棧產品白皮書》：https://www.dtstack.com/resources/1004?src=szsm

《數據治理行業實踐白皮書》下載地址：https://www.dtstack.com/resources/1001?src=szsm

想瞭解或咨詢更多有關袋鼠雲大數據產品、行業解決方案、客戶案例的朋友，瀏覽袋鼠雲官網：https://www.dtstack.com/?src=szbky

同時，歡迎對大數據開源項目有興趣的同學加入「袋鼠雲開源框架釘釘技術qun」，交流最新開源技術信息，qun號碼：30537511，項目地址：https://github.com/DTStack