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

<p><strong>ingress.yml (current)</strong>:</p>

<pre><code>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
</code></pre>

<p>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 <code>new-stylesheet.console.mydomain.com</code> or <code>upgraded-algorithm.api.mydomain.com</code>, inspired by GitLab CI's <a href="https://docs.gitlab.com/ce/ci/environments.html" rel="noreferrer">environments</a>.</p>

<p>Here's a potential workflow for each deployment:</p>

<ol>
<li>Create feature-api-deployment.yml</li>
<li>Create feature-api-service.yml</li>
<li>Update ingress.yml with new subdomain rule: <code>feature.api.mydomain.com</code> specifying <code>serviceName: feature-api-service</code></li>
</ol>

<p>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.</p>

<p>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:</p>

<p><strong>ingress.yml (wanted)</strong></p>

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

<p>There certainly isn't anything like wildcard domains available in kubernetes, but you might be able to get want you want using <a href="http://helm.sh/" rel="noreferrer">Helm</a></p>

<p>With helm, you can template variables inside your manifests, so you can have the name of your branch be in the helm <a href="https://github.com/kubernetes/helm/blob/master/docs/chart_template_guide/values_files.md" rel="noreferrer">values file</a></p>

<p>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.</p>

<p>There's a great blog post about this kind of workflow <a href="http://blog.lwolf.org/post/how-to-create-ci-cd-pipeline-with-autodeploy-k8s-gitlab-helm/" rel="noreferrer">here</a> - hopefully this'll get your where you need to go.</p>
