Docsright arrowEdge Stackright arrow1.14right arrowBasic rate limiting

4 min • read

Basic rate limiting

IMPORTANT: This guide applies to Emissary-ingress, use of this guide on Ambassador Edge Stack is not fully supported. Use the existing RateLimitService instead.

Emissary-ingress can validate incoming requests before routing them to a backing service. In this tutorial, we'll configure the Emissary-ingress to use a simple third party rate limit service. If you don't want to implement your own rate limiting service, Ambassador Edge Stack integrates a powerful, flexible rate limiting service.

Before you get started

This tutorial assumes you have already followed the Emissary-ingress Installation and Quickstart Tutorial guides. If you haven't done that already, you should do so now.

Once completed, you'll have a Kubernetes cluster running Emissary-ingress and the Quote of the Moment service. Let's walk through adding rate limiting to this setup.

1. Deploy the rate limit service

Emissary-ingress delegates the actual rate limit logic to a third party service. We've written a simple rate limit service that:

  • listens for requests on port 5000;
  • handles gRPC shouldRateLimit requests;
  • allows requests with the x-ambassador-test-allow: "true" header; and
  • marks all other requests as OVER_LIMIT;

Here's the YAML we'll start with:

This configuration tells Emissary-ingress about the rate limit service, notably that it is serving requests at example-rate-limit:5000.

Emissary-ingress will see the RateLimitService and reconfigure itself within a few seconds. Note that the v2 API is available for the Emissary-ingress.

2. Configure Emissary-ingress Mappings

Emissary-ingress only validates requests on Mappings which set rate limiting descriptors. If Emissary-ingress cannot contact the rate limit service, it will allow the request to be processed as if there were no rate limit service configuration.

v0 API

Emissary-ingress 0.50.0 and later requires the v2 API Version for rate limiting. The v2 API uses the labels attribute to attach rate limiting descriptors. Review the Rate Limits configuration documentation for more information.

Replace the label that is applied to the service-backend with:

so the Mapping definition will now look like this:

v2 API

Emissary-ingress versions 0.40.2 and earlier use the v2 API version which uses the rate_limits attribute to set rate limiting descriptors.

This configuration tells Emissary-ingress about the rate limit rules to apply, notably that it needs the x-ambassador-test-allow header, and that it should set "A test case" as the generic_key descriptor when performing the gRPC request.

Note that both descriptor and headers are optional. However, if headers are defined, they must be part of the request in order to be rate limited.

Emissary-ingress would also perform multiple requests to example-rate-limit:5000 if we had defined multiple rate_limits rules on the mapping.

3. Test rate limiting

If we curl to a rate-limited URL:

We get a 429, since we are limited.

If we set the correct header value to the service request, we will get a quote successfully:

More

For more details about configuring the external rate limit service, read the rate limit documentation.