1

I have a Jenkins build process that deploys our code to several Kubernetes environments. Currently, it works fantastic with known/core branches (develop, release, master) and such, BUT we would like to make all of our feature branches and bug fix branches as well. In order to do this, we currently have it deploying an ingress with branch subdomains, like "{branchName}.domain.tld". The problem here is that there is a proliferation of ingresses and such for each branch.

I would LIKE to do something like "branch.domain.tld/{branchName}" and have the ingress dynamically route based on the "branchName" path. Unfortunately I only seem to get a single ingress per subdomain/host assignment (branch.domain.tld/bugfix_nasty doesn't route because branch.domain.tld/feat_cool already is defined).

What I would like to see is a single ingress that looks something like this:

apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    name: dynamic_ingress
    annotations:
      {...stuff here}
  spec:
    rules:
    - host: branch.domain.tld
      http:
        paths:
        - path: /{branchName}/*
          backend:
            serviceName: {branchName}
            servicePort: 80

Is there anyway to get to such a zenlike ingress?

All the stuff I see about this type of thing is advice on using regex for the path to capture and route to a known, defined service. I want this to route to variable service names.

zentechinc
  • 369
  • 1
  • 5
  • 15
  • I don't understand exactly what you're trying to do, but this sounds like some of the capabilities of an Istio VirtualService. That probably doesn't help you, just noticing the similarity. – David M. Karr Mar 23 '21 at 20:07
  • In case you're using helm you could do this dynamically. In example by setting a value. Keep in mind the service name is unique and should use the same value. – Manuel Mar 23 '21 at 22:25
  • problem is, re: the helm solution and what not, if i create an ingress that uses a host from another ingress, they dont play nice, and only 1 ingress works – zentechinc Mar 23 '21 at 23:14
  • I use a solution like this in production, but rather than a Kubernetes Ingress I worked it out with a vanilla nginx deployment. We have a statefulset of what amount to dedicated servers. When our client is matchmade to one it is given the name of the server it wants, and we route to a hostname that matches the statefulset name. The nginx deployment stands in front of that and maps to the headless service given in the hostname. All this to say: it's possible, but vanilla Ingress objects aren't complex enough to provide this logic. – Adam Smith Mar 24 '21 at 04:20

1 Answers1

1

As far as I know Ingress objects don't allow what you're trying to do. But there could be a workaround if you can modify the Ingress object every time you deploy a new branch.
Whenever a new branch is deployed update your "dynamic_ingress" to include an extra path for the new branch. This can be achieved using a small utility that can read and write YAMLs which can then be applied to update the existing Ingress OR you can use kubectl patch to update the existing Ingress at deploy time.
This way the Ingress definition has static paths but neither do you have to set the paths manually nor do you need multiple Ingress objects.
So you would have something like this.

apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    name: dynamic_ingress
    annotations:
      {...stuff here}
  spec:
    rules:
    - host: branch.domain.tld
      http:
        paths:
        - path: /bug_fix_nasty/
          pathType: Prefix
          backend:
            serviceName: bug_fix_nasty
            servicePort: 80
        - path: /feat_cool/
          pathType: Prefix
          backend:
            serviceName: feat_cool
            servicePort: 80

Check out all the examples in the Ingress doc and see which suits you best.

0xf
  • 11
  • 2