信也容器雲揭祕02-Flink上雲

Flink做爲大數據和實時數據部門重要的框架和引擎，扮演着重要的角色，Flink的使用也愈來愈多，集羣管理也變得愈來愈不容易。爲了支持Flink上雲，容器雲團隊也對其作了大量的探索工做，以保證Flink可以更好的且平穩的進行容器化。

一：部署方式選擇

目前信也上雲的Flink版本是Flink 1.11，Flink 1.11基於kubernetes的部署模式有：Session、Per-job、Application三種模式，下面說明三種部署模式的對比

這三種模式的區別在於：

• 集羣生命週期和資源隔離保證
• 應用程序的main()方法是在客戶端仍是在集羣上執行

​ 圖：1-1

Application模式

用戶程序的 main 方法將在集羣中而不是客戶端運行，用戶將程序邏輯和依賴打包進一個可執行的 jar 包裏，集羣的入口程序 (ApplicationClusterEntryPoint) 負責調用其中的 main 方法來生成 JobGraph。Application 模式爲每一個提交的應用程序建立一個集羣，該集羣能夠看做是在特定應用程序的做業之間共享的會話集羣，並在應用程序完成時終止。在這種體系結構中，Application 模式在不一樣應用之間提供了資源隔離和負載平衡保證。在特定一個應用程序上，JobManager 執行 main() 能夠節省所需的 CPU 週期，還能夠節省本地下載依賴項所需的帶寬。

Per-Job 模式

per-job模式是爲每一個提交的做業啓動Flink集羣，擁有本身的jobmanager和taskmanager。因此在啓動的時候該做業模式可能延遲會比較高點。做業完成後，集羣將銷燬，並清理全部的資源。此模式容許更好的資源隔離，由於運行有問題的做業也不會影響到其它做業。

Session模式

session模式假定一個已經在運行的集羣，並使用該集羣的資源來執行任何提交的應用程序。在同一個（會話）集羣中執行的應用程序使用相同的資源，並所以競爭相同的資源。你並無爲每一項工做付出所有的開銷。可是，若是其中一個做業行爲不當或致使TaskManager崩潰，則該TaskManager上運行的全部做業都將受到該故障的影響。除了對致使失敗的做業形成負面影響外，這意味着一個潛在的大規模恢復過程，即全部從新啓動的做業同時訪問文件系統，並使其對其餘服務不可用。另外，讓一個集羣運行多個做業意味着JobManager的負載更大，JobManager負責記錄集羣中的全部做業。這種模式很是適合於啓動延遲很是重要的短做業，例如交互式查詢。

目前信也科技在服務的容器化方面的支持已經很成熟，有一套完善的構建發佈流程，因此經過對比Flink的幾種部署模式的優缺點，最終咱們採用了Application的部署方式，該方式相比於其它兩種模式優勢明顯，擁有更好的隔離性，同時對資源的利用率也高，也更符合咱們現有的發佈流程規範。

二：Flink on k8s

​ 圖：2-1

建立Flink Kubernetes集羣時，Flink客戶端將首先鏈接到Kubernetes ApiServer提交集羣，包括ConfigMap，Job Manager。而後，Kubernetes將建立JobManager，在此期間，Kubelet將拉取鏡像，準備並掛載，而後執行啓動命令。啓動JobManager命令後，Dispatcher和KubernetesResourceManager可用，而且羣集已準備好接受一個或多個做業。當用戶經過Flink客戶端提交做業時，客戶端將生成 Job graph ，並將其與用戶jar一塊兒上傳到Dispatcher。JobManager向KubernetesResourceManager請求slots資源。若是沒有可用的slots，資源管理器生成TaskManager並在集羣中註冊。這是Flink 在在kubernetes內部的簡要交互方式。

三：構建發佈

信也採用的Flink版本爲1.11,部署模式是Application。咱們把每一個job抽象成一個應用。因此每一個job的發佈流程也就是信也普通應用同樣的發佈流程:

• 申請Flink job相關的應用
• 非1.11版本的job升級到1.11版本，並集成maven 鏡像構建打包插件
• 經過aladdin打包平臺，打包鏡像。經過stargate平臺選擇相應應用和打包的鏡像版本進行job的發佈

1.構建

​ 圖：3-1

2.發佈

​ 圖：3-2

在程序進行升級的時候，中止job能夠採用savepoint的機制來保持做業的完整快照，在下次啓動的時候能夠利用保存的savepoint來進行做業的恢復

四：監控告警

Flink部署在kubernetes上後，job的監控和運維也須要相應的配套設施才行。 當Flink job在運行過程當中掛掉了，咱們怎麼才能監控到併產生告警？job在運行過程當中可能會出現不健康的運行，好比checkpoint時間過長、gc頻繁、或者發生了重啓。這些咱們又如何監控？

1. 配置探針

Flink job在運行過程當中由jobmanager進行資源管理、做業調度，因此咱們爲每一個Flink job中的jobmanager添加探針，檢測job是否正常運行，當健康檢測不經過，咱們經過zmon平臺進行告警

readinessProbe:
        httpGet:
          path: /jobs/overview
          port: 8081
          scheme: HTTP
        initialDelaySeconds: 30
        timeoutSeconds: 3
        periodSeconds: 5
        successThreshold: 3
        failureThreshold: 12

2.指標收集

目前公司上雲的應用都是採用prometheus進行指標進行收集，因此Flink的指標收集咱們仍然採用prometheus進行收集。利用grafana進行展現（下圖進展現部分）

​ 圖：4-1

1.對於系統指標最常關注的是做業的可用性，如 uptime (做業持續運行的時間)、fullRestarts (做業重啓的次數)
2.另外是 checkpoint 相關信息，例如最近完成的 checkpoint 的時長(lastCheckpointDuration )、最近完成的 checkpoint 的大小(lastCheckpointSize )、做業失敗後恢復的能力(lastCheckpointRestoreTimestamp )、成功和失敗的 checkpoint 數目(numberOfCompletedCheckpoints、numberOfFailedCheckpoints)以及在 Exactly once 模式下 barrier 對齊時間(checkpointAlignmentTime)

五：高可用

做業可能因爲機器維護、硬件故障致使掛掉，這時候如何快速恢復做業也成爲了須要思考的問題。目前咱們採用的方式是能夠經過程序的方式自動恢復做業

以下圖：

​ 圖：5-1

注意：

由於部分job並不適用這種方式來恢復job，因此在平臺能夠設置，若是job設置了啓用高可用，默認狀況下，檢測到job掛掉，會採用checkpoint的機制來直接恢復job，若是沒有設置，job掛掉後會通知對應的job負責人，負責人收到告警後，須要手動來恢復job

六：遇到的問題

1. 網絡問題

Flink在部署的過程當中須要訪問Apiserver,這時候job須要經過clusterip來訪問ApiServer，而公司集羣採用的是macvlan網絡是沒法訪問clusterip的，因此爲了支持Flink部署，咱們在大數據集羣經過給對應pod添加雙網卡的方式（一塊是macvlan，一塊是bridge）

2. ip管理

由於Flink部署在kubernetes是採用的deployment方式部署，這種方式部署的pod，咱們沒法管理相關Flink pod的ip，因此容器雲團隊，部署了一個webhook的服務，來監聽集羣pod的相關事件，來分配和釋放相關的ip

​ 圖：6-1

3.配置問題

Flink在運行過程當中在作checkpoint和savepoint時都依賴於hdfs，因此pod在運行過程當中是須要訪問hdfs服務的，咱們是經過，將hdfs-site.xml、core-site.xml相關配置提早配置到kubernetes集羣Configmap裏，並在Flink啓動過程當中指定相應的ConfigMap

​ 圖：6-2

信也容器雲平臺

stargate做爲信也科技的容器雲平臺，是基於kubernetes開發的一套企業級容器管理平臺，具備業務場景覆蓋全面、生態豐富的特色，目前已經開源

開源地址：https://github.com/ppdaicorp/stargate

掃描加羣討論（備註：stargate）