About

Learn about the default Solo Enterprise for kgateway rate limiter.

About rate limiting

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.

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

Solo Enterprise for kgateway 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: Solo Enterprise for kgateway 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

You can configure rate limiting in Solo Enterprise for kgateway 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

Solo Enterprise for kgateway 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

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 Solo Enterprise for kgateway 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

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

Solo Enterprise for kgateway 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 EnterpriseKgatewayTrafficPolicy.

Shared Redis database

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

Rate Limiting:

• Unique request keys
• Rate limit counters and associated metadata

Setup modes

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)

When you first install Solo Enterprise for kgateway, 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 EnterpriseKgatewayParameters.

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:

   • enterprise-kgateway: Standard class for managing Gateway API ingress traffic.
   • enterprise-kgateway-waypoint: Specialized class for Istio ambient mesh waypoint proxies.

   NAME                       CONTROLLER                ACCEPTED   AGE
   enterprise-kgateway            solo.io/enterprise-kgateway   True       4h41m
   enterprise-kgateway-waypoint   solo.io/enterprise-kgateway   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: kgateway-system
     labels:
       example: httpbin
   spec:
     gatewayClassName: enterprise-kgateway
     listeners:
     - protocol: HTTP
       port: 8080
       name: http
       allowedRoutes:
         namespaces:
           from: All
   EOF

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

   kubectl get deployments -n kgateway-system

   Example output:

   NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
   ext-auth-service-enterprise-kgateway            1/1     1            1           7m46s
   enterprise-kgateway                               1/1     1            1           4h45m
   http                                        1/1     1            1           7m46s
   rate-limiter-enterprise-kgateway                1/1     1            1           7m46s
   ext-cache-enterprise-kgateway                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 kgateway-system

Dedicated setup (multi-tenant)

If you are using Solo Enterprise for kgateway 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 enterprise-kgateway GatewayClass that you can use as the basis for your custom GatewayClass.

   kubectl get gatewayclass enterprise-kgateway -o yaml

   Example output:

   apiVersion: gateway.networking.k8s.io/v1
   kind: GatewayClass
   metadata:
     creationTimestamp: "2025-07-28T16:23:10Z"
     generation: 1
     name: enterprise-kgateway
     resourceVersion: "829"
     uid: 6070687f-c6b9-43d0-b466-4e108bbc6364
   spec:
     controllerName: solo.io/enterprise-kgateway
     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/enterprise-kgateway 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/enterprise-kgateway
     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 ext-cache deployments that the deployer automatically creates for you in the kgateway-system namespace.

   kubectl get deployments -n kgateway-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
   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

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

Update resource requests and limits

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 EnterpriseKgatewayParameters 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: enterprisekgateway.solo.io/v1alpha1
kind: EnterpriseKgatewayParameters
metadata:
  name: my-gw-params
  namespace: kgateway-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
      extCache:
        enabled: true
        resources:
          requests:
            cpu: 256m
            memory: 512Mi
          limits:
            cpu: 1000m
            memory: 2048Mi
EOF