kvcache-ai/Mooncake

Fork 0

mirror of https://github.com/kvcache-ai/Mooncake.git synced 2026-11-05 01:17:55 +00:00

[GH-ISSUE #1321] [Feature Request]: Support Kubernetes Lease Based Master Election in Mooncake Store #434

New issue

Closed

opened 2026-10-29 21:14:26 +00:00 by bsakaguchi · 5 comments

bsakaguchi commented

2026-10-29 21:14:26 +00:00

Owner

Originally created by @kangyifei on GitHub (Jan 4, 2026).
Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/1321

Originally assigned to: @kangyifei on GitHub.

Describe your feature request

When Mooncake Store is deployed in high-availability mode, ETCD, as the centralized election database, also needs to be deployed. But High-availability deployment of ETCD in Kubernetes Cluster is also a complex task, and Mooncake Store only stores one key in etcd (in P2PHANDSHAKE mode).

The requirement for co-deploying ETCD increases the difficulty of production deployment. Therefore, we propose using Kubernetes' native election mechanism, LEASE, to replace ETCD and simplify the deployment of Mooncake Store in Kubernetes clusters.

We will submit the relevant PR soon.

Before submitting a new issue...

Make sure you already searched for relevant issues and read the documentation

Originally created by @kangyifei on GitHub (Jan 4, 2026). Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/1321 Originally assigned to: @kangyifei on GitHub. ### Describe your feature request When Mooncake Store is deployed in high-availability mode, ETCD, as the centralized election database, also needs to be deployed. But High-availability deployment of ETCD in Kubernetes Cluster is also a complex task, and Mooncake Store only stores one key in etcd (in P2PHANDSHAKE mode). The requirement for co-deploying ETCD increases the difficulty of production deployment. Therefore, we propose using Kubernetes' native election mechanism, LEASE, to replace ETCD and simplify the deployment of Mooncake Store in Kubernetes clusters. We will submit the relevant PR soon. ### Before submitting a new issue... - [x] Make sure you already searched for relevant issues and read the [documentation](https://kvcache-ai.github.io/Mooncake/)

bsakaguchi

2026-10-29 21:14:26 +00:00

closed this issue
added the
stale

auto-closed
labels

bsakaguchi commented

2026-10-29 21:14:28 +00:00

Author

Owner

@ykwd commented on GitHub (Jan 5, 2026):

Thanks for the proposal. For leader election, installing an additional etcd instance just for a single key does feel somewhat wasteful. If Kubernetes is already in use, being able to leverage Kubernetes mechanisms to avoid deploying etcd would indeed be a nice improvement.

That said, I would suggest keeping the Kubernetes-based approach as an optional alternative rather than a replacement for etcd. The reasons are:

In non-Kubernetes environments, if we want to support multiple master replicas, deploying etcd is simpler than deploying Kubernetes.
One of the ongoing efforts is to support persistence of KV metadata so that newly joined masters can obtain information about already stored KVs, and this feature will rely on etcd to store additional metadata.

@ykwd commented on GitHub (Jan 5, 2026): Thanks for the proposal. For leader election, installing an additional etcd instance just for a single key does feel somewhat wasteful. If Kubernetes is already in use, being able to leverage Kubernetes mechanisms to avoid deploying etcd would indeed be a nice improvement. That said, I would suggest keeping the Kubernetes-based approach as an optional alternative rather than a replacement for etcd. The reasons are: 1. In non-Kubernetes environments, if we want to support multiple master replicas, deploying etcd is simpler than deploying Kubernetes. 2. One of the ongoing efforts is to support persistence of KV metadata so that newly joined masters can obtain information about already stored KVs, and this feature will rely on etcd to store additional metadata.

bsakaguchi commented

2026-10-29 21:14:28 +00:00

Author

Owner

@kangyifei commented on GitHub (Jan 5, 2026):

Thanks for the proposal. For leader election, installing an additional etcd instance just for a single key does feel somewhat wasteful. If Kubernetes is already in use, being able to leverage Kubernetes mechanisms to avoid deploying etcd would indeed be a nice improvement.

That said, I would suggest keeping the Kubernetes-based approach as an optional alternative rather than a replacement for etcd. The reasons are:

In non-Kubernetes environments, if we want to support multiple master replicas, deploying etcd is simpler than deploying Kubernetes.

One of the ongoing efforts is to support persistence of KV metadata so that newly joined masters can obtain information about already stored KVs, and this feature will rely on etcd to store additional metadata.

Sorry for the misunderstanding. My original description was misleading. What we actually want to propose is an optional alternative leader election mechanism using K8s Lease, as you suggested

We'd like to submit our PR soon.

@kangyifei commented on GitHub (Jan 5, 2026): > Thanks for the proposal. For leader election, installing an additional etcd instance just for a single key does feel somewhat wasteful. If Kubernetes is already in use, being able to leverage Kubernetes mechanisms to avoid deploying etcd would indeed be a nice improvement. > > That said, I would suggest keeping the Kubernetes-based approach as an optional alternative rather than a replacement for etcd. The reasons are: > > 1. In non-Kubernetes environments, if we want to support multiple master replicas, deploying etcd is simpler than deploying Kubernetes. > 2. One of the ongoing efforts is to support persistence of KV metadata so that newly joined masters can obtain information about already stored KVs, and this feature will rely on etcd to store additional metadata. Sorry for the misunderstanding. My original description was misleading. What we actually want to propose is an optional alternative leader election mechanism using K8s Lease, as you suggested We'd like to submit our PR soon.

bsakaguchi commented

2026-10-29 21:14:28 +00:00

Author

Owner

@ykwd commented on GitHub (Jan 5, 2026):

Cool. Looking forward to your PR!

@ykwd commented on GitHub (Jan 5, 2026): Cool. Looking forward to your PR!

bsakaguchi commented

2026-10-29 21:14:28 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Jun 9, 2026):

This issue has had no activity for 90 days and will be closed in 7 days if there is no further activity. Please comment or react if it should stay open.

@github-actions[bot] commented on GitHub (Jun 9, 2026): This issue has had no activity for 90 days and will be closed in 7 days if there is no further activity. Please comment or react if it should stay open.

bsakaguchi commented

2026-10-29 21:14:28 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Jun 17, 2026):

Closing due to 3 months of inactivity. If this is still relevant, please comment and we can reopen.

@github-actions[bot] commented on GitHub (Jun 17, 2026): Closing due to 3 months of inactivity. If this is still relevant, please comment and we can reopen.