search

linkerd / linkerd2

Ultralight, security-first service mesh for Kubernetes. Main repo for Linkerd 2.x.
https://linkerd.io
Apache License 2.0
10.72k stars 1.28k forks source link

Add support for rate-limiting #7278

Open ryan4yin opened 3 years ago

ryan4yin commented 3 years ago

Feature Request

What problem are you trying to solve?

by adding rate limits in the service mesh, we can avoid one service gets bombarded by requests from another service, if the another service's pods all crashed and restart concurrently.

related to: https://github.com/linkerd/linkerd2/issues/4649

How should the problem be solved?

by add support for rate-limiting in service mesh.

Any alternatives you've considered?

How would users interact with this feature?

mdnfiras commented 2 years ago

+1

rye-sw commented 1 year ago

would like to have this feature!

sekar-saravanan commented 3 months ago

+1

amit2kesari commented 2 months ago

Any updates on this feature request? Rate limiting is particularly useful when modern, mesh-hosted workloads are interacting with workloads outside of the cluster. If this ends up implemented, it might be something to consider in the feature set. https://github.com/linkerd/linkerd2/issues/4649

wmorgan commented 2 months ago

In progress. Targeting the next release (2.17) if all goes well.

4FunAndProfit commented 1 month ago

@wmorgan what a wonderful news! 😍 Will this rate limiting be possible also for egress traffic ? 🥹🥹🥹🥹 (i saw 2.17 might have egress traffic control) Indeed, may be amazing, to be able to limit traffic on egress (i have for example one use case where all my services reach one website and the website is considering this as an attack because of the absence of rate limiting and blocking us) Thanks again linkerd for your amazing work, it is really a pleasure to use your tool

DavidMcLaughlin commented 1 month ago

Thanks for the kind words @4FunAndProfit !

For 2.17 scope we are adding inbound rate-limiting only that is focused on the user story in the issue (helping service owners protect themselves from being overloaded). To that end it will be "local" rate-limiting, without requiring a central server to maintain state, etc.

For outbound rate limiting (which I'm assuming is to help prevent going over quota or managing costs, etc. that will require more accuracy than local rate limiting) that will need to be a separate effort we prioritize. Happy to listen to the community here on different needs and user stories that should be considered for that effort.