[switching to kubernetes-users list since this isn't about developing Kubernetes itself]
For use cases like this where you need to build application-specific logic on top of the generic workload controllers, the Operator <https://coreos.com/blog/introducing-operators.html> pattern is useful. The etcd Operator <https://github.com/coreos/etcd-operator> is a good example of what's possible. In this case, it seems like you'd want to write an Operator for twemproxy+Redis. On Wed, May 31, 2017 at 5:47 AM Yuan-rui Cai <grove...@gmail.com> wrote: > Hi all, > > I'm new to k8s. I don't know if this is the right place to post such > topic. If not, I apology here, sorry to disturb you guys. > > My team is trying to deployment Redis cluster(based on > https://github.com/twitter/twemproxy ) on Kubernetes. Redis cluster based > on twemproxy uses pre-sharding to make it easy for cluster scale out/in if > we want to. We need to support scale out/in and failover through > Kubernetes. Afer some researches, I cannot find a proper way to achive all > these. > > 1. All of Deployment, ReplicationSet and ReplicationController cannot > handle such requirement since they aim at stateless application and Redis > cluster is stateful > 2. Although Kubernetes also provide a StatefulSet for stateful > application, it only provide very limit supports: 1.deployment of n > replicas follow the order of {0,1….,n-1}; 2.delete of n replication follow > the reverse order; 3.all pods of the application have a stable network > identity. > > In our case, during scale out/in, we need information of sharding > distribution of the cluster, so we can decide how we can transfer data in > sharding from one pod to another. There is no place for us to store such > information in any existing controllers. Moreover, we need controller that > can control the data transfering process. > > Is there any best practice already there? Any suggestion may be help. > Thank you! > > -- > You received this message because you are subscribed to the Google Groups > "Kubernetes developer/contributor discussion" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kubernetes-dev+unsubscr...@googlegroups.com. > To post to this group, send email to kubernetes-...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/kubernetes-dev/7c3f7ae3-d7af-4778-bf44-0f9c0c906e55%40googlegroups.com > <https://groups.google.com/d/msgid/kubernetes-dev/7c3f7ae3-d7af-4778-bf44-0f9c0c906e55%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.