<p>Is it possible to configure an <code>nginx</code> class ingress in Kubernetes with a backend reference to a captured group from a path regex? There is no indication of this in the ingress-nginx docs <a href="https://kubernetes.github.io/ingress-nginx/user-guide/ingress-path-matching/" rel="nofollow noreferrer">https://kubernetes.github.io/ingress-nginx/user-guide/ingress-path-matching/</a></p>
<p>I am trying to reduce the complexity of ingress path / backend definitions, e.g. from this:</p>
<pre><code>...
spec:
  rules:
    - http:
      paths:
        - path: /some/backend1/*
          backend: 
            serviceName: backend1
        - path: /some/otherbackend/*
          backend:
            serviceName: otherbackend
</code></pre>
<p>to something like this:</p>
<pre><code>
spec:
  rules:
    - http:
      paths:
        - path: /some/([^/]+)/(.+) 
          backend: 
            serviceName: $1  # or \1 - possible to ref a capture group here?

</code></pre>
<p>In the above example, the match regex for <code>path</code> matches &quot;any character that isn't a '/' repeated&quot; - i.e. it will match the next URI part until '/'. Am then looking to pass into <code>serviceName</code>.</p>
<p>Is this possible?</p>
<p><em>edit</em></p>
<p>I have found a way to shoe horn this into working. This is not an ideal way of doing it, because I am injecting an override directly into nginx configs. Would sort of functionality similar to this be worth requesting as an nginx controller feature?</p>
<p>I have posted a solution to get it working below, even though there are concerns with it - see the disclaimer / concerns below.</p>

Brett
<p>disclaimer: Before reproducing this, it is useful to know some of the concerns around working with nginx config directly - <a href="https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-snippets/#disadvantages-of-using-snippets" rel="nofollow noreferrer">see this</a> -</p>
<pre><code>apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: dynamic-routing-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/use-regex: &quot;true&quot;
    nginx.ingress.kubernetes.io/configuration-snippet: |
      set $proxy_upstream_name &quot;default-$BackendService-8088&quot;;
spec:
  rules:
  - http:
    paths:
    - path: /dynamci/(?&lt;BackendService&gt;[^/]+)(.+)?
      pathType: ImplementationSpecific
      backend:
        service:
          name: backendservice
          port:
            number: 8088
</code></pre>
<p>Now requests to <code>/dynamic/x-backend</code> will get routed to <code>x-backend</code> service, if it exists. Heavily caveated - assuming you have consistent spec for the service definitions (e.g. host / port / namespace / etc).</p>
<p>The link above that discusses lack of robustness is that the nginx controller translates to nginx config in a correlated way, and now you are taking that + sanity checks (e.g. by the admission verifier), as well as understanding internal controller naming conventions into the ingress definition. Without the <code>configuration-snippet</code> annotation, the nginx location block would set <code>proxy_upstream_name</code> to something like <code>default-backendservice-8088</code>, but then the config snippet injects another <code>set $proxy_upstream_name</code> parameter later, that matches the name of the captured group from the regex - so you have to know how the back references are created and manually maintain this, while ensuring that the override proxy parameter is consistent with how all your services are defined (e.g. if you have different backend services running on different ports, this won't solve for it and it starts becoming much more complex pretty quick).</p>
<p>While it does get the desired functionality, am not sure if I'll take this forward because of reliability / robustness concerns....</p>
