Rate limiting server

Review how the Gloo rate limiting server backs up data and your setup options to make the backing database more resilient. For more information about the feature, see Rate limit.

What data gets stored

The rate limiter stores information for limiting requests in the backing database, including the following information. For an example of how to check the data that gets stored, see Review data in Redis.

The configuration data of the Gloo custom resources are stored by the management server in its backing database.

Backing storage options

Review the following options for setting up backing storage.

Option Use case Benefits Drawbacks
Default: Built-in local Redis Proof of concept and staging environments in single clusters
  • The Redis instance is deployed for you as part of the default Gloo Platform installation
  • Fast read/write speed as the database is local to the management server
  • Updatable via Gloo Platform Helm chart
  • Redis GUI- and CLI-based tools help you monitor data
  • Only as highly available as your cluster setup
  • Has the same disaster recovery as your cluster setup
  • Might not meet your organization's compliance requirements
Bring your own Redis Production-level, multicluster environments
  • Enhanced high availability and disaster recovery (HA/DR)
  • Service level agreement (SLA) from your provider
  • Meet your organization's compliance requirements
  • Redis GUI- and CLI-based tools help you monitor data
  • More complicated setup
  • Not covered by Solo support (contact your external Redis provider)

Default local Redis

When you install Gloo Platform, a local Redis instance redis is set up in the gloo-mesh-addons namespace of the workload cluster. The rate limiting server automatically reads and writes to this Redis instance.

The default setup is equivalent to setting the rateLimiter.redis.enabled Helm value to true.

Using a local Redis instance is not a recommended practice for production. To achieve higher availability, disaster recovery and add other security features, bring your own Redis instance instead.

Bring your own Redis

Instead of using the built-in local Redis instance, you can achieve higher availability, disaster recovery, and enhanced control and security by bringing your own Redis cluster. You can choose between installing the Redis cluster within your Gloo workload cluster to run it alongside the rate limiter server, or to use a Redis cluster that is hosted outside the management cluster, such as by using a cloud provider service like AWS ElastiCache.

Using a Redis or AWS ElastiCache instance in cluster mode is currently not supported.

When you bring your own Redis cluster, you can customize the following aspects:

Keep in mind that your external Redis database usually must be in the same cloud provider as your Gloo cluster, such as AWS ElastiCache and EC2 instances. Also, you must configure both the Gloo external auth and Gloo portal servers in your cluster to read from and write to the same Redis database. Any settings for your Redis instance, such as the maximum number of retries, are shared between these components.

  1. Create or use an existing Redis cluster, such as AWS ElastiCache or Google Cloud Memorystore.

  2. Make sure that you can connect to your instance from the Gloo management cluster. For example, your cloud provider might require for the cluster and Redis instance to share the same virtual private network (VPC). For more information, consult your cloud provider documentation, such as AWS ElastiCache or Google Cloud Memorystore.

  3. Choose how to authenticate with your Redis cluster. Depending on your Redis provider, you might be required to use a specific authentication method, such as TLS certificates or a username and password.

  4. Create a Kubernetes secret to store your Redis authentication credentials. If you apply a YAML configuration file, make sure to encode the values in base64.

    • Username and password: If your Redis auth doesn't have an explicit username, specify default. For the password, specify your auth string.

      kubectl create secret generic redis-secrets -n gloo-mesh-addons --from-literal=redis-password=<password> --from-literal=redis-username=default
      
      kubectl apply -f- <<EOF
      apiVersion: v1
      kind: Secret
      type: Opaque
      metadata:
        name: redis-secrets
        namespace: gloo-mesh-addons
      data:
        #If Redis doesn't have an explicit username, specify ‘default’.
        username: "<username>"
        password: "<password>"
      EOF
      

    • TLS certificates:

      kubectl apply -f- <<EOF
      apiVersion: v1
      kind: Secret
      type: Opaque
      metadata:
        name: redis-certs-keys
        namespace: gloo-mesh-addons
      data:
        redis.crt: "<TLS_certificate>"
      EOF
      
  5. Follow the Upgrade guide to get your Gloo Platform Helm installation configuration file.

  6. In your Helm values file, add the following information. For more information, see the Helm reference docs.

    Helm setting Description
    extAuthService.enabled Enable this value to deploy the external auth server alongside the rate limiter server. For more backing database options, see External auth server
    If you do not include this value, any existing external auth service is removed.
    rateLimiter.enabled Enable this value to deploy the rate limiter server.
    rateLimiter.redis.enabled Set this option to false to disable the built-in local Redis deployment.
    rateLimiter.redis.hostname Replace $REDIS_HOST with the host that the Redis instance is available on. This host might need to be on the same virtual private network as your cluster or need to have a VPN connection.
    • An example Amazon ElastiCache host might look like redis-cluster.ameaqx.0001.use1.cache.amazonaws.com. For more information, see the Amazon ElastiCache docs.
    • An example Google Cloud Memorystore host might look like 10.xxx.xx.xx in the same VPC as your cluster. Note: If you use an IP address, do not include the port 6379, which is appended for you. For more information, see the Google Cloud Memorystore docs.
    rateLimiter.redis.auth.enabled Add this section if you want to authenticate with your Redis cluster by using a username and password. For the password, specify your auth string. To authenticate by using TLS certificates, remove this section and configure redis.certs instead.
    rateLimiter.redis.certs.enabled Add this section if you want to authenticate with your Redis cluster by using TLS certificates. To authenticate by using a username and password, remove this section and configure redis.auth instead.
    rateLimiter.redis.service.socket If you enable authentication via TLS certificates, set this value to tls.
    helm upgrade --install gloo-agent-addons gloo-platform/gloo-platform \
       --namespace gloo-mesh-addons \
       --create-namespace \
       --version $GLOO_VERSION \
       --set common.cluster=$CLUSTER_NAME \
       --set extAuthService.enabled=true \
       --set rateLimiter.enabled=true \
       --set rateLimiter.redis.enabled=false \
       --set rateLimiter.redis.hostname="$REDIS_HOST" \
       --set rateLimiter.redis.auth.enabled=true \
       --set rateLimiter.redis.certs.enabled=true \
       --set rateLimiter.redis.service.socket=tls
    

    If you use a Helm values file, make sure that the following settings are enabled.

    # Enable the external auth server.
    extAuthService:
      enabled: true
    # Enable the rate limiter server.
    rateLimiter:
      enabled: true
      redis:
        # Disable the default local Redis instance.
        enabled: false
        # Provide the host to your external Redis database, such as AWS ElastiCache or Google Cloud Memorystore.
        hostname: "$REDIS_HOST"
        # Optionally set to true if your Redis instance runs in clustered mode.
        clustered: false
        # Optionally enable authentication for Redis with the username and password in the referenced secret.
        # The 'secretName', 'passwordKey', and 'usernameKey' are set to the default values,
        # which you must update if you changed these in your secret.
        auth:
          enabled: true
          secretName: redis-secrets
          # The name of the data fields in your secret.
          passwordKey: password
          usernameKey: username
       # Optionally enable TLS connections to the Redis instance with the CA cert that you provide.
       # The 'mountPoint', 'caCert', 'signingKey', and 'secretName' are set to the default values, 
       # which you must update if you changed these in your secret.
       certs:
         enabled: true
         mountPoint: "/etc/tls"
         caCert: "redis.crt"
         signingKey: "redis.key"
         secretName: "redis-certs-keys"
        # Optionally configure the Redis service to use a TLS connection with the TLS certs that you provide.
        service:
          socket: tls
    
  7. Continue with the Upgrade guide to reinstall the Gloo Platform rate limiter add-on with your own Redis instance.

  8. Optional: Verify that the rate limiter server is configured with your external Redis database details.

    1. Verify that the secrets are created.
      kubectl get secrets -n gloo-mesh-addons
      
    2. Apply a basic rate limit policy and send a test request that gets rate limited.
    3. Review the rate limiting data in Redis.