[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.

Reply via email to