istio
Support Virtual Service route match percentage
Fixes to https://github.com/istio/istio/issues/39880
Add percentage support in Virtual Service route match, this will configure runtime_fraction match in Routes.
This is useful for a couple of usecases:
- applying different timeout, retries configurations in a subset of requests to test changes
- routing a subset of traffic to a different service when service migrations are happening. (route destinations are not usable because they are used by teams to perform deployments)
🤔 🐛 You appear to be fixing a bug in Go code, yet your PR doesn't include updates to any test files. Did you forget to add a test?
Courtesy of your friendly test nag.
😊 Welcome @sschepens! This is either your first contribution to the Istio api repo, or it's been a while since you've been here.
You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines by referring to Contributing to Istio.
Thanks for contributing!
Courtesy of your friendly welcome wagon.
@howardjohn what do you think? we're in need of this and is not easy to implement other way
Will Gateway API support this?
I don't really know, I'm not really much involved into Gateway API. But I don't think Gateway API will ever cover all the features we have in Virtual Services, such as the stat_prefix option.
Will Gateway API support this?
I don't really know, I'm not really much involved into Gateway API. But I don't think Gateway API will ever cover all the features we have in Virtual Services, such as the
stat_prefixoption.
As we always said it's the future, should think about it before making decision.
As we always said it's the future, should think about it before making decision.
Sure, it might be the future, but in my opinion it's currently very limited and there a very small subset of features of VirtualServices that are currently covered, there's still a very long way to go and standards evolve pretty slow, I don't think it's best for Istio to stop inovating in the mean time.
I'll let others chime in though
Given VS API reaches GA, and Gateway API is future of our networking API, I would like to also understand if this is planned for GW API. @keithmattix @howardjohn @robscott may have some insights.
I'm fairly certain this won't be coming to Gateway API any time soon. I think the use-case is valid (if somewhat niche) and agree that Istio generally shouldn't stop innovating even though we want Gateway API to be the default experience. My main question is whether the use-case is worth the complexity of implementation and support
https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/traffic_splitting#traffic-shifting-between-two-upstreams
It doesnot mention traffic shifting across more than three clusters, not sure if it suites. And use case is mostly like weighted clusters
My main question is whether the use-case is worth the complexity of implementation and support
The implementation itslef is very simple, you can check the PR, it's really like 5 lines of code, the rest is mostly tests.
It doesnot mention traffic shifting across more than three clusters, not sure if it suites. And use case is mostly like weighted clusters
Most use-cases are probably OK with weighted clusters, but route percent match enables much more versatility and applying different route configurations for each given percentage. Also playing with percentages is slightly less troublesome than playing with weights (whenever a weight changes, you most probably have to adjust all other wieghts as well).
So that's what we should think about: should we make first class API to support a corner case, and at the same time it won't be part of Gateway API(It has been described as the future on many occasions)?
There's already a bunch of corner cases exposed in the API, so what's the logic to tell which ones are ok and which ones are not?
Direct Reponses, VS Delegates, sourceLabels, sourceNamespace, statPrefix, to name a few, are examples of niche or corner cases that are not supported by Gateway API and we had no trouble implementing.
There's already a bunch of corner cases exposed in the API, so what's the logic to tell which ones are ok and which ones are not?
Direct Reponses, VS Delegates, sourceLabels, sourceNamespace, statPrefix, to name a few, are examples of niche or corner cases that are not supported by Gateway API and we had no trouble implementing.
It is based on number of users' asks either in slack or github or in community meetings. So far, we haven't seen a lot of asks for https://github.com/istio/istio/issues/39880 based on engagement from GitHub.
PR needs rebase.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
