HTTP Scaling with OpenShift Routes

This guide demonstrates how to scale applications exposed via OpenShift Routes based on HTTP traffic. OpenShift Routes are the standard way to expose services in OpenShift clusters. You’ll deploy a sample application, configure an OpenShift Route, deploy a KEDA ScaledObject, and see how Kedify automatically manages the Route’s backend for efficient load-based scaling, including scale-to-zero.

Architecture Overview

For applications exposed via OpenShift Routes, Kedify leverages its autowiring feature. When using the kedify-http scaler with OpenShift Route resources, the traffic flow is adapted:

Route -> kedify-proxy -> Service -> Deployment

The kedify-proxy intercepts traffic directed by the Route, collects metrics based on the host and path defined in the ScaledObject, and enables scaling decisions. When traffic increases, Kedify scales your application up; when traffic decreases, it scales down—even to zero if configured. Kedify automatically modifies the Route’s to.name field (the backend service reference) to point to the kedify-proxy service.

Prerequisites

• A running OpenShift Container Platform (OCP) cluster.
• The oc command line utility installed and logged into your cluster.
• Connect your cluster in the Kedify Dashboard.
  • If you do not have a connected cluster, you can find more information in the installation documentation.
• Install hey to send load to a web application.

Step 1: Deploy Application and OpenShift Route

Get your default ingress domain from your OpenShift cluster and deploy the sample application, Service, and an OpenShift Route to your project/namespace:

oc get ingresses.config/cluster -o jsonpath={.spec.domain}

oc apply -f application.yaml

The combined application YAML:

application.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: application
spec:
  replicas: 1
  selector:
    matchLabels:
      app: application
  template:
    metadata:
      labels:
        app: application
    spec:
      containers:
        - name: application
          image: ghcr.io/kedify/sample-http-server:latest
          imagePullPolicy: Always
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP
          env:
            - name: RESPONSE_DELAY
              value: '0.3'
---
apiVersion: v1
kind: Service
metadata:
  name: application-service
spec:
  ports:
    - name: http
      protocol: TCP
      port: 8080
      targetPort: http
  selector:
    app: application
  type: ClusterIP
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: application-route
spec:
  host: application.<DEFAULT_DOMAIN> # Replace with your actual default ingress domain
  to:
    kind: Service
    name: application-service # Points to the application Service
  port:
    targetPort: http # Matches the service port name or number

• Deployment: Defines the simple Go-based HTTP server application.
• Service: Provides internal routing to the application Pods.
• Route: Exposes the application-service externally. OpenShift automatically assigns a hostname if spec.host is not specified. Kedify will automatically update the spec.to.name field to point to the kedify-proxy when autowiring is active.

Find the generated route hostname:

oc get route application-route -o jsonpath='{.spec.host}'

Make a note of this hostname for later steps.

Step 2: Apply ScaledObject to Autoscale

Now, apply the following ScaledObject to enable autoscaling based on HTTP traffic coming through the OpenShift Route:

oc apply -f scaledobject.yaml

The ScaledObject YAML:

scaledobject.yaml

kind: ScaledObject
apiVersion: keda.sh/v1alpha1
metadata:
  name: application
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: application
  cooldownPeriod: 5
  minReplicaCount: 0 # Enable scale-to-zero
  maxReplicaCount: 10
  fallback:
    failureThreshold: 2
    replicas: 1
  advanced:
    restoreToOriginalReplicaCount: true
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 5
  triggers:
    - type: kedify-http
      metadata:
        # Replace with the actual hostname from 'oc get route application-route'
        hosts: application.<DEFAULT_DOMAIN>
        service: application-service # The backend service name
        port: '8080' # The backend service port
        scalingMetric: requestRate
        targetValue: '1000' # Target requests per second per replica
        granularity: 1s
        window: 10s
        trafficAutowire: 'route' # Enable autowiring for OpenShift Route

Important: Replace your app hostname application.<DEFAULT_DOMAIN> in the ScaledObject metadata with the actual hostname you obtained from the oc get route command earlier.

• type (kedify-http): Specifies the Kedify HTTP scaler.
• metadata.hosts: The hostname assigned to the OpenShift Route to monitor.
• metadata.service (application-service): The Kubernetes Service associated with the application.
• metadata.port (8080): The port on the service to monitor.
• metadata.scalingMetric (requestRate): Metric for scaling.
• metadata.targetValue (1000): Target request rate.
• metadata.trafficAutowire (route): Explicitly enables Kedify’s autowiring for OpenShift Route resources. Kedify will manage the spec.to.name field in the corresponding Route to direct traffic via the kedify-proxy.

Check the Kedify Dashboard to confirm the ScaledObject is active and monitoring the specified host.

Step 3: Test Autoscale

First, verify the application is accessible via the OpenShift Route hostname:

# Replace with your actual route hostname
export ROUTE_HOST=$(oc get route application-route -o jsonpath='{.spec.host}')

curl -I http://${ROUTE_HOST}

You should receive a successful HTTP response (e.g., HTTP/1.1 200 OK).

Now, simulate higher load using hey:

# Replace with your actual route hostname
hey -n 10000 -c 150 http://${ROUTE_HOST}

Observe the results from hey and monitor the application pods (oc get pods) and the Kedify Dashboard to see the deployment scale based on the traffic.

Next steps

Consult the full HTTP Scaler documentation for more details on its features, configuration options, and how it integrates with various ingress mechanisms including OpenShift Routes.