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.

Reply via email to