On Tue, Jun 20, 2017 at 8:01 AM, 'Jonathan MacMillan' via kubernetes-sig-federation <kubernetes-sig-federat...@googlegroups.com> wrote:
> [+kubernetes-sig-federation] > > On Monday, June 19, 2017 at 6:07:02 PM UTC-7, kelka...@gmail.com wrote: >> >> Hi >> >> We have been researching on Cluster Federation to built a management >> platform for our widely spread independent Kubernetes Clusters >> While doing so we came across your talk at Kubecon ( >> https://www.youtube.com/watch?v=pq9lbkmxpS8). It was quite helpful to us. >> >> >> >> I had couple of questions that will help us to move ahead with our >> project and efficient use of Cluster Federation in it. Apprecitae if anyone >> out here could spend some valuable time and helps us understand it better. >> >> Mostly its on the networking/multi cloud service communication aspect. >> >> >> >> PFB the same. >> >> Case 1)Multi-cloud service deployment networking >> 1) The concept of networking in Kubernetes is quite clear to us as far as >> individual cluster is concerned? But how do we design the networking pane >> for globally scattered kubernetes clusters (Public Cloud & Onpremise) >> managed by Cluster Federation? >> > Currently, as far as Cluster Federation is concerned, the basic working assumption is that each cluster runs on it's own private network, and that all network access between clusters is via externally visible load balancers (created and exposed in Kubernetes via either LoadBalancer Services, or Ingress). https://kubernetes.io/docs/tasks/federation/federation-service-discovery/ https://kubernetes.io/docs/tasks/administer-federation/ingress/ Interest has been expressed in supporting inter-cluster private networking, but this has not been fully designed yet, or implemented. > 2) Assuming we have 2/3 tier application, with my web & app containers on >> GCE/AWS & and my backend DB container on our private cloud. How does >> inter-service communication happen in this case? How does my web/app layer >> talk with my DB layer? >> >> >> See above. Current best practise would be to expose your DB layer as a load balancer service. If you use a Federated Service to achieve that, public DNS records will be automatically created for you. If you use a traditional Kubernetes Service, you will need to configure the public DNS records manually. > >> >> Case 2) Service Discovery across federated clusters ( Asia east, Asia >> west ) >> A single Service ( Web-FrontEnd[Asia east], MySQL-Backend[Asia >> west]) >> There are two etcd (federation controller layer, kubernetes >> cluster layer) >> >> 4) Which contents are stored in etcd at cluter federation side? >> If containers in Cluster A is lost, how does cluster federation catch >> failed container's status in Cluster A and spawn them to other available >> Cluster. >> When we spawn a service which is a collection of container...then, all >> info regarding a service stored in etcd first on Cluster A and does it >> stored it again etcd on federation side? >> >> >> I assume that you are referring to ReplicaSets, not Services (to use the Kubernetes terminology). The desired state (number of replicas etc) of the Federated Replicaset is saved in the etcd store of the Federation. The control plane of the Federation attempts to create one or more ReplicaSets in the underlying clusters (each of which is stored in that cluster's etcd), to the total number of desired replicas, and monitor's their health (number of actual replicas running in each cluster, according to the status of the replicaset in that cluster). If the replicas in one or more clusters become unhealthy, the federation control plane will replace them with replicas in other clusters if necessary. https://kubernetes.io/docs/tasks/administer-federation/replicaset/ > 5) Can we have internal dns service to use with Cluster Federation? if >> yes, What interconnections are there between SkyDNS(Kubernetes DNS) and >> Private DNS(owned by us or Commercial DDNS)? >> Who updates service url/DNS updates when one of frontend containers get >> failed?How does changes propogate? >> > https://kubernetes.io/docs/tasks/federation/federation-service-discovery/ >> >> Case 3)Inter-cluster migration in failures. >> 6) Having a common storage across cluster is not possible. Do we have any >> provision to migrate the volumes too or any plan for the same ? >> > Currently persistent storage is not automatically migrated or mirrored across clusters, but there has been interest in adding this functionality. To date, nobody has proposed a detailed design, or implemented anything in that regard, but contributions would be welcome. >> Hopefully someone in the community is also working on the same direction >> & have some inputs. >> >> >> >> -- > You received this message because you are subscribed to the Google Groups > "kubernetes-sig-federation" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kubernetes-sig-federation+unsubscr...@googlegroups.com. > To post to this group, send email to kubernetes-sig-federation@ > googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/kubernetes-sig-federation/2d99abf4-df97-4b00-a0b9-110689da4b19% > 40googlegroups.com > <https://groups.google.com/d/msgid/kubernetes-sig-federation/2d99abf4-df97-4b00-a0b9-110689da4b19%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Quinton Hoole quin...@hoole.biz -- 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.
