Skip to main content
logoTetrate Enterprise Gateway for Envoy (TEG)Version: v1.0.x

Rate Limiting

There are myriad reasons to limit the rate of requests to an endpoint, including fair use of your resources by customers, and protection of your services by ensuring they don't go over their qps capacity.

info

The Envoy proxies used by Tetrate Enterprise Gateway for Envoy (TEG) to process and forward user requests do support a form of ratelimiting natively. However this is local-only; each proxy keeps its own count of how many requests have hit and endpoint, and can only make decisions based on that local number. Since TEG horizontally scales out the Envoys at the edge of your cluster (for both scale reasons, and to avoid single-points-of-failure), each proxy doing its own local limiting isn't sufficient to keep load on your services to a given level. What's needed is global ratelimiting, i.e. across all the proxies. This requires them to co-ordinate about the request counts for each endpoint. This in turn needs a global counter, available to all of them. TEG's batteries-included approach provides this for you as part of the standard install, realized as a Redis server available on the network.

warning

While the TEG-managed Redis instance is a great way to get started, it is not deployed in a production-hardened manner and should be considered suitable for demo purposes only.

TEG makes enforcing global rate-limits easy; configurable with a simple resource. And because TEG is layer-7 (i.e. HTTP) aware, ratelimits can be applied to individual HTTP hosts, paths, and other attributes available in the requests' HTTP headers, e.g. username.

Prerequisites

This article will just cover configuring ratelimiting. Before we can look at that, you should have a Kubernetes cluster, with TEG installed, an app deployed, and that app exposed outside of the cluster using TEG. You can follow the Expose Your Application guide to get to this point. This guide suggests you install an example httpbin instance to test with. The instructions in this article will configure ratelimiting for this httpbin instance, but you can of course change them to refer to your own app(s).

Configuring ratelimiting

  1. Ratelimiting using BackendTrafficPolicy

    First, we will configure a ratelimiting setting using BackendTrafficPolicy. This states that any endpoint subject to it will be limited to 1 request per second.

    cat <<EOF | kubectl apply -f -
    apiVersion: gateway.envoyproxy.io/v1alpha1
    kind: BackendTrafficPolicy
    metadata:
    namespace: httpbin
    name: ratelimit-1hz
    spec:
    targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: httpbin
    namespace: httpbin
    rateLimit:
    type: Global
    global:
    rules:
    - limit:
    requests: 1
    unit: Second
    EOF
  2. Test the Ratelimit

    Now let's make some requests to httpbin to see the ratelimit in action. Refer back to Expose Your Application for how to set the $DEDICATED_GATEWAY_IP environment variable, which we'll need to be able to call TEG.

    We can then make a request with curl:

    curl -i http://$DEDICATED_GATEWAY_IP/httpbin/get

    You'll see output like

    HTTP/1.1 200 OK
    server: envoy
    date: Thu, 07 Sep 2023 10:48:22 GMT
    content-type: application/json
    content-length: 334
    access-control-allow-origin: *
    access-control-allow-credentials: true
    x-envoy-upstream-service-time: 1
    x-ratelimit-limit: 1, 1;w=1
    x-ratelimit-remaining: 0
    x-ratelimit-reset: 1

    {
    ...
    }

    The body of the response isn't important; it just echos our request back at us. But the response headers clearly talk about ratelimiting (their syntax is complicated, I'll run through it below for the interested). Let's empirically check if the rate limit is working: we're allowed one request per second, so let's send two in quick succession:

    curl -i http://$DEDICATED_GATEWAY_IP/httpbin/get; curl -i http://$DEDICATED_GATEWAY_IP/httpbin/get;

    We should now see output like:

    HTTP/1.1 200 OK
    ...
    HTTP/1.1 429 Too Many Requests
    x-envoy-ratelimited: true
    ...

    The second request was denied because the ratelimit was exceeded. This is indicated by an HTTP status 429.

    info

    The status code we get is in the 400 range - these indicate client errors, i.e. we sent an invalid request. And indeed we did: we asked for resources more quickly than we were allowed. The first request was successful, and it told us (in those ratelimit headers) that we were subject to a ratelimit, and how far away we were from hitting it.

    If we were making requests at an acceptable rate (according to our SLA with the service provider), but the app couldn't keep up, that's a server-side error, and hence is indicated by a 500 range error, specifically a 503 Service Unavailable.

    That it! Our ratelimit works! You can now proceed to the next steps, or keep reading this article for some more advanced content.

  3. Configuring a Second Rule

    Ratelimits are made of buckets. A 3-per-second ratelimit is a bucket of size 3. Every request decrements that bucket's value by 1. When the bucket hits 0, no more requests are allowed. That would limit is to 3 requests ever, so to enforce a limit of 3 per second, the bucket's value is reset to 3 every 1 second.

    Ratelimit policies can have more than one rule; more than one bucket which is drained and reset. Edit your policy's rules section to look like this

        rules:
    - limit:
    requests: 1
    unit: Second
    - limit:
    requests: 20
    unit: Minute

    This enforces a policy of no more than 1 request per second, or 20 per minute. Whichever is exceeded first causes all traffic to be blocked (until it resets); think of them as being or'd rather than and'ed.

  4. Response Header Format

    Now we understand the bucket model of ratelimits, the response headers will make more sense:

    • x-ratelimit-limit: 1, 1;w=1, 20;w=60 - tells the client the ratelimit policies that are in effect. Ignore the first element for now, and focus on 1;w=1 and 20;w=60. These are the rules in our policy: 1 request in a window of 1 second (w=1), and 20 requests in a window of 60 seconds (w=60). That first number 1 is the size of the bucket we're closest to draining; the rule that will deny our requests first, and which we should take care not to exceed. The other two headers also concern this "closest" bucket...
    • x-ratelimit-remaining: 0 - how many requests are left in the close bucket. In this case 0: the current request succeeded, but the bucket is now empty, and future ones will fail, until that bucket is reset...
    • x-ratelimit-reset: 1 - how long, in seconds, until the close bucket resets to its full value. In this case that's just 1 second, as it's the 1-request-per-1-second bucket that we're in danger of exhausting.

    If you're writing the clients that will connect to TEG when it's enforcing ratelimits, they should ideally parse and act on these headers, rather than just retrying in a tight loop until they get a 200.

    If you're interested you can read the draft RFC for these headers. At this writing, Envoy is emitting version 3, even though the spec is already on version 7.