Server Config (Enterprise)

To enforce rate limiting, Envoy queries an external rate limit server. You can configure changes to the rate limit server as follows.

• Configure rate limiting query behavior
• Change the default database from an internal Redis deployment to an external Aerospike, DynamoDB, or Redis database
• Debug the rate limit server

Configure Envoy rate limit query behavior

To achieve global rate limiting, Envoy queries an external server that is backed by Redis by default. You can configure the default query behavior as described in the following table.

Change the rate limit server’s backing database

By default, the rate limit server is backed by a Redis instance that Gloo Gateway deploys for you. Redis is a good choice for global rate limiting data storage because of its low latency. However, you might want to use a different database for the following reasons:

• Rate limiting across multiple data centers
• Replicating data for multiple replicas of the database
• Using an existing database
• Using a database that is external to the cluster, such as for data privacy concerns

Gloo Gateway supports the following external databases for the rate limit server:

• Aerospike
• DynamoDB
• Redis

Aerospike-backed rate limit server

You can use Aerospike as the backing storage database for the Gloo Gateway rate limit server. Aerospike is a real-time data platform with support for helpful features such as in-memory storage and streaming.

1. Create an Aerospike database instance to use as the backing storage for the rate limit server. For setup steps, see the Gloo Portal documentation.
2. To rate limit APIs that you manage with Gloo Portal, make sure that your configuration matches the configuration that you used with your Gloo Portal Storage custom resource.
3. Install or upgrade your Gloo Gateway Enterprise Helm installation by completing the following steps:
   1. Disable the default Redis server backing storage by setting rateLimit.enabled to false.
   2. Provide the rate limiting Aerospike Helm chart configuration options, as shown in the following table. These values match what you configured in your Aerospike database setup.

DynamoDB-backed rate limit server

You can use DynamoDB as the backing storage database for the Gloo Gateway rate limit server. DynamoDB is built for single-millisecond latencies. It includes features such as built-in replication (DynamoDB Global Tables) that can help you set up global rate limiting across multiple instances or multiple data centers.

1. Create a secret in your cluster that includes your AWS credentials for the DynamoDB that you want to use. The secret must be in the same namespace as your Gloo installation, such as gloo-system. For more information, see the AWS docs.

   glooctl create secret aws -n gloo-system --access-key <aws_access_key> --secret-key <aws_secret_key>
   

2. Install or upgrade your Gloo Gateway Enterprise Helm installation by completing the following steps:
   1. Disable the default Redis server backing storage by setting rateLimit.enabled to false.
   2. Provide the rate limiting DynamoDB Helm chart configuration options, as shown in the following table.

As part of the rate limit service deployment, Gloo Gateway uses the provided AWS credentials to automatically create the rate limits DynamoDB table (default name rate-limits) in your AWS region (default us-east-2). If you want to turn the table into a globally replicated table, you can select the regions to replicate to in the DynamoDB AWS console UI.

Redis-backed rate limit server

You can use a clustered Redis instance as the backing storage database for the Gloo Gateway rate limit server. Redis is an open source, in-memory database with features such as data persistence, server-side scripting and Redis Functions, extensibility, and sharding for horizontal scalability, clustering for high availability. For more information, see the Redis docs.

1. Install a clustered Redis instance in your cluster. The following example uses a Helm chart and Redis version 6. You can use the following versions of Redis with Gloo Gateway.
   • Redis 6
   • Redis 7 in Gloo Gateway 1.13 or later

   helm repo add bitnami https://charts.bitnami.com/bitnami
   helm repo update
   helm install redis -n redis bitnami/redis-cluster --set fullnameOverride=redis --set global.redis.password=redis --set image.tag=6.2.12-debian-11-r0 --version 8.1.1 --create-namespace
   

2. Create a secret with your Redis credentials in the same namespace as your Gloo Gateway installation, such as gloo-system. Make sure to encode your credentials in base64. For more information, see the Redis security docs.

   cat << EOF | kubectl apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: redis
     namespace: gloo-system
     labels:
       app.kubernetes.io/instance: redis
   type: Opaque
   data:
     redis-password: <base64_password>
     users.acl: <base64_access-control-list>
   EOF
   

3. Install or upgrade your Gloo Gateway Enterprise Helm installation by completing the following steps:

   1. Disable the default Redis server backing storage by setting rateLimit.enabled to false.

   2. Provide the rate limiting Redis Helm chart configuration options, as shown in the following table.

      redis:
        disabled: true
        clustered: true
        service:
          name: "redis.redis.svc"
          port: 6379
      

      Option	Type	Description
      redis.disabled	bool	Set to true to disable a default Redis instance, so that you can bring your own clustered Redis.
      redis.clustered	bool	Set to true to bring your own clustered Redis instance.
      redis.service.name	string	The name of the service to use to access the Redis instance, such as the default redis.redis.svc.
      redis.service.port	string	The port to access Redis on, which by default is 6379.

   3. Make sure that the rate limit server refers to the secret that you created. You can choose between the following options.

      • Override the rate limit deployment Helm values to refer to the secret. For values, see the Helm reference docs.
      • Restart the rate limit pods after creating the secret and re-installing with the clustered Redis instance.

Debug the rate limit server

1. Show the states from the Envoy proxy in your cluster.

   glooctl proxy stats
   

2. In the output, check for rate limiting errors from stats that end in ratelimit.error.

3. Start the rate limiting server locally, such as with the following command.

   kubectl port-forward -n gloo-system deploy/rate-limit 9091
   

4. Check the active configuration of the rate limiting server by opening the following localhost URL.

   localhost:9091/rlconfig
   

   For all administrative options, open the following localhost URL.

   localhost:9091
   

5. Check the backing storage database of the rate limit server.

   • Default Redis server: By default, the rate limit server uses Redis as an in-memory cache of the current rate limit counters with their associated timeouts. To check the current value of rate limit counters, inspect Redis.
     1. Start the Redis instance locally, such as with the following command.

        kubectl port-forward -n gloo-system deploy/redis 6379
        

     2. Connect to the Redis instance, such as with the redis_cli tool.
     3. Query the Redis instance, such as the following.
        • scan 0 to list all the current counters.
        • get COUNTER to inspect the current value of a counter.
   • DynamoDB: Refer to the DynamoDB docs, such as Query data or Common Errors.
   • Aerospike: Refer to the Aerospike docs, such as Troubleshooting.