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 <kubernetes-users@googlegroups.com<mailto:kubernetes-users@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<mailto: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<http://clustera.com/>"? I would like to give another kubernetes cluster, lets call it clusterb.com<http://clusterb.com/>, access to the individual services of the original cluster (clustera.com<http://clustera.com/>); I'm hoping it would look something like clusterb simply hitting endpoints like web-1.web.default.svc.clustera.com<http://web-1.web.default.svc.clustera.com/> and web-0.web.default.svc.clustera.com<http://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-users+unsubscr...@googlegroups.com<mailto:kubernetes-users%2bunsubscr...@googlegroups.com>. To post to this group, send email to kubernetes-users@googlegroups.com<mailto: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. -- 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<mailto:kubernetes-users+unsubscr...@googlegroups.com>. To post to this group, send email to kubernetes-users@googlegroups.com<mailto: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. -- 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.
