Migration from KEDA to Kedify

This guide provides step-by-step instructions for migrating from the upstream KEDA project to Kedify, including how to handle HTTPScaledObjects migration.

Migration Overview

Migrating from KEDA to Kedify is straightforward and requires minimal changes to your existing configuration. The process involves uninstalling KEDA components, migrating specific resource types, and installing Kedify.

Step 1: Uninstall KEDA and KEDA HTTP Add-on

Before installing Kedify, you need to remove the existing KEDA installation and KEDA HTTP Add-on (if installed) from your cluster.

Danger

Uninstalling KEDA will also remove all KEDA-managed resources, including ScaledObjects (SOs) and ScaledJobs (SJs).

If you want to preserve original replica counts on the workloads after removal, see the docs for restoreToOriginalReplicaCount.

Uninstall KEDA HTTP Add-on

If you have the KEDA HTTP Add-on installed, remove it first:

# If installed with Helm
helm uninstall keda-add-ons-http --namespace keda

# If installed with kubectl
kubectl delete -f https://github.com/kedacore/http-add-on/releases/latest/download/keda-add-ons-http.yaml

Note

After uninstalling the KEDA HTTP Add-on, you will need to update your ingress resources to point directly to your workload services instead of the Interceptor component.

Kedify will handle traffic autowiring automatically through its traffic autowiring feature.

Uninstall KEDA

Remove the KEDA installation:

# If installed with Helm
helm uninstall keda --namespace keda

# If installed with kubectl (update the version appropriately)
kubectl delete -f https://github.com/kedacore/keda/releases/latest/download/keda-2.18.0.yaml

Note

Replace the version number with your installed KEDA version if different.

Step 2: ScaledObjects Compatibility

Good news! Any ScaledObjects that worked with KEDA will continue to work with Kedify without any modifications. No action is needed for existing ScaledObjects.

Kedify maintains full backward compatibility with KEDA ScaledObjects, so your existing autoscaling configurations will work seamlessly.

Step 3: Migrate HTTPScaledObjects to ScaledObjects

If you were using HTTPScaledObjects from the KEDA HTTP Add-on, you need to migrate them to ScaledObjects using the Kedify HTTP Scaler.

HTTPScaledObject vs ScaledObject Comparison

The HTTPScaledObject resource from KEDA HTTP Add-on needs to be converted to a ScaledObject with a kedify-http trigger. Here’s how the key fields map:

HTTPScaledObject Field	ScaledObject Equivalent	Notes
spec.hosts	triggers[].metadata.hosts	Comma-separated string in ScaledObject
spec.pathPrefixes	triggers[].metadata.pathPrefixes	Comma-separated string in ScaledObject
spec.scaleTargetRef.service	triggers[].metadata.service	Service name
spec.scaleTargetRef.port	triggers[].metadata.port	Port as string
spec.scaleTargetRef.portName	triggers[].metadata.portName	Port name
spec.scaleTargetRef.name	spec.scaleTargetRef.name	Deployment name
spec.scaleTargetRef.kind	spec.scaleTargetRef.kind	Resource kind
spec.scaleTargetRef.apiVersion	spec.scaleTargetRef.apiVersion	API version
spec.replicas.min	spec.minReplicaCount	Minimum replicas
spec.replicas.max	spec.maxReplicaCount	Maximum replicas
spec.scaledownPeriod	spec.cooldownPeriod	Cooldown period
spec.scalingMetric.concurrency.targetValue	triggers[].metadata.targetValue + scalingMetric: concurrency	Concurrency metric
spec.scalingMetric.requestRate.targetValue	triggers[].metadata.targetValue + scalingMetric: requestRate	Request rate metric
spec.scalingMetric.requestRate.window	triggers[].metadata.window	Time window for rate calculation
spec.scalingMetric.requestRate.granularity	triggers[].metadata.granularity	Time granularity

Migration Example

Here’s a practical example showing how to migrate an HTTPScaledObject to a ScaledObject:

Original HTTPScaledObject:

apiVersion: http.keda.sh/v1alpha1
kind: HTTPScaledObject
metadata:
  name: http-demo
  namespace: default
spec:
  hosts:
    - www.my-app.com
  pathPrefixes:
    - "/"
  scaleTargetRef:
    name: http-demo-deployment
    apiVersion: apps/v1
    kind: Deployment
    service: http-demo-service
    port: 8080
  replicas:
    min: 0
    max: 10
  scalingMetric:
    requestRate:
      targetValue: 10
      window: 1m
      granularity: 1s
  scaledownPeriod: 300

Migrated ScaledObject:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: http-demo-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: http-demo-deployment
  minReplicaCount: 0
  maxReplicaCount: 10
  cooldownPeriod: 300
  triggers:
    - type: kedify-http
      metadata:
        hosts: www.my-app.com
        pathPrefixes: "/"
        service: http-demo-service
        port: "8080"
        scalingMetric: requestRate
        targetValue: "10"
        window: "1m"
        granularity: "1s"

Key Migration Notes

1. Hosts and Path Prefixes: Convert arrays to comma-separated strings
2. Port Values: Convert numeric ports to strings
3. Scaling Metrics: Specify the metric type explicitly (requestRate or concurrency)
4. Target Values: Convert to strings
5. Trigger Type: Use kedify-http as the trigger type

Step 4: Install Kedify

After removing KEDA and migrating your HTTPScaledObjects, install Kedify following the installation guide.

Verification

After completing the migration:

1. Verify Kedify Components: Check that all Kedify components are running:

   kubectl get pods -n keda

2. Verify ScaledObjects: Ensure your ScaledObjects are ready:

   kubectl get scaledobjects

3. Test Scaling: Verify that your applications scale correctly with the new configuration.

Getting Help

If you encounter issues during migration:

• Check the troubleshooting guide for common issues
• Review the Kedify HTTP Scaler documentation for advanced configuration options
• Collect debug information using the Kedify configuration guide

The migration from KEDA to Kedify is designed to be smooth and minimize disruption to your applications while providing enhanced functionality and support.