About

About rate limiting link

API gateways act as a control point for the outside world to access the various application services that run in your environment, whether monoliths, microservices, or serverless functions. In microservices or hybrid application architecture, these workloads accept an increasingly large number of requests.

Requests might come from:

• External clients or end users. This type of traffic is often called “north-south” and passes through the ingress gateway.
• Internal clients including other microservices in the mesh. This type of traffic is often called “east-west” and passes through the Istio service mesh gateway. To use rate limiting for east-west traffic, you must have a Gloo Mesh (Gloo Platform APIs) license in addition to your Gloo Mesh Gateway license.

Protecting backend services and globally enforcing business limits can become incredibly complex for your developers to handle at the application-level. Instead, you can use rate limiting policies to limit requests that pass through the ingress or Istio API gateway.

With rate limiting, you set a limit for the number of incoming traffic requests that an API accepts over a specific time interval, such as per second, minute, hour, or day. For example, you might say that your website can handle 1,000 requests per second.

Key benefits link

Gloo Gateway provides a set of custom resources to make it even easier to set up rate limiting for all of the microservices in your environment.

Scalable: Gloo Gateway gives you a set of reusable rate limiting resources that use Kubernetes selectors to automatically scale as your policies and workloads grow.

Reusable for ingress and mesh traffic: You can use the same resources to apply policy to both traffic into your service mesh (ingress or “north-south”) and across the services in your mesh (“east-west”).

Rate limiting APIs link

You can configure rate limiting in Gloo Gateway resources by using two primary rate limiting APIs:

• Envoy-style rate limit API, or “tree” style.
• Set-style rate limit API, for use cases wherein you want a rule to apply to all of the matching descriptors, regardless of order or other descriptors with the same values.

Both APIs make use of descriptors and actions.

Envoy API link

Gloo Gateway exposes the Envoy Go/gRPC rate limit service. You can configure a vast number of rate limiting use cases by defining rate limiting actions that specify an ordered tuple of descriptor keys to attach to a request. The descriptors match the ordered tuple of descriptor keys in the actions, and then apply the associated rate limit to the request.

Set-style API link

Although powerful, the Envoy API has some drawbacks. It limits only requests whose ordered descriptors match a rule exactly. For example, you might have a use case wherein you want to limit requests for:

• Requests with an x-type header
• Requests with both an x-type header and an x-number=5 header.

In Envoy “tree” style, you must configure two sets or “branches” of actions for each request: one that gets only the value of x-type, and another that gets the value of both x-type and x-number. At scale, this approach branches out and can become complex to configure, difficult to troubleshoot, and potentially impact performance.

In contrast, set-style descriptors are treated as an unordered set so that a policy applies if all the specified descriptors match. The order or value of other descriptors does not matter. Using the previous example, you can have the policy apply to requests with an x-type header and an x-number value of any (like a wildcard) or none.

In the Gloo Gateway API, these set-style settings have set prepended to the name. For example:

• Envoy-style: descriptors and actions
• Set-style: setDescriptors and setActions

Descriptors and actions link

Descriptors and actions are set in the RateLimitConfig resource. Then, your GlooTrafficPolicy refers to the RateLimitConfig for the rate limit policy that you want to apply to the Gateways or routes that the policy targets.

Descriptors describe the rules for which requests to rate limit. These rules are expressed as an ordered tuple of required key, optional value, and optional rate_limit fields. For more information, see the Envoy rate limiting configuration docs.

• key: The key for the rule to use to match a request. You must provide a key for each descriptor.
• value: An optional value that you can provide for the key, to further scope the rule matching.
• rate_limit: An optional value to set a rate limit for any requests that match the key and values that you set for the descriptor.
• weight: An optional value to set priority for rules.

In Envoy-style API, the complete set of descriptors must match exactly. In set-style, descriptors are matched regardless of other descriptors, so your requests can have more or fewer descriptors. The descriptors in the server config correspond to the actions in the client config.

Actions describe the action for the Envoy client to take, by matching the action to the descriptors on the server. If you specify more than one rate limit action, the request is throttled if any of those rate limiting actions is met. Actions can set up counters for requests related to:

• Source cluster
• Destination cluster
• Request headers
• Remote address
• Generic key
• Header value match
• Metadata

About the rate limiter service link

Gloo Gateway includes a deployer that automatically creates the following services to support enterprise security use cases for your Gateways. This way, you do not have to set up and configure your own services in order to use enterprise external auth and rate limiting features of the GlooTrafficPolicy.

Shared Redis database link

The Redis service stores critical operational data for both the external auth and rate limiter services as follows.

External Auth:

• API keys (plain text or hashed)
• Session data and cookies
• OIDC distributed claims
• Portal-generated API keys for end-user authentication

Rate Limiting:

• Unique request keys
• Rate limit counters and associated metadata

Setup modes link

You can choose from two setup modes:

• Shared (default): All Gateways that share the same GatewayClass automatically use the same external auth, rate limiter, and Redis services.
• Dedicated (multi-tenant): Use separate GatewayClasses for each team. Then, each team’s Gateway has its own set of ext-auth, rate limiter, and Redis services.

Shared setup (default) link

When you first install Gloo Gateway, the system does not immediately deploy the external auth service, rate limiter, or Redis. These services are only provisioned when you create the first Gateway for a GatewayClass. The Redis instance automatically gets created when either an external auth or rate limiting instance is created or enabled in the GlooGatewayParameters.

All Gateways that share the same GatewayClass automatically use the same external auth, rate limiter, and Redis services. This shared deployment model optimizes resource usage while maintaining isolation between different GatewayClasses.

Example steps:

1. Review the default GatewayClasses.

     kubectl get gatewayclasses
     

   Example output: Gloo Gateway provides two default GatewayClasses:

   • gloo-gateway-v2: Standard class for managing Gateway API ingress traffic.
   • gloo-gateway-v2-waypoint: Specialized class for Istio ambient mesh waypoint proxies.

     NAME                       CONTROLLER                ACCEPTED   AGE
   gloo-gateway-v2            solo.io/gloo-gateway-v2   True       4h41m
   gloo-gateway-v2-waypoint   solo.io/gloo-gateway-v2   True       4h41m   
     

2. Create a Gateway that references the default GatewayClass. For example, you might follow along with the Sample app guide to create an http Gateway.

     kubectl apply -f- <<EOF
   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: http
     namespace: gloo-system
     labels:
       example: httpbin
   spec:
     gatewayClassName: gloo-gateway-v2
     listeners:
     - protocol: HTTP
       port: 8080
       name: http
       allowedRoutes:
         namespaces:
           from: All
   EOF
     

3. Review the ext-auth-service, rate-limiter, and gloo-ext-cache deployments that the deployer automatically creates for you in the gloo-system namespace.

     kubectl get deployments -n gloo-system
     

   Example output:

     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
   ext-auth-service-gloo-gateway-v2            1/1     1            1           7m46s
   gloo-gateway-v2                               1/1     1            1           4h45m
   http                                        1/1     1            1           7m46s
   rate-limiter-gloo-gateway-v2                1/1     1            1           7m46s
   gloo-ext-cache-gloo-gateway-v2                1/1     1            1           7m46s
     

4. You can optionally remove the resources that you set up as part of this guide. The external auth, rate limiter, and Redis services are automatically deleted when the Gateway is deleted.

     kubectl delete Gateway http -n gloo-system
     

Dedicated setup (multi-tenant) link

If you are using Gloo Gateway in a multi-tenant environment, you can create custom GatewayClasses based off the default GatewayClasses. Then, create a Gateway that refers to the GatewayClass. The deployer automatically creates a separate set of ext-auth, rate limiter, and Redis services in the namespace of the Gateway.

1. Get the default gloo-gateway-v2 GatewayClass that you can use as the basis for your custom GatewayClass.

     kubectl get gatewayclass gloo-gateway-v2 -o yaml
     

   Example output:

     apiVersion: gateway.networking.k8s.io/v1
   kind: GatewayClass
   metadata:
     creationTimestamp: "2025-07-28T16:23:10Z"
     generation: 1
     name: gloo-gateway-v2
     resourceVersion: "829"
     uid: 6070687f-c6b9-43d0-b466-4e108bbc6364
   spec:
     controllerName: solo.io/gloo-gateway-v2
     description: Standard class for managing Gateway API ingress traffic.   
     

2. Create a custom GatewayClass based on the default GatewayClass. Make sure to use the solo.io/gloo-gateway-v2 controller so that Gloo Gateway manages the Gateway automation for you.

     kubectl apply -f- <<EOF
   apiVersion: gateway.networking.k8s.io/v1
   kind: GatewayClass
   metadata:
     name: my-team-gatewayclass
   spec:
     controllerName: solo.io/gloo-gateway-v2
     description: Custom GatewayClass for my team with isolated services
   EOF
     

3. Create a Gateway that references the custom GatewayClass.

     kubectl apply -f- <<EOF
   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: my-team-gateway
     namespace: default
   spec:
     gatewayClassName: my-team-gatewayclass
     listeners:
     - name: http
       port: 80
       protocol: HTTP
   EOF
     

4. Review the ext-auth-service, rate-limiter, and gloo-ext-cache deployments that the deployer automatically creates for you in the gloo-system namespace.

     kubectl get deployments -n gloo-system
     

   Example output:

     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
   ext-auth-service-my-team-gatewayclass       1/1     1            1           7m46s
   gloo-gateway                                1/1     1            1           4h45m
   http                                        1/1     1            1           7m46s
   rate-limiter-my-team-gatewayclass           1/1     1            1           7m46s
   gloo-ext-cache-my-team-gatewayclass         1/1     1            1           7m46s
     

5. You can optionally remove the resources that you set up as part of this guide. The external auth, rate limiter, and Redis services are automatically deleted when the Gateway is deleted.

     kubectl delete Gateway my-team-gateway -n default
   kubectl delete GatewayClass my-team-gatewayclass
     

Manage the deployments link

Manage the ext auth service, rate limiter, and Redis services that the deployer automatically creates for you.

Update resource requests and limits link

The default deployments include reasonable resource allocations, as well as Prometheus metrics endpoints and health checks as described in the following table. If you notice performance issues with the external auth or rate limiter services, check the resource usage and adjust as necessary.

To change the defaults:

1. Create a GlooGatewayParameters with your resource requests and limits in the sharedExtensions section, such as the following example. For more information, see the API docs.

     kubectl apply -f- <<EOF
   apiVersion: gloo.solo.io/v1alpha1
   kind: GlooGatewayParameters
   metadata:
     name: my-gw-params
     namespace: gloo-system
   spec:
     kube:
       sharedExtensions:
         extauth:
           enabled: true
           resources:
             requests:
               cpu: 200m
               memory: 256Mi
             limits:
               cpu: 750m
               memory: 512Mi
         ratelimiter:
           enabled: true
           resources:
             requests:
               cpu: 200m
               memory: 256Mi
             limits:
               cpu: 750m
               memory: 512Mi
         glooExtCache:
           enabled: true
           resources:
             requests:
               cpu: 256m
               memory: 512Mi
             limits:
               cpu: 1000m
               memory: 2048Mi
   EOF
     

2. Update the GatewayClass to use the new GlooGatewayParameters. The following example updates the default gloo-gateway-v2 GatewayClass.

     kubectl apply -f- <<EOF
   apiVersion: gateway.networking.k8s.io/v1
   kind: GatewayClass
   metadata:
     name: gloo-gateway-v2
   spec:
     controllerName: solo.io/gloo-gateway-v2
     description: Standard class for managing Gateway API ingress traffic.
     parametersRef:
       group: gloo.solo.io
       kind: GlooGatewayParameters
       name: my-gw-params
       namespace: gloo-system
   EOF
     

The deployer automatically updates the ext-auth-service, rate-limiter, and gloo-ext-cache deployments to use the new resource requests and limits.

Delete the deployments link

The deployer will automatically delete the deployments when at least one of the following conditions is met:

1. All the Gateways that reference the GatewayClass were deleted.
2. The given extension is disabled by setting spec.kube.sharedExtensions.<extension>.enabled to false in the GlooGatewayParameters. Use caution when disabling an extension as the deployment is deleted, even if a Gateway or GlooTrafficPolicy still uses it.

Disable the deployer link

You can disable the deployer for either or both the external auth and rate limiter services. Then, the deployer no longer creates and manages the service for you. You might disable the deployer to prevent teams from deploying their own services automatically when creating a Gateway for a GatewayClass.

1. Create a GlooGatewayParameters that disables the external auth, rate limiter, or Redis services in the sharedExtensions section, such as the following example. For more information, see the API docs.

     kubectl apply -f- <<EOF
   apiVersion: gloo.solo.io/v1alpha1
   kind: GlooGatewayParameters
   metadata:
     name: disable-deployer-gw-params
     namespace: gloo-system
   spec:
     kube:
       sharedExtensions:
         extauth:
           enabled: false
         ratelimiter:
           enabled: false
         glooExtCache:
           enabled: false
   EOF
     

2. Update the GatewayClass to use the new GlooGatewayParameters. The following example updates the default gloo-gateway-v2 GatewayClass.

     kubectl apply -f- <<EOF
   apiVersion: gateway.networking.k8s.io/v1
   kind: GatewayClass
   metadata:
     name: gloo-gateway-v2
   spec:
     controllerName: solo.io/gloo-gateway-v2
     description: Standard class for managing Gateway API ingress traffic.
     parametersRef:
       group: gloo.solo.io
       kind: GlooGatewayParameters
       name: disable-deployer-gw-params
       namespace: gloo-system
   EOF
     

3. Because the deployer no longer manages the deployments for you, manually delete any existing ext-auth-service, rate-limiter, and gloo-ext-cache deployments that used the GatewayClass.

     kubectl delete deployments -n gloo-system ext-auth-service-gloo-gateway-v2
   kubectl delete deployments -n gloo-system rate-limiter-gloo-gateway-v2
   kubectl delete deployments -n gloo-system gloo-ext-cache-gloo-gateway-v2
     

More resources link