我想在kubernetes上运行一个flink作业，使用一个（持久的）状态后端看起来崩溃taskmanagers没有问题，因为如果我理解正确的话，他们可以问jobmanager需要从哪个检查点恢复。
一个失败的工作经理似乎有点困难。在这个flip-6页面上，我读到zookeeper需要知道jobmanager需要使用什么检查点来恢复和领导选举。
鉴于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 似乎很有趣，但没有后续行动
3条答案
按热度按时间jm81lzqq1#
基于till的答案和xeli的部分实现，我实现了一个基于文件的ha的轻量级版本。
您可以在这个github repo中找到代码—在生产中运行良好。
还写了一个博客系列，解释了如何在k8s上运行作业集群，并具体介绍了基于文件的ha实现。
gg0vcinb2#
对于所有对此感兴趣的人，我目前正在评估并实现一个类似的解决方案，使用kubernetes configmaps和blob存储（例如s3）来持久化job元数据，覆盖jobmanager重启。不需要使用本地存储，因为解决方案依赖于blob存储的持久状态。
github thmshmm/Flink-k8s-ha
还有一些工作要做（持久化检查点状态），但是基本的实现非常好。
如果有人喜欢使用多个职位经理，kubernetes提供了一个进行领导人选举的接口，可以利用这个接口进行选举。
ttisahbt3#
flink需要一个zookeeper集群来从jobmanager崩溃中恢复。但是，我认为您可以使用
HighAvailabilityServices,CompletedCheckpointStore,CheckpointIDCounter以及SubmittedJobGraphStore它能带你走很远。假设您始终只有一个jobmanager在运行（不完全确定k8s是否能保证这一点），并且您有一个持久的存储位置，那么您可以实现
CompletedCheckpointStore从持久性存储系统中检索完成的检查点（例如，读取所有存储的检查点文件）。此外，您将拥有一个包含当前检查点id计数器的文件CheckpointIDCounter以及所有提交的SubmittedJobGraphStore. 因此，基本思想是将所有内容存储在一个持久卷上，该持久卷可由单个jobmanager访问。