Kubernetes 上的 Apache flink - 如果 jobmanager 崩溃则恢复工作

Question

我想在 kubernetes 上运行 flink 作业，使用（持久的）状态后端，崩溃的任务管理器似乎没有问题，因为如果我理解正确，他们可以询问作业管理器他们需要从哪个检查点恢复。

一个崩溃的工作经理似乎有点困难。在这个flip-6 page 我读到需要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好像很有意思但是没有后续

Answer 1

根据 Till 的回答和 Xeli 的部分实现，我实现了基于文件的 HA 的轻量级版本。
您可以在 this github repo 中找到代码 - 在生产环境中运行良好。

还写了一个博客系列，解释如何运行job cluster on k8s，特别是关于这个file-based HA implementation。

Answer 2

对于对此感兴趣的每个人，我目前使用 Kubernetes ConfigMaps 和 blob 存储（例如 S3）来评估和实施一个类似的解决方案，以在 JobManager 重新启动时持久保存作业元数据。无需使用本地存储，因为该解决方案依赖于持久化到 blob 存储的状态。

Github thmshmm/flink-k8s-ha

还有一些工作要做（保持检查点状态），但基本实现工作得很好。

如果有人喜欢使用多个 JobManager，Kubernetes 会提供一个接口来进行领导者选举，这可以用于此目的。

Answer 3

开箱即用，Flink 需要 ZooKeeper 集群才能从 JobManager 崩溃中恢复。但是，我认为您可以拥有HighAvailabilityServices、CompletedCheckpointStore、CheckpointIDCounter 和SubmittedJobGraphStore 的轻量级实现，这可以让您走得更远。

假设你只有一个 JobManager 一直在运行（不完全确定 K8s 是否可以保证这一点）并且你有一个持久存储位置，你可以实现一个 CompletedCheckpointStore 从持久存储系统中检索完成的检查点（例如读取所有存储的检查点文件）。此外，您将拥有一个文件，其中包含 CheckpointIDCounter 的当前检查点 id 计数器和 SubmittedJobGraphStore 的所有提交的作业图。因此，基本思想是将所有内容存储在单个 JobManager 可以访问的持久卷上。