On Tuesday, February 28, 2017 at 2:00:41 PM UTC+8, Rodrigo Campos wrote: > On Tuesday, February 28, 2017, <[email protected]> wrote: > On Monday, February 27, 2017 at 11:33:47 PM UTC+8, Rodrigo Campos wrote: > > > On Monday, February 27, 2017, edenxia <[email protected]> wrote: > > > hi, we are working on k8s evaluation. we encountered and issue for stateful > > service replication. > > > > > > > > > > > > let's say psql as an exmaple. what we are trying to achieve are two > > scenario as below > > > > > > 1. psql master on k8s cluster on cloud ZoneA and psql slave on k8s cluster > > on ZoneB. psql master need communicate with psql slave and vice visa. > > > > > > 2. psql cluster on cloud region A need communicate with psql cluster on > > region B via VPN(or other internal channel) > > > > > > > > > > > > for scenario 1, we may achieve via setting up one cluster across multiple > > zones. > > > > > > for scenario 2, we do not see any proper solution. > > > > > > > > > If your default gateway knows how to route the VPN, then that should just > > work using IP address. > > > > > > > > > If you want a service to point to the VPN, you can also do that since kube > > 1.4/1.5 (don't remember). You can point a service to an external IP, in > > your case the IP of the psql, and that is just routes via the VPN. > > > > > > > > > The important part for those are the routing tables. I've not played with > > them in a container environment. But you can maybe have an init-container > > (not sure if that change will stick after init container finishes), or > > maybe just doing the changes in the nodes is enough. But some way to add > > the routes should be possible :-) > > > > Thanks Rodrigo. that sounds doable. we did further research. currently, some > cloud providers(for example, aws, alicloud ) are supporting internal lb but > google has not supported it.there are also other workaround (for example > https://github.com/kubernetes/contrib/tree/master/service-loadbalancer ) but > not good enough. > > > But why would you use an internal lb? For which of those scenarios? Sorry, > I'm lost (or maybe sleepy, it's 3am here :)) > > > > > > to connect different clusters, your way seems work. But need to evaluate how > to implement it. any more detail are welcome:) > > > Those were ideas, I don't have the need for any of those, so can't give you > more details. Sorry :-(
ofc. we if internal l4 lb is avaialbe. we can use it to expose psql as service via internal lb. then we can do across cluster communication. although we have to create many lbs. and purpose is that we need access service via private ip(instead of public ip) from outside of cluster -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
