search

solo-io / gloo

The Feature-rich, Kubernetes-native, Next-Generation API Gateway Built on Envoy
https://docs.solo.io/
Apache License 2.0
4.09k stars 441 forks source link

resource selection based on label(s) or need #5530

Open ianrudie-tmus opened 2 years ago

ianrudie-tmus commented 2 years ago

Is your feature request related to a problem? Please describe. Customers consuming our gloo-edge product report rates of health checks higher than they expect. Upon investigation we found that upstreams are added to envoy as clusters regardless of whether or not any virtual service references them. Because we have gloo managing 2 separate gateway-proxy instances we have upstreams being configured in instances where they are not used however these still produce healthcheck calls.

Describe the solution you'd like For virtual services this is handled via a label selector. I think this is a suitable solution which would work for upstreams and RLCs (really any resources which make sense to limit to a single gateway-proxy instance). Additionally it would be suitable if RLCs and upstreams were only configured based on need (example: they are referenced by a matcher in a virtual service). Either solution or potentially both solutions seems workable.

We have also had issues with the size of our proxy resources and reducing the number of things configured in the proxy resources which are not used would likely help with this issue as well.

Describe alternatives you've considered The only other solution we think might be workable would be to limit gloo to managing only a single gateway-proxy instance. This would be a significant re-architecture of the solution we've deployed though. If gloo can support better boundaries between multiple gateway-proxy tentents that would be ideal

Additional context One possible multi-tenency model as implemented for gloo-edge virtual service resources can be found here.

lgadban commented 2 years ago

related: https://github.com/solo-io/gloo/issues/5087

asayah commented 2 years ago

I think #5087 is a better path forward here. having a selection on upstream can cause coordination issues, the easiest would be just to create an upstream if it is used by a virtual service or a roundtable

github-actions[bot] commented 4 months ago

This issue has been marked as stale because of no activity in the last 180 days. It will be closed in the next 180 days unless it is tagged "no stalebot" or other activity occurs.