Very helpful John, thank you. I think #1 is what I'm looking to do; just wasn't sure where to start. I think I can connect the clusters on a private network using google vpc, so that should address the security issues. I'll start messing around/learning the kube-dns service and stubdomains.
Cheers, Geige On Tuesday, March 13, 2018 at 3:27:01 PM UTC-7, John Belamaric wrote: > If you have multiple clusters, you should give each a unique cluster domain > anyway, rather than just ’cluster.local’. From your description below your > pod IPs are routable between the clusters. In that case, you have a couple > ways to do this: > > > > > > 1) You could expose the kube-dns service externally to the cluster and setup > each kube-dns with stubDomains to the other kube-dns for their cluster > domains (or if you are using CoreDNS use unique server blocks with proxy > stanzas). Exposing this > externally could lead to DoS attacks on the cluster DNS though (and > therefore basically the whole cluster), so it depends on your environment and > firewall/security group setup to be safe. > > > > > > 2) You can use a custom build of CoreDNS and include the Kubernetai plugin: > https://github.com/coredns/kubernetai which allows CoreDNS to talk to > multiple API servers and serve up their > records with different cluster domains. That is safer (assuming your API > server is already externally available). > > > > > > > > > > For either solution, this is really only useful for Headless services. For > clusterIP services it will give non-routable answers though (i.e., the > service IPs won’t be routable between your clusters). > > > > > > > > > John > > > > > > > > > > On Mar 13, 2018, at 5:28 PM, 'Ahmet Alp Balkan' via Kubernetes user > discussion and Q&A <kubernet...@googlegroups.com> wrote: > > > > > > Closest thing you can get is > https://github.com/kubernetes-incubator/external-dns but I don't think it has > support for StatefulSet ordinal numbers, mostly because > it's not a common scenario to expose individual pods to the Internet > publicly. > > > > > > However, you may still make use of external-dns to manage public dns records > to each pod, although it may require some work. > > > > > > > > > On Tue, Mar 13, 2018 at 2:24 PM gv <gei...@gmail.com> wrote: > > > > Kubernetes StatefulSets create internal DNS entries with stable network IDs. > The docs describe this here: > > > > ------------------------------------------------------------------------------ > > Each Pod in a StatefulSet derives its hostname from the name of the > StatefulSet and the ordinal of the Pod. The pattern for the constructed > hostname is $(statefulset name)-$(ordinal). The example above will create > three Pods named web-0,web-1,web-2. A StatefulSet > can use a Headless Service to control the domain of its Pods. The domain > managed by this Service takes the form: $(service > name).$(namespace).svc.cluster.local, where “cluster.local” is the cluster > domain. As each Pod is created, it gets a matching DNS subdomain, > taking the form: $(podname).$(governing service domain), where the governing > service is defined by the serviceName field on the StatefulSet. > > -------------------------------------------------------------------------------- > > > > I am experimenting with headless services, and this works great for > communication between individual services i.e > web-0.web.default.svc.cluster.local can connect and communicate with > web-1.web.default.svc.cluster.local just fine. > > > > Is there any way that I can configure this to work outside of the cluster > network as well, where "cluster.local" is replaced with something like > "clustera.com"? > > > > I would like to give another kubernetes cluster, lets call it > clusterb.com, access to the individual services of the original cluster > (clustera.com); I'm hoping it would look something like clusterb simply > hitting endpoints like > > web-1.web.default.svc.clustera.com and > web-0.web.default.svc.clustera.com. > > > > Is this possible? I would like access to the individual services, not a load > balanced endpoint. > > > > -- > > 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-us...@googlegroups.com. > > To post to this group, send email to > kuberne...@googlegroups.com. > > Visit this group at > https://groups.google.com/group/kubernetes-users. > > 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-use...@googlegroups.com. > > To post to this group, send email to > kuberne...@googlegroups.com. > > Visit this group at > https://groups.google.com/group/kubernetes-users. > > 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.
