我想在kubernetes上运行一个flink作业，使用一个（持久的）状态后端，看来崩溃的任务管理器似乎没有问题，因为如果我理解正确的话，他们可以问任务管理器他们需要从哪个检查点恢复。
崩溃的工作经理似乎要困难一些。在此flip-6 page上，我读到了Zookeeper，以便能够知道工作经理需要使用哪个检查点进行恢复和领导选举。
看到kubernetes会在崩溃时重新启动jobmanager，是否有办法让新的jobmanager无需设置Zookeeper集群即可恢复工作？
我们正在寻找的当前解决方案是：当kubernetes想杀死jobmanager时（例如，因为它想将其移至另一个vm），然后创建一个保存点，但这仅适用于正常关机。
编辑： http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/Flink-HA-with-Kubernetes-without-Zookeeper-td15033.html似乎很有趣，但是没有后续行动
答案 0 :(得分：4)
开箱即用，Flink需要ZooKeeper群集才能从JobManager崩溃中恢复。但是，我认为您可以使用HighAvailabilityServices，CompletedCheckpointStore，CheckpointIDCounter和SubmittedJobGraphStore的轻量级实现，这可以带给您很大的帮助。
鉴于您始终始终只运行一个JobManager（不能完全确定K8是否可以保证这一点），并且您有一个持久性存储位置，则可以实现一个CompletedCheckpointStore，该持久性存储从持久性中检索完成的检查点。存储系统（例如，读取所有存储的检查点文件）。此外，您将拥有一个文件，其中包含CheckpointIDCounter的当前检查点ID计数器和SubmittedJobGraphStore的所有已提交的作业图。因此，基本思想是将所有内容存储在单个JobManager可以访问的持久卷上。
答案 1 :(得分：1)
基于Till的回答和Xeli的部分实现，我实现了基于文件的HA的简化版本。
您可以在this github repo中找到该代码-在生产环境中运行良好。
还写了一个博客系列，解释了一般如何运行job cluster on k8s以及具体如何运行file-based HA implementation的情况。
答案 2 :(得分：0)
对于对此感兴趣的每个人，我目前都使用Kubernetes ConfigMaps和Blob存储（例如S3）评估并实现类似的解决方案，以持久保存作业元数据，从而使JobManager重新启动。无需使用本地存储，因为该解决方案依赖于持久保存到Blob存储的状态。
仍然需要做一些工作（保持Checkpoint状态），但是基本实现却相当不错。
如果某人喜欢使用多个JobManager，Kubernetes提供了一个界面来进行领导者选举，可以用于此。