Open adityamandaleeka opened 2 years ago
Transferred from discussions. Thanks @pinkfloydx33 for the suggestion.
The Kubernetes Ingress resource doesn't have a concept of "HTTP Method", so AFAIK configuring two resources with the same host and path would be invalid.
I even looked at the newer Kubernetes Gateway API and that has the same limitation relating to HTTP methods.
Are you attempting to route a POST
request to one backend and non-POST requests to another? Or are you trying to enforce auth at the ingress controller?
Auth at the ingress controller. In our case YARP is acting as an API gateway and does authorization there.
K8s doesn't have a concept of HTTP method, you are correct. But that doesn't matter. It does support two Ingress
resources with the same hosts
and path
. In what I am proposing, HTTP methods would be codified in the metadata.annotations
with all the other YARP route configuration.
In my use case I would create three Ingress
resources:
paths
(or a single path with a regex route pattern). Auth metadata via annotations would indicate I want YARP to use some authorization policyIngress
would have a single path
, authorization annotation and a hypothetical HTTP method annotation with a value of "get/put/delete/patch"
Order
annotation and no HTTP methodsIngress
would have a single path
(the same one from the second bullet), no authorization annotation, and a hypothetical HTTP method annotation for "post"
Order
annotation if one were available and bullet two only used that I could likely get this down to two Ingress
resources with a bit of thinking. In any case, it's the second and third bullets that are of note. As far as K8S is concerned they'd have the same host
, path
and ingressClass
which is a supported scenario. As different resources they'd have to have different names; the YARP ingress controller would treat them as distinct routes, as it should. Without any annotations/metadata this would be an issue as there would be two YARP routes with the exact same match configuration. If HTTP methods was a supported annotation this would work just fine as the two routes created on the YARP end would have different set of match criteria.
This is a supported scenario with Ingress
resources managed by ingress-nginx
(via metadata.annotations
) as well as with Istio's VirtualService
(via spec.http.match.method
) and I'm sure others. I know the goal isn't parity, but figured I'd call these cases out.
I'm posting from my cell, but I can provide hypothetical Ingress
examples later.
I believe this can be resolved as done now.
Discussed in https://github.com/microsoft/reverse-proxy/discussions/1825