Open pavelkuchin opened 4 months ago
Interesting. I am actually not sure this is obviously the wrong behavior (certainly is under-specified).
I can see the argument it should 404 - any other unmatched rule would, so why not sourceLabels?
However, this and sourceNamespace are not like other match rules; probably, they should not have been under match
but rather a top level workloadSelector
like other APIs. These APIs are not doing runtime matches, but actually filtering which workloads the VS applies to. The docs somewhat hint at this: "labels that constrain the applicability of a rule to source (client) workloads with the given labels"
Interesting. I am actually not sure this is obviously the wrong behavior (certainly is under-specified).
I can see the argument it should 404 - any other unmatched rule would, so why not sourceLabels?
However, this and sourceNamespace are not like other match rules; probably, they should not have been under
match
but rather a top levelworkloadSelector
like other APIs. These APIs are not doing runtime matches, but actually filtering which workloads the VS applies to. The docs somewhat hint at this: "labels that constrain the applicability of a rule to source (client) workloads with the given labels"
Got it, thank you for the clarification @howardjohn! It would definitely be helpful to note the behavior explicitly in the documentation. (Imho the hint is great but it makes you double guess how it really works)
Is this the right place to submit this?
Bug Description
If we match route by
sourceLabels
only and the label is not present in original pod then istio routes the request to k8s service (round robin across all subsets) instead of returning 404.If I use
queryParams
instead ofsourceLabels
then istio returns 404 as expected.The issue is reproducible in 1.22.0
Testing with label:
Testing without label:
Version
Additional Information