本文最初發布于Zalando網站Technology Blog板塊，經原作者授權由InfoQ中文站翻譯并分享

最近，我在用Apache Flink構建小型的流處理應用。在Zalando，我們默認使用Kubernetes進行部署，所以計劃將Flink和開發的一些作業都部署到Kubernetes集群上。在這個過程中，我學到了很多關于Flink和Kubernetes的知識，在這篇文章里會和大家分享一下。

一些挑戰

首先是合規性。在Zalando，正產環境運行的代碼必須經過至少2人的審核，并且所有部署的內容都可以追溯到git commit。通常部署Flink任務會將包含有任務和依賴的JAR包上傳到運行中的Flink集群，但這不符合我們內部的合規流程。

其二是容器編排的成熟度。Flink一個重要的賣點是支持容錯的流處理。但如下一節所述，在容器編排系統中沒有設計可靠性相關的功能，這使得在Kubernetes上運行Flink集群并不是你想的那么簡單。

其三是碎片化的文檔。不論是Flink還是Kubernetes都在快速的發展中，這使一些文檔很容易就過時了（就像我這篇blog，或者是論壇/新聞組的帖子）。可惜的是，對于如何在Kubernetes上可靠地運行Flink，現在官方文檔能提供的信息還不夠完善。

Flink的架構和部署模式

為了理解如何在Kubernetes集群上部署Flink，需要先對其架構和部署模式有個大致的了解。如果你已經很熟悉Flink了，可以跳過本節。

Flink由作業管理器（Job Manager）和任務管理器（Task Manager）兩個部分組成。作業管理器協調流處理作業，管理作業的提交及其生命周期，并將工作分配給任務管理器。任務管理器執行實際的流處理邏輯。同一時間只可能有一個活躍的作業管理器，但任務管理器可以有n個。

為了實現彈性的、有狀態的、流式的處理，Flink使用了檢查點（Checkpointing）來周期性地記錄各種流處理操作的狀態，并進行持久化存儲。從故障中恢復時，流處理作業可以從最新的檢查點繼續執行。檢查點的操作由作業管理器進行協調，它知道最新完成的檢查點的位置，這在后面會很重要。

Flink集群可以以兩種獨立的模式運行：第一種叫Standalone或者叫Session Cluster，是一個可以運行多個流處理作業的單一集群。任務管理器在作業之間共享。第二種叫作業集群Job Cluster，專門用于運行單個流處理作業。

Flink集群可以在HA模式下運行。在這個模式下，多個作業管理器的實例同時運行，其中的一個會被選舉為leader。如果leader失效了，會從其他運行的作業管理器中選出一個新的leader。Flink使用Zookeeper來進行leader選舉。

部署Kubernetes

在上文提到的兩種模式中，我們選擇了Job Cluster模式來運行Flink。有兩個原因：第一是因為Job Cluster的Docker鏡像需要包含有Flink作業的JAR包。這能很好地解決合規性問題，因為我們可以重復使用與常規JVM應用相同的工作流程。第二個原因是這種部署模型能為每個Flink作業獨立地擴展任務管理器。

我們將作業管理器作為一個部署（Deployment）并設置了1副本，任務管理器設置了n副本。任務管理器通過Kubernetes服務發現作業管理器。這個設置和官方文檔不太相同，官方文檔是建議將Job Cluster的作業管理器當做Kubernetes的作業來運行。但我們認為這種場景下（一個永不停止的流任務）使用部署的方式會更可靠，因為可以確保有一個pod一直在運行，而作業是可以完成的，使得集群可以沒有任何作業管理器。這就是為什么我們的設置比較類似于文檔中關于session cluster的描述。

作業管理器pod的失效由部署控制器（Deployment Controller）來處理，它會負責生成新的作業管理器。鑒于這是相對較快的操作，我們無需在熱備份中維護多個作業管理器，不然會增加部署的復雜性。任務管理器使用Kubernetes服務來定位作業管理器。

如上文所述，作業管理器會在內存中保留一些和檢查點相關的狀態。在作業管理器崩潰時，這些狀態會丟失，所以我們會在Zookeeper中持久化這些狀態。這意味著即使沒有選舉leader的需求以及Flink HA模式的發現功能（就像Kubernetes本身處理的那樣），仍然需要用到Zookeeper來存儲檢查點的狀態。

我們在Kubernetes集群上已經部署了etcd集群和etcd-operator，所以不想再引入另一個分布式調度系統了。我們試了一下zetcd，這是一個基于etcdv3的Zookeeper API。用著挺順利，所以我們決定堅持下去。

在這種設置下我們會遇到另一個問題，作業管理器有時會陷入不健康的狀態，而只有通過重啟作業管理器才能解決。這個我們會通過livenessProbe來解決，它會檢查作業管理器是否健康、作業是否仍然在運行。

還需要注意的是，這個設置僅適用于Flink大于1.6.1的版本，因為存在無法從job cluster的檢查點恢復的bug。

小結

上面的設置在生產環境中已經運行了好幾個月，并能很好地服務于我們的用例。這也說明，即使在實現的過程中會遇到一些小障礙，在Kubernetes上平穩地運行Flink還是可行的。

原文鏈接：https://jobs.zalando.com/tech/blog/running-apache-flink-on-kubernetes/index.html

總結

以上是生活随笔為你收集整理的如何在Kubernetes上运行Apache Flink的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。