Envoy HTTP Scaler
Kedify Envoy HTTP Scaler ensures that your service scales based on incoming HTTP requests using a custom Envoy proxy. To use this scaler, an existing Envoy proxy is required in your environment and needs to be configured to send metrics to Kedify Scaler.
Details
The kedify-envoy-http
scaler is designed specifically for ScaledObject
resources to enable scaling based on incoming HTTP traffic using a custom Envoy proxy. Unlike kedify-http
, it does not support scaling to zero, as Envoy cannot hold traffic during scale-to-zero scenarios. The scaler monitors traffic using the custom Envoy proxy and routes traffic accordingly.
With this scaler, users can define specific metrics, such as request rate or concurrency, to determine the scaling needs of the application, ensuring optimal performance and resource utilization.
Trigger Specification
This specification describes the kedify-envoy-http
trigger, which scales workloads based on incoming HTTP traffic using a custom Envoy proxy.
Here is an example of trigger configuration using the Kedify Envoy HTTP scaler:
Parameter list:
scalingMetric
: Metric used for scaling, which can be eitherrequestRate
orconcurrency
.targetValue
: Target value for the scaling metric. When incoming traffic meets or exceeds this value, KEDA will scale out the deployment. (Default:100
)granularity
: The granularity at which the request rate is measured. For example, “1s” means one second. (Only forrequestRate
, Default:1s
)window
: The window over which the request rate is averaged. For example, “1m0s” means one minute. (Only forrequestRate
, Default:1m
)externalProxyMetricKey
: Matching external metric name, used for aggregating metrics from the Envoy proxy (e.g., specificcluster_name
for Envoy).
Example ScaledObject with Kedify Envoy HTTP Trigger
Here is a full example of a ScaledObject definition using the Kedify Envoy HTTP trigger:
Configuring Existing Envoy Proxy
The Kedify Envoy HTTP Scaler uses Envoy to route traffic and collect metrics for applications to improve reliability and performance. This setup prevents situations where the interceptor may become a bottleneck. Standard reverse proxies, such as Envoy, nginx, or HAProxy, are better equipped to handle such conditions.
To route application traffic through a custom Envoy and enable it to flush metrics to KEDA for scaling, add the following configuration snippet within your Envoy fleet. This configuration ensures that metrics are pushed to the interceptor every second, complete with all necessary labels and values for HTTP-based scaling.
Also, add the kedify_metrics_service
cluster to your static_resources
:
This utilizes the stats_sink
extension, implementing the V3 gRPC MetricsService
. For each scaled application where these Envoy metrics should be aggregated with the internal interceptor metrics, you should configure externalProxyMetricKey
in the trigger metadata:
Here, my_app_com
refers to the upstream cluster_name
from the Envoy configuration used to route the traffic to the desired application. Depending on your Envoy config, the section may look similar to this:
The two Envoy metrics that are ingested and processed are:
cluster.upstream_rq_total
- for the request rate scaling metriccluster.upstream_rq_active
- for the concurrency scaling metric