You are including proxies for clients and server? How do they compare to envoy? eg: Are you doing anything clever to handle failovers transparently for clients?
Is the metadata storage just using redis?
The core idea here is called chunk: https://github.com/doyoubi/undermoon/blob/master/docs/chunk....
Each proxy always runs in front of 2 Redis instances. Each chunk consists of 2 proxies and thus 4 Redis instances on 2 different physical servers. And each Redis has its master/replica on another half part under another proxy inside the chunk. So master and replica are always not in the same physical server. Chunk is the smallest building block of a cluster so the Redis instances number is always a multiple of 4.
We designed it in this way because we came up with an algorithm to balance the overall workload based on this chunk structure: https://github.com/doyoubi/undermoon/blob/master/docs/chunk_...
For the second question, the proxy here is just a way to add additional features on the top of Redis without changing its source code. I would say it's a server-side proxy while envoy focuses on the client-side features.
And yes, it can handle failover transparently for clients.
In Kubernetes, the metadata is stored inside a ConfigMap, which is based on etcd.