FLINK ON K8S 基于Zookeeper和基于K8S原生HA的区别

鸿乃江边鸟

已于 2023-07-26 12:28:59 修改

阅读量1.1k

点赞数 1

分类专栏： flink k8s 大数据文章标签： kubernetes java-zookeeper flink

于 2022-10-13 09:57:31 首次发布

本文链接：https://blog.csdn.net/monkeyboy_tech/article/details/127295593

版权

大数据同时被 3 个专栏收录

127 篇文章 22 订阅

订阅专栏

flink

10 篇文章 1 订阅

订阅专栏

k8s

10 篇文章 0 订阅

订阅专栏

背景

本文基于Flink 1.13.x
Flink on K8S

分析

基于原生K8S(基于ConfigMap) HA的数据交互图如下：
在这里插入图片描述

基于Zookeeper HA的数据交互图如下:
在这里插入图片描述

可以看到这两者的最大的区别在于：

基于原生K8S的Active JobManager 会在选举成功后，持续向configMap中修改control-plane.alpha.kubernetes.io/leader的值，control-plane.alpha.kubernetes.io/leader的值如下：

annotations:
  control-plane.alpha.kubernetes.io/leader: '{"holderIdentity":"2ab0efc8-1bbc-4aae-800e-135e5d349092","leaseDuration":15.000000000,"acquireTime":"2022-10-08T04:03:26.033000Z","renewTime":"2022-10-11T13:55:46.342000Z","leaderTransitions":58949}'

基于Zookeeper的Active JobManager在选举成功后，不会周期性的修改zknode里面的内容

这是为什么?
这是因为两者领导选举机制的实现不一样：

基于K8S原生HA的实现是基于组件KubernetesLeaderElector
基于k8s的HA最终是基于ConfigMap来实现的(谁先创建了configMap就是leader),必须定期的修改configMap里面的某一项值(内部实现是基于renewTime等)，来向其他StandBy的JobManger表明，当前Active JobManager是活着的，具体的实现细节参考：KubernetesLeaderElector.run
基于Zookeeper的HA的实现是基于组件LeaderLatch
该方法的实现原理是基于zk的顺序的临时节点来实现的(谁先创建了该节点就是leader)，而该方法的实现不需要Active JobManager周期修改里面的数据，因为Zookeeper的临时节点的特性就是，如果创建该节点的客户端挂了，该临时节点会自动删除，这样，其他standBy的JobManager可以通过该临时节点存在与否来判断是否Active节点存在，从而进行领导选举，具体的实现细节见LeaderLatch.internalStart

结论

通过以上分析，我们可以得到如下优劣:

基于K8S原生的HA，会定期修改ConfigMap的值，导致watch该ConfigMap的客户端会定期收到很多事件，而这种定期事件，最终会影响到K8S的ETCD集群的稳定性，从而影响K8S集群的稳定性
基于Zookeeper的HA，只有在Active节点下线以后，watch的节点才会收到对应的事件，相比K8S那种方式，对ZK的压力会小很多。