在 Kube.netes 中使用 ingress-nginx 时，是否可以使用路径中捕获的组配置后端？

Question

Is it possible to configure an nginx class ingress in Kube.netes with a backend reference to a captured group from a path regex? There is no indication of this in the ingress-nginx docs https://kube.netes.github.io/ingress-nginx/user-guide/ingress-path-matching/

I am trying to reduce the complexity of ingress path / backend definitions, eg from this:

...
spec:
  rules:
    - http:
      paths:
        - path: /some/backend1/*
          backend: 
            serviceName: backend1
        - path: /some/otherbackend/*
          backend:
            serviceName: otherbackend

to something like this:

spec:
  rules:
    - http:
      paths:
        - path: /some/([^/]+)/(.+) 
          backend: 
            serviceName: $1  # or \1 - possible to ref a capture group here?

In the above example, the match regex for path matches "any character that isn't a '/' repeated" - ie it will match the next URI part until '/'. Am then looking to pass into serviceName .

Is this possible?

edit

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?

I have posted a solution to get it working below, even though there are concerns with it - see the disclaimer / concerns below.

Answer 1

disclaimer: Before reproducing this, it is useful to know some of the concerns around working with nginx config directly - see this -

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: dynamic-routing-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/configuration-snippet: |
      set $proxy_upstream_name "default-$BackendService-8088";
spec:
  rules:
  - http:
    paths:
    - path: /dynamci/(?<BackendService>[^/]+)(.+)?
      pathType: ImplementationSpecific
      backend:
        service:
          name: backendservice
          port:
            number: 8088

Now requests to /dynamic/x-backend will get routed to x-backend service, if it exists. Heavily caveated - assuming you have consistent spec for the service definitions (eg host / port / namespace / etc).

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 (eg by the admission verifier), as well as understanding internal controller naming conventions into the ingress definition. Without the configuration-snippet annotation, the nginx location block would set proxy_upstream_name to something like default-backendservice-8088 , but then the config snippet injects another set $proxy_upstream_name 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 (eg 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).

While it does get the desired functionality, am not sure if I'll take this forward because of reliability / robustness concerns....