Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Done
-
None
-
None
Description
Currently flink only supports HighAvailabilityService using zookeeper. As a result, it requires a zookeeper cluster to be deployed on k8s cluster if our customers needs high availability for flink. If we support HighAvailabilityService based on native k8s APIs, it will save the efforts of zookeeper deployment as well as the resources used by zookeeper cluster. It might be especially helpful for customers who run small-scale k8s clusters so that flink HighAvailabilityService may not cause too much overhead on k8s clusters.
Previously FLINK-11105 has proposed a HighAvailabilityService using etcd. As NathanHowell suggested in FLINK-11105, since k8s doesn't expose its own etcd cluster by design (see Securing etcd clusters), it also requires the deployment of etcd cluster if flink uses etcd to achieve HA.
Attachments
Issue Links
- is related to
-
FLINK-17709 Active Kubernetes integration phase 3 - Advanced Features
- Closed
-
FLINK-19545 Add e2e test for native Kubernetes HA
- Closed
- supercedes
-
FLINK-11806 Import shaded jetcd
- Closed
-
FLINK-11807 Implement etcd based LeaderElectionService and LeaderRetrievalService
- Closed
-
FLINK-11808 Implement etcd based SharedCount or sequencer
- Closed
-
FLINK-11809 Implement etcd based StateHandleStore
- Closed
-
FLINK-11810 Implement etcd based CheckpointRecoveryFactory
- Closed
-
FLINK-11811 Implement etcd based RunningJobsRegistry and SubmittedJobGraphStore
- Closed
-
FLINK-11812 Composite etcd based HighAvailability components
- Closed
-
FLINK-11105 Add a new implementation of the HighAvailabilityServices using etcd
- Closed
- links to