Kubernetes 上的 Apache flink - 如果 jobmanager 崩溃则恢复作业
Apache flink on Kubernetes - Resume job if jobmanager crashes
我想 运行 在 kubernetes 上做一个 flink 作业，使用（持久的）状态后端似乎崩溃的 taskmanagers 不是问题，因为他们可以询问 jobmanager 他们需要从哪个检查点恢复，如果我理解正确。
崩溃的 jobmanager 似乎有点困难。在这个 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好像有点意思但是没有后续
开箱即用，Flink 需要一个 ZooKeeper 集群来从 JobManager 崩溃中恢复。但是，我认为您可以使用 HighAvailabilityServices、CompletedCheckpointStore、CheckpointIDCounter 和 SubmittedJobGraphStore 的轻量级实现，这可以让您走得更远。
鉴于您始终只有一个 JobManager 运行（不完全确定 K8s 是否可以保证这一点）并且您有一个持久存储位置，您可以实现一个 CompletedCheckpointStore 来检索来自持久存储系统的已完成检查点（例如读取所有存储的检查点文件）。此外，您将拥有一个文件，其中包含 CheckpointIDCounter 的当前检查点 ID 计数器和 SubmittedJobGraphStore 的所有已提交作业图。因此，基本思想是将所有内容存储在单个 JobManager 可以访问的持久卷上。
对于对此感兴趣的每个人，我目前评估并实施了一个类似的解决方案，使用 Kubernetes ConfigMaps 和 blob 存储（例如 S3）来持久保存 JobManager 重启后的作业元数据。无需使用本地存储，因为解决方案依赖于持久保存到 blob 存储的状态。
还有一些工作要做（保持检查点状态），但基本实现工作得很好。
如果有人喜欢使用多个 JobManager，Kubernetes 提供了一个接口来进行领导人选举，可以利用它。
基于 Till 的回答和 Xeli 的部分实现，我实现了一个基于文件的 HA 的轻量级版本。
您可以在 this github repo 中找到代码 - 运行s well in production.
还写了一个博客系列，专门解释如何 运行 job cluster on k8s in general and about this file-based HA implementation。
我想 运行 在 kubernetes 上做一个 flink 作业，使用（持久的）状态后端似乎崩溃的 taskmanagers 不是问题，因为他们可以询问 jobmanager 他们需要从哪个检查点恢复，如果我理解正确。
崩溃的 jobmanager 似乎有点困难。在这个 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好像有点意思但是没有后续
开箱即用，Flink 需要一个 ZooKeeper 集群来从 JobManager 崩溃中恢复。但是，我认为您可以使用 HighAvailabilityServices、CompletedCheckpointStore、CheckpointIDCounter 和 SubmittedJobGraphStore 的轻量级实现，这可以让您走得更远。
鉴于您始终只有一个 JobManager 运行（不完全确定 K8s 是否可以保证这一点）并且您有一个持久存储位置，您可以实现一个 CompletedCheckpointStore 来检索来自持久存储系统的已完成检查点（例如读取所有存储的检查点文件）。此外，您将拥有一个文件，其中包含 CheckpointIDCounter 的当前检查点 ID 计数器和 SubmittedJobGraphStore 的所有已提交作业图。因此，基本思想是将所有内容存储在单个 JobManager 可以访问的持久卷上。
对于对此感兴趣的每个人，我目前评估并实施了一个类似的解决方案，使用 Kubernetes ConfigMaps 和 blob 存储（例如 S3）来持久保存 JobManager 重启后的作业元数据。无需使用本地存储，因为解决方案依赖于持久保存到 blob 存储的状态。
还有一些工作要做（保持检查点状态），但基本实现工作得很好。
如果有人喜欢使用多个 JobManager，Kubernetes 提供了一个接口来进行领导人选举，可以利用它。
基于 Till 的回答和 Xeli 的部分实现，我实现了一个基于文件的 HA 的轻量级版本。
您可以在 this github repo 中找到代码 - 运行s well in production.
还写了一个博客系列，专门解释如何 运行 job cluster on k8s in general and about this file-based HA implementation。