GEP: Gateway API should support basic rate limiting (aka throttling) per (sub)path.

[nielsbasjes]

See also: kubernetes/ingress-nginx#6011
What would you like to be added:

I would like to be able to have rate limiting (throttling) as part of the standard way of defining an Ingress.
By having this a part of the api the various backends can start implementing support for it.

Why is this needed:

In general there is a need for limiting the rate at which requests are allowed to avoid overloading the servers.
Having this at this level would make this very easy to use in many places.

Also I found that in many situations the rate limit depends on the exact path.
Some are easy for the server to handle (send static content) and some are hard (like build a complex report).
So in general I want to specifiy the rat limits per sub-path on a specific ingress.

What I have in mind

Right now you can defined per host which (Prefix) paths should go to which service.
My first idea is that having the limits per prefix path of that service is probably enough for most usecases.

My first rough sketch looks like this:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
    - host: something.example.nl
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: something-service
                port:
                  number: 80
            rateLimits:
              - path: /      # I would do this relative to the 'parent path', implicitly this is always "pathType: Prefix"
                byCookie: jsessionid
                #byHeader: customerid
                #byIP
                # If nothing is specified then "global limit"
                maxPerSecond: 5
                allowBurst: 10
                delayBurst: false
              - path: /reporting
                #byCookie: jsessionid
                byHeader: customerid
                #byIP
                # If nothing is specified then "global limit"
                maxPerSecond: 1
                allowBurst: 2
                delayBurst: true

[howardjohn]

cc @mandarjog @gargnupur

[gargnupur]

This would be good to have.. In the ratelimits section, it would be good to add support for generic keys too, so that custom attributes in ingress can be used for ratelimiting..

[hbagdi]

Thanks for the issue, @nielsbasjes .

Rate-limiting is indeed a very common use-case that is tackled at the Ingress layer and most implementations have support for it. The catch here is that rate-limiting is an extremely nuanced area. It is very uncommon for different rate-limit implementations to have the exact same behavior.

The purpose of the service-apis is to design an API that can be implemented by a major subset of proxies out there, and then have extensions points for implementation-specific features. In this spirit, we added Filters to HTTPRoute (equivalent of Ingress v1 resource) which is exactly meant for use-cases like the one proposed here.
Can you take a look at Filters and see if it satisfies your use-case? If not, I'd love to hear your feedback and see how we can support your problem better.

[nielsbasjes]

I had a look at this Filters feature and (although I do not yet fully understand how it should work) it seems like a generic solution to handle variation in the available backends.

The downside I see is that it may be too generic: will it create a multitude of configurations each specific for the actual implementation used?
So where we now have a single "Ingress" which works with all backends; it seems that for ratelimiting it is going to converge towards a separate Filter (+ possibly very different config) for each and every distinct implementation.

So I was wondering if there is a way to have a basic rate limiting (like only max requests per second per global/IP/cookie) which is generic in the base implementation; and then to have the option for specific implementations (similar to creating a subclass) to add more advanced features (like the bursts in nginx) ?

[ Note that I'm unfamiliar with the code you linked to (seems like a config structure definition to me) so I have not been able to figure out what kind of config this will lead to. ]

[jmprusi]

This seems to be related to #114

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[robscott]

/remove-lifecycle rotten

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale