Linkerd2: Add support for rate limiting
Feature Request
It would be nice if linkerd had rate limiting.
What problem are you trying to solve?
We have problem where an application gets bombarded by requests if all the clients disconnect. I would like to be able to protect applications through rate limiting.
steve-fraser
All 4 comments
@steve-fraser in my experience, folks want to do rate limiting most often at the ingress level. Why are you looking for it on service-service traffic?
grampelberg
on 22 Jun 2020
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.
![stale[bot] picture](https://avatars3.githubusercontent.com/in/1724?v=4&s=40)
stale[bot]
on 20 Sep 2020
Service to service rate limiting is a pattern mostly used to avoid to tip over a service that is temporary under high pressure, would be a great features to have.
It is true that the server could implement rate limit itself but this is not possible with 3rd party softwares
ltagliamonte-dd
on 8 Nov 2020
Just commenting here as we are investigating LinkerD and looking at the feature set available. One of the things that would be wonderful to have in rate-limiting support is the ability to control the rate of outgoing requests from a service at the mesh level.
The difficulty is that during a scaling event, managing the request flow out of a service depends on knowing the number of live replicas of the service communicating with a particular endpoint. We run into this with legacy services, where their ability to handle requests is outpaced by modern Kubernetes-hosted workloads. When we horizontally scale the client workloads, it's quite a complex challenge to account for the pressure we put on legacy backends from within the (stateless) application. Given legacy, sometimes limiting traffic on the layers guarding the slow systems is much more difficult.
The tldr here is:
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.
bsmithyman
on 18 Nov 2020
Related issues
klingerf
路
3Comments
miklezzzz
路
3Comments
ihcsim
路
4Comments
olix0r
路
3Comments
manimaul
路
3Comments
Most helpful comment
Just commenting here as we are investigating LinkerD and looking at the feature set available. One of the things that would be wonderful to have in rate-limiting support is the ability to control the rate of outgoing requests from a service at the mesh level.
The difficulty is that during a scaling event, managing the request flow out of a service depends on knowing the number of live replicas of the service communicating with a particular endpoint. We run into this with legacy services, where their ability to handle requests is outpaced by modern Kubernetes-hosted workloads. When we horizontally scale the client workloads, it's quite a complex challenge to account for the pressure we put on legacy backends from within the (stateless) application. Given legacy, sometimes limiting traffic on the layers guarding the slow systems is much more difficult.
The tldr here is:
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.