我正试图在kubernetes上部署高可用的flink集群。在下面的示例中，工作节点被复制，但我们只有一个主pod。
https://github.com/apache/flink-statefun
据我所知，有两种方法可以让工作经理变得快乐。
https://ci.apache.org/projects/flink/flink-docs-stable/ops/jobmanager_high_availability.html
https://medium.com/hepsiburadatech/high-available-flink-cluster-on-kubernetes-setup-73b2baf9200e
在第一个示例中，我们部署另一个作业管理器，以便在发生故障时在它们之间进行切换；在第二个示例中，kubernetes在发生故障时重新部署作业管理器pod
所以我有几个问题
对于这两个示例，当活动作业管理器失败时，正在运行的作业会发生什么情况？
第一个场景可以应用于kubernetes吗？
在第二种情况下，如果作业管理器出现故障，flink ui将在pod恢复之前不可用，但在第二种情况下，它将可用，对吗？
两种方案的优缺点是什么？
1条答案
按热度按时间o2gm4chl1#
有一种方法可以使job manager成为ha，您的两个链接都是使用jm-ha，使用zookeeper集群来创建jm的主/备体系结构。
当jobmanager失败时，会出现“故障转移”，如apache flink文档（第一个链接）中所描述的，备用jm将变为活动状态。
当然，kubernetes只是整个flink集群的部署，您仍然可以使用ha集群模式使用zk。
不，两者都将使“故障转移”和备用jm变为活动状态。
你不知道kubernetes只是flink的部署集群，就像你可以在物理/虚拟服务器上部署它一样，而你可以在kubernetes上部署它，但是像高可用性这样的东西将保持不变。
编辑：你可以在jobmanager的kubernetes中创建2个或更多的pod，然后它将等于第一个解决方案。