Flink模式

Per-job Cluster

該模式下，一個作業一個集群，作業之間相互隔離，

在Per-Job模式下，集群管理器框架用于為每個提交的Job啟動一個 Flink 集群，Job完成后，集群將關閉，所有殘留的資源也將被清除，

此模式可以更好地隔離資源，因為行為例外的Job不會影響任何其他Job，另外，由于每個應用程式都有其自己的JobManager，因此它將記錄的負載分散到多個物體中，

場景：Per-Job模式適合長期運行的Job，這些Job可以接受啟動延遲的增加以支持彈性，

資源管理器支持：Yarn

Application

與per-job 模式相比，在Application 模式下，main() 方法在集群上而不是在客戶端執行，

場景：任務啟動較慢，適合于長時間運行的大型任務，

資源管理器支持：Yarn、Native kubernetes

Session

該模式下，作業共享集群資源，Session 模式提交的應用都在該集群里執行，會導致資源的競爭，

該模式優勢是無需為每一個提交的任務花費精力去分解集群，但是，如果Job例外或是TaskManager 宕掉，那么該TaskManager運行的其他Job都會失敗，除了影響到任務，也意味著潛在需要更多的恢復操作，重啟所有的Job，會并發訪問檔案系統，會導致該檔案系統對其他服務不可用，此外，單集群運行多個Job，意味著JobManager更大的負載，

場景：該模式適合于對啟動延遲要求較高且運行時間較短的作業，例如互動式查詢，任務提交速度快，適合頻繁提交運行的短時間任務，

資源管理器支持：Standalone、Yarn、Native kubernetes

Flink on kubernetes

Standalone

Standalone模式需要在任務啟動時就確定TaskManager的數量，不能像Yarn一樣，可以在任務啟動時申請動態資源，

很多時候任務需要多少個TaskManager事先并不知道，TaskManager設定少了，任務可能跑不起來，多了又會造成資源浪費，需要在任務啟動時才能確定需要多少個TaskMananger，

Standalone Application kubernetes

需要先將用戶代碼都打到鏡像里面，然后根據該鏡像來部署一個flink集群運行用戶代碼，

每提交一個任務，單獨啟動一個集群運行該任務，運行結束集群被洗掉，資源也被釋放，

Standalone Session kubernetes

在Session模式下，先啟動一個Flink集群，然后向該集群提交任務，所有任務共用JobManager，

Native kubernetes

Flink 的 Client 內置了一個 K8s Client，可以借助 K8s Client 去創建 JobManager，當 Job 提交之后，如果對資源有需求，JobManager 會向 Flink 自己的 ResourceManager 去申請資源，這個時候 Flink 的 ResourceManager 會直接跟 K8s 的 API Server 通信，將這些請求資源直接下發給 K8s Cluster，告訴它需要多少個 TaskManger，每個 TaskManager 多大，當任務運行完之后，它也會告訴 K8s Cluster 釋放沒有使用的資源，相當于 Flink 用很原生的方式了解到 K8s Cluster 的存在，并知曉何時申請資源，何時釋放資源，

Native Kubernetes Application

native kubernetes下，application模式相當于提交任務時調k8s api自動拉起一個flink集群跑該應用，然后跑完就洗掉集群，

這種模式比較適合對啟動時間不敏感、且長時間運行的作業，不適合對任務啟動時間比較敏感的場景，

優點：隔離性比較好，任務之間資源不沖突，一個任務單獨使用一個 Flink 集群；相對于 Flink session 集群而且，資源隨用隨建，任務執行完成后立刻銷毀資源，資源利用率會高一些，

缺點：需要提前指定 TaskManager 的數量，如果 TaskManager 指定的少了會導致作業運行失敗，指定的多了仍會降低資源利用率；資源是實時創建的，用戶的作業在被運行前，需要先等待以下程序，

flink on native kubernetes application模式：提交任務示例
./bin/flink run-application --target kubernetes-application
-Dkubernetes.namespace=flink-native-kubernetes
-Dkubernetes.cluster-id=flink-application-cluster
-Dkubernetes.jobmanager.service-account=flink
-Dkubernetes.container.image=flink:1.14.2
-Dkubernetes.rest-service.exposed.type=NodePort
-Djobmanager.heap.size=1024m
-Dkubernetes.jobmanager.cpu=1
-Dkubernetes.taskmanager.cpu=2
-Dtaskmanager.memory.process.size=1024m
-Dtaskmanager.numberOfTaskSlots=2
local:///opt/flink/examples/batch/WordCount.jar

應用鏡像構建方式：
`FROM flink:1.14.2
 RUN mkdir -p $FLINK_HOME/usrlib
 COPY my-flink-job.jar $FLINK_HOME/usrlib/my-flink-job.jar`

Native Kubernetes Session

native kubernetes下,session模式是提前調k8s api啟動一個常駐的flink集群，然后客戶端提交任務時，調k8s api自動起一個taskmanager pod 運行任務，然后等任務運行完之后，這個taskmanager的任務pod會被銷毀，

flink on native kubernetes session模式：

1、kubectl create namespace flink-session-cluster

2、kubectl create serviceaccount flink -n flink-session-cluster

3、kubectl create clusterrolebinding flink-role-binding-flink --clusterrole=edit --serviceaccount=flink-session-cluster:flink

啟動session集群：
4、./bin/kubernetes-session.sh \
 -Dkubernetes.namespace=flink-session-cluster \
-Dkubernetes.jobmanager.service-account=flink \
 -Dkubernetes.cluster-id=flink-session-cluster \
 -Dkubernetes.rest-service.exposed.type=NodePort  \
-Dkubernetes.container.image=flink:1.14.2

flink on native kubernetes session模式：提交任務示例
./bin/flink run -d --target kubernetes-session  \
-Dkubernetes.namespace=flink-session-cluster  \
-Dkubernetes.cluster-id=flink-session-cluster \
 -Dkubernetes.jobmanager.service-account=flink \
-Dkubernetes.rest-service.exposed.type=NodePort \
/opt/flink-1.14.2/examples/batch/WordCount.jar

總結

Flink on K8s ：

優點：

Flink 在 K8s 上最簡單的方式是以 Standalone 方式進行部署，這種方式部署的好處在于不需要對 Flink 做任何改動，同時 Flink 對 K8s 集群是無感知的，通過外部手段即可讓 Flink 運行起來，

缺點：

• 無論 Operator、Helm Chart 或者是直接使用 Kubectl Yaml 的方式，Flink 都感知不到 K8s 的存在，
• 目前主要使用靜態的資源分配，需要提前確認好需要多少個 TaskManager，如果 Job 的并發需要做一些調整，TaskManager 的資源情況必須相應的跟上，否則任務無法正常執行，
• 用戶需要對一些 Container、Operator 或者 K8s 有一些最基本的認識，這樣才能保證順利將 Flink 運行到 K8s 之上，
• 對于批處理任務，或者想在一個 Session 里提交多個任務不太友好，無法實時申請資源和釋放資源，因為 TaskManager 的資源是固定的，批處理任務可能會分多個階段去運行，需要去實時地申請資源、釋放資源，當前也無法實作，如果需要在一個 Session 里跑多個 Job 并且陸續運行結束當前也無法實作，
• 如果維持一個比較大的 Session Cluster，可能會資源浪費，但如果維持的 Session Cluster 比較小，可能會導致 Job 跑得慢或者是跑不起來，

基于這幾點，社區推進了一個 Native 的集成方案，讓Flink 原生的感知到下層 Cluster 的存在，Native 是相對于 Flink 而言的，借助 Flink 的命令就可以達到自治的一個狀態，不需要引入外部工具就可以通過 Flink 完成任務在 K8s 上的運行，

生產環境上推薦：

Flink on YARN(pre-job、application）、Flink on Native Kubernetes Appliation；

問題

Flink on Kubernetes 需考慮的問題：

日志問題

日志需要通過k8s的pod日志排查，如果出現節點宕機，pod飄移到別的節點，日志獲取困難，

應用jar包問題

flink on k8s的application模式需要將jar包以及依賴放在鏡像里啟動，

應用依賴問題

有依賴的任務，無法通過客戶端獲取資訊，k8s不支持pre-job模式，

標籤：其他

上一篇：MySQL學習筆記-事務

下一篇：分享10個高級sql寫法