Dynamic wildcard subdomain ingress for Kubernetes

Question

I'm currently using Kubernetes on GKE to serve the various parts of my product on different subdomains with the Ingress resource. For example: api.mydomain.com, console.mydomain.com, etc.

ingress.yml (current):

apiVersion: extensions/v1beta1 kind: Ingress metadata:   name: ingress spec:   rules:   - host: api.mydomain.com     http:       paths:         - backend:             serviceName: api-service             servicePort: 80   - host: console.mydomain.com     http:       paths:         - backend:             serviceName: console-service             servicePort: 80 

That works wonderfully, with the L7 GCE load balancer routing to the appropriate places. What I would like to do, however, is deploy many feature-branch deployments as subdomains to test and demonstrate new features before pushing to production. These could be something like new-stylesheet.console.mydomain.com or upgraded-algorithm.api.mydomain.com, inspired by GitLab CI's environments.

Here's a potential workflow for each deployment:

1. Create feature-api-deployment.yml
2. Create feature-api-service.yml
3. Update ingress.yml with new subdomain rule: feature.api.mydomain.com specifying serviceName: feature-api-service

But enumerating and maintaining all subdomain->service mappings will get messy with tearing down deployments, and create a ton of GCE backends (default quota is 5...) so it's not ideal.

Is there anything built in to Kubernetes that I'm overlooking to handle this? Something like this would be ideal to pick a target service based on a matched subdomain:

ingress.yml (wanted)

apiVersion: extensions/v1beta1 kind: Ingress metadata:   name: ingress spec:   rules:   - host: *.api.mydomain.com     http:       paths:         - backend:             serviceName: {value of *}-api-service             servicePort: 80 

Answer 1

There certainly isn't anything like wildcard domains available in kubernetes, but you might be able to get want you want using Helm

With helm, you can template variables inside your manifests, so you can have the name of your branch be in the helm values file

From there, you can have gitlab-ci do the helm installation in a build pipeline and if you configure your chart correctly, you can specify a helm argument of the pipeline name.

There's a great blog post about this kind of workflow here - hopefully this'll get your where you need to go.

Answer 2

here is an example:

 apiVersion: networking.k8s.io/v1     kind: Ingress     metadata:       name: ingress-wildcard-host     spec:       rules:       - host: "foo.bar.com"         http:           paths:           - pathType: Prefix             path: "/bar"             backend:               service:                 name: service1                 port:                   number: 80       - host: "*.foo.com"         http:           paths:           - pathType: Prefix             path: "/foo"             backend:               service:                 name: service2                 port:                   number: 80 

and the source.