-
Notifications
You must be signed in to change notification settings - Fork 689
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ingress V1: path matching mode #2135
Comments
So we already support regex path matching on Ingress resources but the current implementation is such that the path match type is ignored if you put something in the path field that "looks like" a regex. Seems like this regex path match deal is better suited for just the So moving forward how does this sound:
|
We could also put a changelog note and change it, although that would also not be ideal. I anticipate that the Ingress code is going to be around a long time though, so we should make it as tidy as posisble. If we don't want to do that, @sunjayBhatia's solution above seems like the only way. |
Another weird caveat that the spec wants: https://github.com/kubernetes-sigs/ingress-controller-conformance/blob/79bd068cbb31d77c2a060f61eea795f9791a3d48/features/path_rules.feature#L162 Prefix matches are not string prefix matches, but path label matches See also https://kubernetes.io/docs/concepts/services-networking/ingress/#examples
|
We specifically had to stop doing prefix matches using Go's Path support because of weird interactions with inclusion for HTTPProxy, but if we're going to meet the spec, maybe the Ingress validation code can just treat them as path labels. |
To close the loop what we ended up coming up with in office hours is the following:
|
…fix match updated to match spec (#3471) Since we already had support for regex path matching without checking the type of the path match, we now have the following rules to ensure backwards compatibility: - If you specify a prefix path match type, you get a prefix match - prefix matches only match path segments, not a string prefix - trailing slashes ignored from prefix match string - If you specify an exact path match type, you get an exact match - If you specify an implementation specific path match type you get path matching behavior that Contour already supports - If it looks like a regex we give a regex match - otherwise a string prefix match like Contour already does - ImplementationSpecific match is the default if not set when an Ingress resource is created so this should give people the default they are already using Fixes #2135 Signed-off-by: Sunjay Bhatia <[email protected]>
I must admit this is a great way to blend additional functionality with simplicity. In the openservicemesh.io project that I work on, I am upgrading our Ingress capability to v1 and was wondering how |
This path matching behavior was done b/c that was all Contour supported before implementing Ingress v1 fully and I want to say was that way b/c it mimiced the nginx Ingress implementation which came first? Someone who has been around longer can check me on that |
Support Ingress V1 path changes:
https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20190125-ingress-api-group.md#path-as-a-prefix
The text was updated successfully, but these errors were encountered: