Kedify | HTTP

Use events from HTTP to trigger autoscaling with Kedify and KEDA

HTTP-based autoscaler dynamically scales Kubernetes workloads based on real-time HTTP traffic metrics, including scale down to zero.

Overview of Kedify’s HTTP Scaler

The HTTP Scaler is a production-ready solution designed to deliver unmatched performance, stability, and ease of use for scaling based on HTTP traffic in Kubernetes environments. Built on top of the KEDA HTTP Add-On, the Kedify HTTP Scaler incorporates significant improvements that enhance stability and performance.

Key Features

Automatic Network Traffic Wiring: Simplifies configuration by automating necessary Ingress reconfigurations.
Fallback Mechanism: Ensures continuous availability by rerouting traffic during control plane issues.
Built-In Health Checks: Maintains proper health statuses for applications scaled to zero.
gRPC and Websockets Support: Enables autoscaling based on gRPC and Websockets, including scale to zero
Performance and Envoy Integration: Leverages the Envoy proxy for superior performance and reliability.

Compare the Kedify HTTP Scaler and the KEDA Community HTTP Add-On

Compare

Production Readiness

Stability and Performance

Single Point of Failure

gRPC & Websockets Support

Configuration

Automatic Network Wiring

Fallback Mechanism

Health Check Responses

Integration with Envoy

Kedify HTTP Scaler Types

kedify-http: Offers full autowiring and fallback support (documentation).
kedify-envoy-http: Utilizes an existing Envoy proxy and scales from 1 replica with limited autowiring and fallback capabilities (documentation).

Learn More

Tutorial: In-browser, step by step guide on how to use the HTTP Scaler: HTTP Scaler Tutorial
Quickstart: A step by step guide using local Kubernetes cluster: HTTP Scaler Quickstart
For detailed information, visit our blog post.

Featured Use Cases

Scenario:

Scale out a specific service that is only needed during sales events and peak traffic periods on demand. This service does not have to be running all the time, therefore we can save resources.

HTTP Scaler Usage:

Scaling is triggered based on the number of HTTP requests per second and we know that each replica of the service can handle 100 requests per second.

KEDA Usage:

We define ScaledObject with kedify-http trigger. We set minReplicaCount: 0, specify scalingMetric to requestRate and targetValue: 100. This way we can scale from 0 replicas based on the incoming traffic. We just need to define the correct host and Kubernetes service and port that the app is listening on.

Get Started

                    apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: ecommerce
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ecommerce-service
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: kedify-http
      metadata:
        hosts: ecommerce-service.company.com
        service: ecommerce-service
        port: "8080"
        scalingMetric: requestRate
        targetValue: "100"

Scenario:

Scale out AI Training workers based on the actual demand. Each worker can handle 50 concurrent requests. We can save resources by scaling down to 0 when there is no demand.

HTTP Scaler Usage:

Scaling is triggered based on the number of concurrent HTTP requests and we know that each replica of the service can handle 50 requests at the same time.

KEDA Usage:

We define ScaledObject with kedify-http trigger. We set minReplicaCount: 0, specify scalingMetric to concurrency and targetValue: 50. This way we can scale from 0 replicas based on the incoming traffic. We just need to define the correct host and Kubernetes service and port that the app is listening on.

Get Started

                    apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: ecommerce
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ai-training-worker
  minReplicaCount: 0
  maxReplicaCount: 5
  triggers:
    - type: kedify-http
      metadata:
        hosts: ai-training-worker.company.com
        service: ai-training-worker
        port: "8884"
        scalingMetric: concurrency
        targetValue: "50"

Scenario:

Scale out during sales events and peak traffic periods on demand. Using a custom Envoy proxy that is already deployed in the cluster. We do not need to utilize scale to zero, because we need at least one replica running all the time.

HTTP Scaler Usage:

Scaling is triggered based on the number of HTTP requests routed through pre-configured Envoy proxy deployed in the application's namespace.

KEDA Usage:

We define ScaledObject with kedify-envoy-http trigger. We set minReplicaCount: 1 , specify externalProxyMetricKey to the one defined in our Envoy proxy configuration and targetValue: 100. This way we can scale from 1 replica based on the incoming traffic. We just need to define the correct host and Kubernetes service and port that the app is listening on.

Get Started

                    apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: ecommerce
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: workload
  minReplicaCount: 1
  maxReplicaCount: 10
  triggers:
    - type: kedify-envoy-http
      metadata:
        scalingMetric: requestRate
        targetValue: '100'
        externalProxyMetricKey: 'my_app_com'