Automating wildcard subdomain support for Kubernetes using Helm operator

问题

Here is my use case: We have a customer, where each of their services has to be available on dedicated subdomain. Naming convention should be service-name.customerdomain.com, where service-name is the deployed service and customerdomain.com is the customer domain. When a new service is created, it should be available automatically, i.e. once service-name service is deployed into the cluster, it has to be available on service-name.customerdomain.com.

I know, this can be achieved manually by following steps:

1. Add Ingress controller to the cluster

2. Create wildcard DNS *.customerdomain.com and point it to the Ingress controller

3. Map subdomain for each running service. For every existing service from the cluster create a separate section into Ingress resource file ingress.yaml, e.g.

Spec:     
    rules: 
    - host: helloworld.awesome-customer.com 
    http: 
        paths: 
        - path: /* 
        backend: 
            serviceName: helloworld 
            servicePort: 8080 
    - host: nextfineapp.awesome-customer.com 
    http: 
        paths: 
        - path: /* 
        backend: 
            serviceName: nextfineapp 
            servicePort: 8080 
    - [...]

4. Add Ingress resource file new -host section for each newly deployed service
5. Remove Ingress resource file -host section for each removed service

Basically - I would like to automate steps 4 & 5. I am aware Ingress cannot handle this by itself, however, googling around, it appears that updating ingress.yaml file each time a new service is deployed / an existing one is removed can be achieved via Helm and its values files.

I would appreciate if a sample solution can be pointed out / described below.

回答1:

You would generally do this by having a template for the Ingress resource as a part of your base application chart. You can have more than one Ingress object and they will all get muxed at run time to build the routing table for your controller.

回答2:

I'd recommend going with @coderanger's suggestion. If you add the Ingress in a helm chart then it can be controlled via the values.yaml file. This is what the official kubernetes helm charts do. However, it isn't exactly automation of creating the Ingress as the templated Ingress source file is still there. It is templating rather than automating.

For further automation you could look at Jenkins-X expose controller. That would need to be deployed in your cluster and then it would watch what services are deployed and what annotations they have on them to automatically create Ingresses. With this you still need the annotations though as you have to indicate which services to expose and what routing logic to apply to them. If you are using helm your values files end up similar whether using expose controller or putting Ingress resources in the charts.

The Jenkins-X expose controller can also work with wildcard DNS. Actually Jenkins-X uses wildcard DNS and expose controller by default so you could follow one of their guide to see this in action. Because they support this for different platforms their docs can be helpful in seeing how to setup wildcard DNS for different cloud providers e.g. https://aws.amazon.com/blogs/opensource/continuous-delivery-eks-jenkins-x/

来源：https://stackoverflow.com/questions/53952561/automating-wildcard-subdomain-support-for-kubernetes-using-helm-operator