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

Services are available locally as

my-svc.svc.cluster.local

You can write a simple NGINX proxy which can forward which can parse the subdomain and proxy pass it to http://$service as long as the subdomain and service name matches as in this case.