微盟Flink on Kubernetes實時平台建設實踐

一、前言背景

1.1 引言概述

為滿足公司日常業務場景中資料分析、資料同步、實時風控、實時推薦、營銷自動化、數倉建設等實時資料分析計算場景的需求，建設提供了一個管理 Flink 實時計算任務的整個生命周期，集開發、部署、監控流程為一體的基礎工具平台系統。

1.2 邏輯架構

體系分層結構分别為：管理排程層、計算資源層、存儲服務層；而我們将 Flink 任務部署到計算資源層，就需要橫貫這三層進行打通，其中涉及到權限認證、狀态存儲、環境初始化、任務監控、任務日志等一系列相關問題。

1.3 建設思路

如上圖系統建設主要分為三個方面：任務開發、任務部署、任務監控；上述三方相輔相成，從任務編碼、配置、釋出到部署，對任務實施監控各項名額、日志采集分析等回報出任務的健康狀态、性能等方面的資料，對任務的異常名額告警觸達，推進任務更加合理化配置運作資源，促進任務健康平穩地運作。

1.3 目前問題

為解決目前 Flink on Yarn 部署模式的一些痛點問題：EMR 成本攀高、資源使用率低、資源碎片化、資源隔離性差、環境部署成本等。是以從資源隔離、運維成本和成本收益角度、快速擴縮、資源使用率等方面出發，我們開始調研 Flink on K8s 模式，希望解決目前 Yarn 環境的以上痛點；本文将側重介紹部署 K8s 環境，在任務開發、任務部署以及任務監控方面的一些實踐總結。

二、調研對比

2.1 業内對比

Flink on K8s 相比 Flink on Yarn 的優勢：

• 更好的資源與網絡的隔離性、安全性，更适合多租戶場景。
• 更容易實作與 online service 的混合部署，提升叢集使用率。
• 容器環境容易部署、清理和重建，更加快捷的部署，運維友好。
• 雲原生的趨勢，可以受益 K8s 豐富的生态系統，以及大資料計算上雲原生的趨勢。

對于 Flink on K8s 部署方式，官網以及社群推薦的部署模式：Native Kubernetes，社群提供的 Native Kubernetes 模式部署流程如下：

2.2 調研總結

研究 Flink on K8s 部署模式的實施，通過分析對比各種部署模式和優缺點和社群趨勢，得出如下圖結論。

結合，目前平台中各個 Flink 版本的占比情況，計劃 Flink on K8s 的部署模式的支援從 Flink 1.12 版本開始，使用 Native Kubernetes 模式，以 Application 運作方式送出部署 Flink 任務，應用 Kubernetes 生态能力保障 Flink 任務 HA 和資源自動伸縮、排程管理能力。

主要考量如下：

• 使用 Native Kubernetes 模式，相較于 standalone 方式（Flink 管理資源排程），對資源排程管理使用 Kubernetes 的原生能力。
• 對于任務的 HA 保障，從Flink1.12版本開始支援使用 Kubernetes 的原生能力，而不再依賴 Zookeeper 的能力來實作HA。
• Flink 生态社群逐漸廢除 Per Job 模式，替代為 Application 模式送出啟動任務。
• 目前平台各個 Flink 版本占比分布情況，Flink1.12.5 及以上版本是主力分布。

由此，部署模式的整體規劃如下：

• 第一期，支援從 Flink1.12 版本及以上支援部署 Kubernetes，盡量推進實時平台中Flink1.12 以下任務更新到 Flink 高版本；
• 第二期，後續如果 Flink1.12 以下版本有需要部署 Kubernetes 的強烈訴求，再考慮 Standalone 部署模式支援相對較低的版本。

2.3 部署思路

從上圖流程可見：

• 由 Flink 任務管理平台控制送出任務到指定業務線對應的資源空間。
• 由于不同租戶相關的資源、權限認證、配置等不同，是以存在 Flink 送出機的隔離性，通過臨時的 POD 容器來作為 Flink Client 來實作動态加載、差役隔離性，避免在 Flink 任務管理平台中維護多個開發組（租戶）的資源隔離。
• 在送出機中加載指定版本的待部署鏡像，動态加載不同任務的不同資源啟動任務。

2.4 部署實作

整體部署流程：

• 定義 Dockerfile 以及啟動腳本，構模組化闆鏡像。
• 資料開發者在平台中資源管理子產品上傳任務 jar 資源。
• 資料開發者在平台中資料開發子產品開發并啟動 Flink 實時任務。
• Flink 任務在管理平台中送出 Flink 任務到 K8s 叢集環境，拉取鏡像。
• 在 K8S 環境中按照 Dockerfile 鏡像以及啟動腳本進行 Flink 任務環境初始化。
• Flink 任務啟動運作，由 job manager 拉起 task manager。

三、實踐挑戰

3.1 快速驗證

為了快速試驗得到初步的思路驗證和部署體驗問題總結，我們先嘗試本地環境進行 Demo 驗證部署。為此，我們本地環境搭建虛拟機、Docker、K8s 環境，準備 Flink運作環境、建構 Docker 鏡像，向 K8s 容器送出部署 Flink 任務，指令如下：

./bin/Flink run-application \
--target kubernetes-application \
-c com.weimob.flink.client.DemoClient -Denv=QA \
-Dkubernetes.namespace=Flink-K8S-demo \
-Dkubernetes.container.image=Flink-deploy-demo:1.15.2 \
-Dkubernetes.cluster-id=Flink-thor-2926-9365 \
local:///opt/Flink/usrlib/root.jar           

初步驗證部署效果，送出任務到 K8s 容器環境：

通路 Flink Web UI界面：

3.2 動态資料

以基礎鏡像動态加載任務運作所需資源的思路，将任務運作所需環境初始化

• 目前平台維護的衆多實時任務，不希望一個任務一個鏡像，甚至是一次部署一個鏡像，這對于 tcr 鏡像存儲成本是一種損耗
• 是以，我們考慮通過基礎鏡像結合動态資源加載腳本來實作任務運作環境的資源差異化加載的能力，而不是通過提前将運作時環境建構好，一次運作一個鏡像的方式。

3.3 動态界面

Flink 官網文檔研究分析，通過 clusterIP、nodePort 的方式都不适用于 K8s 容器環境，并且公司生産級 K8s 叢集體系本身已經有成熟的服務暴露方案，本質上是通過 Load Balance 方式，參考如下：

K8s 體系的服務暴露流程如圖所示：

• 由于 K8s 環境的網絡通路結構決定，外部網絡無法直接通路，是以，想要通路到 Flink 任務的 WebUI 服務，需要将任務的 Service 暴露。
• 在完善的 K8s 體系下，我們需要将 ingress 路由規則和任務的 Service 綁定，就能實作通過指定的域名透過 K8s 環境的路由到内部 Service 對應的 POD 服務。

3.4 狀态存儲

任務運作的資料存儲，包含Checkpoint、日志等上傳騰訊COS。

• 對于 Flink on K8s 模式，我們需要支援 HDFS on COS 的能力，以友善任務的Checkpoint 上傳和存儲，具體配置做法，可以參考騰訊官方文檔

3.5 日志采集

對于 K8s 容器環境日志采集方式，大概分3類模式，參考業内實踐總結如下：

初期，為了快速實施部署實作效果，在 Demo 實踐中采用 Sidecar 模式部署在同一個 POD 中的不同 Container 的方式來實作對容器日志采集，寫入 ElasticSearch 叢集中，在資料平台中對應頁面搜尋展示時使用。

後期，通過對比現有容器叢集的日志采集體系，考慮依托目前運維體系的日志資料采集來實施對 Flink 任務的日志采集，同時，和容器叢集的其他業務日志進行隔離采集，由資料平台相關服務對采集的日志進行分析處理并寫入 ElasticXearch叢集中。

相對于 Sidecar 模式來說，Daemonset 模式部署在資源成本上和統一管理，部署資源成本更加低，資源使用率更加高，K8s 全體系日志資料采集方案和實施邏輯更加統一和管理，對于開發者和租戶更友好，無需感覺任務日志的采集體系。

3.6 監控名額

對于任務的名額資料采集和告警監控體系，我們接入目前整體基礎體系的監控采集體系中，依托 K8s 環境體系自動發現 POD，經過 VM Agent 采集到相關 POD 的名額資料存儲，設定對應的 VM Rule 來實作觸發告警推送到 AlertManager，經過 Flink 任務管理平台識别是否發送告警到使用者端。

四、階段成效

4.1 任務通路

對于部署效果和任務送出運作的直接呈現，我們需要能通路任務 Flink Web UI 界面，在測試環境以及生産環境中，對應的網絡體系和服務暴露需要找運維小夥伴支援，最終我們可以通過任務對應的專屬域名通路 Flink Web UI 界面。

4.2 任務日志

我們對任務日志搜尋提供了平台內建性頁面展示，友善使用者檢索檢視任務運作日志。

4.3 任務監控

任務名額監控資料展示，配置對應的 Grafana 大盤，展示 Flink on K8s 環境的任務名額資料。

五、未來展望

5.1 功能完善

目前已經完成任務的部署、監控&告警的一套完整基礎流程，還遺留部分問題及優化，包括：

• POD 資源CPU、Memory的實際使用率統計分析，确定彈性比例，以及适合的機器資源型号。
• 磁盤存儲方面，對于任務 Checkpoint 狀态存儲，後續需要研究挂載 PVC 來實作。
• 資料清理，對于 K8s 容器環境，傾向于是無狀态應用，本質上不希望産生日志檔案，任務運作結束，收尾處理，清理資源等操作。
• 鏡像優化，以及同一個鏡像融合 Yarn 部署模式和 K8s 模式，目前是拆分鏡像。

5.2 日志&監控

目前資料平台體系中，對于任務運作的日志采集、搜尋體系，還分散在各個業務子系統中，後續規劃，可以獨立資料平台的日志服務中心，獨立服務來為整體資料中心所有子系統服務。

日常開發者所需的任務監控展示和告警體系，也需要獨立一個資料中心的獨立子產品來收口聚集統一的服務實作，友善整體資料中心的統一操作行為和使用者習慣。

是以，對于日志和告警其實是傾向于建構獨立的子產品服務于整體資料中心平台，這可以使得平台更加體系化、健壯以及使用者友好。

六、參考資料

• Flink Native Kubernetes Deploy（https://nightlies.apache.org/flink/flink-docs-release-1.13/zh/docs/deployment/resource-providers/native_kubernetes/）
• Native Kubernetes Integration (Beta)（https://flink.apache.org/2020/02/11/apache-flink-1.10.0-release-announcement/#native-kubernetes-integration-beta）
• Kubernetes publishing-services-service-types（https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types）
• HDFS TO COS 工具（https://cloud.tencent.com/document/product/436/7212）
• Integeration of Tencent COS in Hadoop（https://hadoop.apache.org/docs/stable/hadoop-cos/cloud-storage/index.html）
• K8s 中的sidecar 和daemonset的了解和實踐（https://blog.csdn.net/knight_zhou/article/details/126241319）
• 分布式計算引擎 Flink/Spark on K8S 的實作對比以及實踐（https://developer.aliyun.com/article/788288）

作者:楊韬

來源:微信公衆号:微盟技術中心

出處:https://mp.weixin.qq.com/s/p2FgefWv4QZD1_5r95Rafw