導讀：
近些年隨著雲端計算和雲原生應用的興起，容器技術可以很好地解決許多問題，所以將大資料平臺容器化是一種理想的方案。本文將結合袋鼠雲數棧在Flink on Kubernetes的實踐讓您對大資料平臺容器化的操作和價值有初步的瞭解。
你可以看到???
▫ Kubernetes如何解決Hadoop痛點
▫ 數棧在Flink on K8S的實踐
▫ 容器化之後的未來設想：資源池化
作者 / 雅澤、狗煥
編輯 / 向山
引言
在過去的很長一段時間，大資料領域中構建可擴充套件的分散式應用框架中，Apache Hadoop佔據的是絕對的統治地位。
目前絕大多數大資料平臺都是基於Hadoop生態構建，使用YARN作為核心元件進行資源管理與資源排程，但是這些大資料平臺普遍都會存在資源隔離性差、資源利用率低等問題，與此同時近些年隨著雲端計算和雲原生應用的興起，容器技術可以很好地解決這些問題。
所以將大資料平臺容器化是一種理想的方案，本文將結合袋鼠雲數棧在Flink on Kubernetes的實踐讓您對大資料平臺容器化的操作和價值有初步的瞭解。
Hadoop痛點頻現，亟待解決
大資料平臺顧名思義就是處理急速增長的實時、離線資料的大規模應用程式，所以設計大資料平臺的解決方案的需要考慮的首要問題就是如何確定生產環境中大資料平臺的部署架構，使得平臺具有緊密聯絡資料、應用程式與基礎設施之間的能力。
Hadoop主要提供了三個關鍵功能：資源管理器(YARN)、資料儲存層(HDFS)、計算正規化(MapReduce)，市面上大多數大資料平臺都是基於Hadoop生態構建的，但是這型別的平臺會存在下列問題：
資源彈性不足
大資料系統的資源使用高峰是具有周期性的，不同業務線在一天中的高峰期是不一樣的，當業務壓力增大時，當前的大資料系統普遍缺乏資源彈性伸縮的能力，無法按需進行快速擴容，為了應對業務高峰只能預留出足夠的資源保證任務正常執行；
資源利用率低
儲存密集型的業務儲存資源使用較高而CPU使用率長期處於較低的水平，計算密集型的業務雖然CPU使用率相對較高但是儲存的使用率非常低，大量資源閒置；
資源隔離性差
從Hadoop2.2.0開始，YARN開始使用cgroup實現了CPU資源隔離，通過JVM提供的記憶體隔離機制來實現記憶體資源隔離，整體上來看YARN的資源隔離做的並不完善，會造成多個任務執行到同一個工作節點上時，不同任務會出現資源搶佔的情況。
Kubernetes風頭正勁，完美解決Hadoop痛點
Kubernetes是谷歌開源的生產級的容器編排系統，是建立在谷歌大規模執行生產工作負載方面的十幾年的經驗基礎上的，而且擁有一個龐大且快速增長的生態系統，伴隨著微服務、DevOps、持續交付等概念的興起和持續發酵，並依託與雲原生計算基金會(CNCF)，Kubernetes保持著高速發展。
如下圖所示，Google過去五年對於Kubernetes和Apache Hadoop熱度統計結果展示表明市面上對Kubernetes的熱情逐漸高漲而對Hadoop熱度逐漸減退。
那麼，Kubernetes是如何解決Hadoop存在的痛點的呢，我們一一分析一下。
解決資源彈性不足
對於資源彈性不足的問題，Kubernetes本身就是設計為一個利用模組化架構來進行擴充套件的系統，對使用者來說，服務進行擴容只需要修改配置檔案中容器的副本數或者是使用Pod水平自動擴縮(HPA)，將應用擴縮容的複雜度交給Kubernetes控制可以極大減少人為介入的成本。HPA是基於CPU使用率、記憶體使用率或其他實時採集的效能指標自動擴縮ReplicationController、Deployment和ReplicaSet中的Pod數量。
Kubernetes中的Metrics Server會持續採集所有Pod副本的效能指標資訊，HPA控制器通過Metrics Server的API獲取這些資料，並根據使用者設定的自動擴縮容規則計算目標Pod副本數量，當目標Pod數量與當前Pod數量不一致時，HPA控制器就向Pod的副本控制器發起擴縮容操作，調整Pod數量，完成擴縮容操作。
解決資源使用率低
對於資源使用率低的問題，一方面Kubernetes支援更加細粒度的資源劃分，這樣可以儘量做到資源能用盡用，最大限度的按需使用。另外一方面支援更加靈活的排程，並根據業務SLA的不同，業務高峰的不同，通過資源的混合部署來進一步提升資源使用率。
解決資源隔離性差
對於資源隔離性差的問題，容器技術本身是具有資源隔離的能力的，底層使用Linux namespace進行資源隔離，它將全域性系統的資源包裹在一個抽象層中，使得在每個 namespace 內部的程式看起來自己都擁有一個獨立的全域性資源。
同一個 namespace 下的資源變化對於同一 namespace 的程式是可見的，但是對於不同namespace下的程式是不可見的。為了能夠讓容器不佔用其它容器的資源（或者說確定每個容器的“硬體”配置），採用cgroups來限制單個程式或者多個程式所使用資源的機制，可以對 cpu，記憶體等資源實現精細化的控制。
Flink on K8S實踐，數棧研究小成
正因為大資料元件容器化優勢明顯，數棧使用的大資料計算和儲存元件均預期往容器化方向排布。
在數棧目前使用的眾多元件中，我們首先選擇在k8s上嘗試實踐的是數棧流計算引擎——Flink 。經過研究佈設，現在數棧的流計算容器化轉換已經基本實現。接下來是一些Flink on K8S的經驗分享:
Flink on K8S概述
目前在K8S中執行Flink任務的方式有兩種，一種是Standalone，一種是原生模式：Flink native session 模式、Flink native per-job 模式，它們各自對應的優缺點如下：
Flink Standalone模式：
● 優點：優點是無需修改 Flink 原始碼，僅僅只需預先定義一些 yaml 檔案，叢集就可以啟動，互相之間的通訊完全不經過 K8s Master；
● 缺點：缺點是資源需要預先申請無法動態調整。
Flink native session 模式：
● 優點：taskManager 的資源是實時的、按需進行的建立，對資源的利用率更高，所需資源更精準。
● 缺點：taskManager 是實時建立的，使用者的作業真正執行前, 與 Per Job叢集一樣, 仍需要先等待 taskManager 的建立, 因此對任務啟動時間比較敏感的使用者，需要進行一定的權衡。
Flink native per-job 模式：
● 優點：資源按需申請，適合一次性任務，任務執行後立即釋放資源，保證了資源的利用率；
● 缺點：資源是在任務提交後開始建立，同樣意味著對於提交任務後對延時比較敏感的場景，需要一定的權衡;
數棧Flink Standalone on K8S實踐
接下來我們以standalone模式容器化為切入點介紹下我們的一些實踐。
我們通過自定義的資源物件來定義我們應用的相關部署屬性，然後將這個yaml檔案和所需的配置檔案以及映象打包上傳到easymanager平臺（後續會將其開源）進行一鍵部署。這裡對於應用整體狀態的處理大致如下：
● 對於配置：這裡我們把應用的涉及到的狀態資料都提煉到應用的配置變成k8s中的configmap，通過該配置作為統一的修改入口。同時分離出jobmanager和taskmanager的配置使兩者對各自狀態進行維護互不干擾。
● 對於儲存：分離儲存狀態，可採用pvc來宣告我們所需要的儲存型別（storageclass），或者我們可以在映象中內建一個hdfs的client或者s3外掛來直接對接客戶現場的環境，這裡我們是將hdfs client和s3的外掛包封裝到了flink的映象中，然後通過上面提取出的配置來進行控制對應的儲存對接。
● 對於叢集狀態資訊：我們在部署flink的時候我們會部署好基礎元件包，如zookeeper、redis、mysql等，同樣也能通過上面提取的配置引數進行修改對接外部基礎元件。
實踐如下：
1) 定義我們自定義資源描述：
flink社群擁有大量的外掛供我們使用，通過這些外掛我們能擴充套件一些需要的能力，但是將這些外掛都打包到映象中，那麼這個映象體積勢必會變得非常大，這裡我們將這些外掛單獨抽離出來做成一個單獨的基礎服務元件，然後通過我們的業務映象去引用這些基礎元件，在引用這些基礎元件後會以sidecar形式注入到我們的業務容器中完成目錄繫結，從而實現按需索取也減小了映象體積的大小。
上面對應資源描述了在k8s上應用最基本的部署能力，這裡我們還需要將公共配置進行對映，然後將這些配置暴露到前端。通過這個統一的配置修改入口簡化了交付人員對配置檔案的篩查和修改。
2) 自動化出包：
我們在定義好資源物件的描述後，根據定義的資源描述檔案將需要的配置提取以及編寫應用需要的相關屬性，將這些內容放到一個yaml檔案中，同時編寫dockerfile、啟動指令碼、編寫jenkinsfile接入自動化出包流程，最後出包驗證。通過分工合作這樣一來就能將內部原先大量人工的操作全部自動流程化，提高效率。
3) 部署：
完成部署後的結果如下：
通過點選“服務擴縮容”，我們可以一鍵擴縮taskmanager的計算資源：
然後我們可以通過k8s的ingress資源物件暴露的地址來訪問flink的ui進行後續flink叢集的運維操作。
通過以上flink standalone容器化我們簡化了主機模式下flink的部署、資源管理劃分等問題。那麼對於應用日誌收集和監控，我們採用的是loki和prometheus的動態服務發現。
容器之後，數棧走向何方
儘管Kubernetes能夠解決傳統Hadoop生態存在的一些痛點問題，但是距離它能真正成為一個部署大資料應用切實可行的平臺還是有很長的一段路要走的：比如為短生命週期與無狀態應用設計的容器技術、不同job之間缺少共享的持久化儲存以及大資料平臺關心的排程、安全以及網路相關問題還需要更好的解決方案。現在，數棧正積極參與開源社群，幫助 Kubernetes 能成為部署大資料應用程式的實用選擇。
對於數棧而言，基於存算分離的設計理念，使用Kubernetes解決了計算資源彈性擴充套件的問題後，由於計算資源與儲存資源的分離，可能會出現計算效能降低、儲存的彈性無法保證等問題。未來我們會考慮在儲存層使用物件儲存，整體架構在計算和底層儲存之間加上一層快取（比如JuiceFS和Alluxio），儲存層選型在OpenStack Swift、Ceph、MinIO等成熟的開源方案中。
容器之後，我們並未停下腳步，關於未來我們有很多在考慮的設想，比如利用雲化或者雲原生技術統一管理資源池，實現大數系統產品、計算、儲存資源池化，實現全域性化、集約化的排程資源等等，技術在迭代，我們的自我革新也從未停止。
開源專案技術交流
ChunJun
https://github.com/DTStack/chunjun
https://gitee.com/dtstack_dev_0/chunjun
Taier
https://github.com/DTStack/Taier
https://gitee.com/dtstack_dev_0/taier
MoleCule
https://github.com/DTStack/molecule
https://gitee.com/dtstack_dev_0/molecule
歡迎加入開源框架技術交流群
（釘釘群：30537511）