We've discussed adding a feature for this but don't have a solution yet. It would likely require the pod to ask for the data since routes can be late bound. It may also imply that we endorse the idea of "primary name" (which we are extremely close to with the way route host names are defaulted).
The easiest approach would be to allow DNS to provide the answer (SVC.NS.external.cluster.local CNAME to the app author selectable primary name). That's a bit harder to script than a downward API, but is consistent with the new ExternalName service in Kube/OS 1.4 (where you can CNAME a service to another DNS name). Early binding in the template is problematic if admins are using custom routers and couples templates to routes too closely. Adding downward API for the pod is probably too hard. We've discussed having a controller write an annotation to the service indicating the desired external name but users would not have an easy way to get at that info. On Sep 23, 2016, at 3:11 PM, Jonathan Yu <jaw...@redhat.com> wrote: On Fri, Sep 23, 2016 at 11:19 AM, Gary Franczyk <gary.franc...@availity.com> wrote: > From the point of your application, is there a way to tell what the route > name(s) are that point to the pod that your application is in? > Generally, no - after all, you can create multiple routes that point to the same service/set of pods. Some ideas: - You can potentially examine the Host header on first-touch to see what clients are using to connect (wait for a request, create certificates etc on first access - this is similar to what web servers like Caddy do for their Let's Encrypt certificate) - Use the Kubernetes API to determine which service your pod belongs to, then which routes point to that service. But this likely relies on assumptions about the way your application is set up, since these relationships are many-to-one (a service points to a pod, but many services could point to the same pod; same applies for routes) - Use an environment variable to tell pods their external hostname (but this means you need to set this and the route name and keep them in sync) Cheers, Jonathan _______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
_______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
