Ingress-nginx: Route path to different backends depending on http method (GET vs POST)

[gjcarneiro]

Hi, I would like to route the same URL to different backends depending on the HTTP method:

1. GET /v1/orders/ would go to one backend (since it is a DB query, potentially slow);
2. POST /v1/orders/ would go to another backend.

As far as I can tell, this is not supported. Any plans to support this scenario?

[pieterlange]

I don't think this is in scope for the ingress controller. It sounds like you're looking for something like apigee.

https://apigee.com/about/blog/digital-business/api-management-kubernetes

[aledbf]

@gjcarneiro this is possible but it will make the use or debugging more complex than it should be.

[aledbf]

Closing. This is out of the scope of the ingress controller. Please reopen if you have more questions

[mattwilliamson]

I believe it is in scope. If ingress-nginx is not supposed to route traffic to different backends depending on the traffic coming in, what is the scope it is meant to address?

[aledbf]

I believe it is in scope

I am sorry but the Ingress spec does not support this.

[gjcarneiro]

It could be supported by an annotation, perhaps? I am happy to create a separate Ingress just for this.

[smirzai]

I also think that is a useful feature to have. Http verb is part of http address just like a verb. Is there a voting mechanism we can know how many others have the same idea?
Will a pull request implementing it will be considered?

[ElvinEfendi]

ingress-nginx now has internals implemented to support multi-backend per path. Canary feature is just one feature that is built on top of it.

As a starter we can piggyback on canary and introduce another set annotations such as

alternative-backend-by-http-method: "*|POST|GET|etc."

So in the example given you would have a normal ingress defining /v1/orders/ without any extra stuff
and another ingress where canary annotation is set to true and alternative-backend-by-http-method annotation is set to POST. This would make sure POST requests on that endpoint gets proxied to the backend service configured in the second ingress where canary is enabled.

Even though we currently support only two backends, we have the foundation built to support many: https://github.com/kubernetes/ingress-nginx/blob/56bcd785107c331042e7547eca04d49ae29657ee/rootfs/etc/nginx/lua/balancer.lua#L142

We will also eventually have to come up with better annotation names.

[christhomas]

This is absolutely in scope for an ingress controller. I can't see how this is not an obvious thing to support. It's an underpinning functionality of EVERY. SINGLE. REST. API. EVER. How could you not want to support it?

If the spec doesn't include this, then update the spec. Don't downgrade expectations

[vaslabs]

I found a way that works for me, posting it here for reference, if you are using this controller. Use at your own risk :)

  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/configuration-snippet: |
      internal;
      rewrite ^ $original_uri break;
    nginx.ingress.kubernetes.io/server-snippet: |
      location /api/does/not/matter/much {
        if ( $request_method = GET) {
          set $target_destination '/_read';
        }
        if ( $request_method != GET) {
          set $target_destination '/_write';
        }
        set $original_uri $uri;
        rewrite ^ $target_destination last;
      }

And on the paths

paths:
          - path: /_read
            backend:
              serviceName: read-service
              servicePort: 8080
          - path: /_write
            backend:
              serviceName: write-service
              servicePort: 8080

This was inspired from the linked ticket on nginxinc and I tested it on a test environment. Haven't observed any weird side effects yet