I have a following use case:
Our customers frequently release new services on their K8s clusters. These new services are reachable from the outside world through a load balancing and Ingress to dynamically configure this load balancing once a service is deployed. This makes it really easy for the development teams of our customers because they don’t have to wait until somebody configures a load balancing manually. They can just create their own Ingress resource next to their service deployment and the service will be reachable.
A customer asked if we can also enable that each of its services can have its own subdomain automatically. So once a new application is deployed it, it should be available as a subdomain of the cluster domain (e.g. https://helloworld.cyvh5.k8s.ginger.aws.gigantic.io) as well as at their own subdomain (e.g.. helloworld.awesome-customer.com).
I have found this resource as a starting point.
My questions are:
Can I achieve the customer subdomain dynamic binding in some other (better) way?
What are the possible limitations / pitfalls for the suggested solution?
Thanks!
Yeah for 1 ingress sounds great.
For 2 it sounds to me like you just need wildcard DNS pointing at the ingress controller. The wildcard DNS entry should say that *.domain.com should point to the ingress controller's external IP. Then host-based Ingress rules/resources can be deployed and traffic can be routed to the appropropriate Service based on the host specified in the request. So it doesn't matter what is in the wildcard part of the DNS of a request insofar as 'a.b.domain.com' will go to the ingress controller and it will then depend on what rules are in the Ingress resources as to where it ends up.
This won't be 'automatic' in the sense that the customer will have to deploy an Ingress rule or two if they want the service exposed on two hosts. But if the customer is happy with deploying Ingress resources then they should be happy with this too.
I don't think you need anything more dynamic because in 'helloworld.awesome-customer.com' it seems 'helloworld' is the service so that fills out your host so there's no need for a wildcard in the Ingress rule itself. What would be more dynamic and more like the example you point to is if they were asking for 'v1.helloworld.awesome-customer.com' and 'v2.helloworld.awesome-customer.com' and for both to be covered by one Ingress entry containing a wildcard (rather than two entries, one per version). But it seems they are not asking for that.
This is how I see the customer domain part anyway. I am not exactly sure what you mean about the cluster domain part - for that I'd need to better understand how that is accessed. Presumably it is again wildcard DNS pointing at something doing routing but I'm not as sure about what is doing the routing there. If the point is that you want to achieve this then it could just be that it's another wildcard DNS entry pointed at the same ingress controller with additional Ingress resources deployed.