Common Issues

Diagnosing and resolving common issues you might encounter with Kedify and KEDA.

Collecting Debug Information

When encountering issues with Kedify, collecting comprehensive debug information is essential for effective troubleshooting. See Collecting Kedify Configuration for detailed instructions on gathering all necessary configuration and log data using the kubectl-kedify plugin or standalone script.

Unknown scaler type kedify-http or kedify-envoy-http

If you deployed a ScaledObject with the trigger kedify-http or kedify-envoy-http and the ScaledObject is not ready, you might encounter one of the following error messages in the KEDA Operator logs:

• no scaler found for type: kedify-http
• no scaler found for type: kedify-envoy-http

This indicates that you are using an unsupported KEDA distribution. These scalers (HTTP and Envoy HTTP) are supported only with the Kedify build of KEDA.

You need to uninstall your current KEDA distribution and ensure you are using Managed mode during the Kedify installation.

Kedify Agent is unable to connect to the Kedify service

The Kedify Agent connects using gRPC over port 443. Check to make sure port 443 is open and you are able to make outbound network connections.

A ScaledObject does not create KPA

KPA requires a compatible Kedify KEDA installation with KPA enabled. Check the ScaledObject annotation and status first:

kubectl get scaledobject <name> -n <namespace> -o yaml
kubectl get kpa,hpa -n <namespace>

autoscaling.kedify.io/class must be kpa, unless the installation default is KPA. KEDA rejects an invalid class, a KPA selection when KPA support is disabled, an explicit class: kpa on an existing ScalingGroup member, or a conflicting autoscaler instead of creating two controllers for the same target. If an explicitly KPA-selected ScaledObject newly matches a ScalingGroup selector, the controller changes the annotation to hpa and emits an AutoscalingClassFallback Warning event before KEDA replaces KPA with HPA. This rewritten HPA choice remains after the object leaves the group; wait for the membership annotation to disappear, then explicitly select kpa again if desired. If KPA came only from the installation default, no class is rewritten: the object uses HPA while it is a group member and follows the installation default again after leaving. Review the ScaledObject events and KEDA operator logs for the exact transition or validation error.

KEDA-generated KPAs support External, Resource, and ContainerResource metrics. The KPA CRD rejects another HPA metric type during API admission. Directly authored KPAs remain unsupported even when their spec passes structural validation.

If KPA exists but cannot fetch an external metric, verify that its paired KEDA operator watches the same namespace and that the KPA-to-KEDA mTLS identity is valid. For CPU or memory, verify that kubectl top pods -n <namespace> works. See Kedify Pod Autoscaler troubleshooting.

Command not found: kubectl

You will need to install kubectl before proceeding. Here are some examples using common package managers, depending on your platform:

Homebrew (macOS and Linux)

brew install kubectl

Apt (Debian/Ubuntu)

sudo apt-get update && sudo apt-get install -y kubectl

Yum (CentOS/RHEL/Fedora)

sudo yum install -y kubectl

Chocolatey (Windows)

choco install kubernetes-cli

Custom DNS Domain

If your Kubernetes cluster uses a custom DNS domain instead of the standard cluster.local suffix, you need to properly configure your setup.

Istio Integration

When setting up Kedify, you might encounter an error like (v1beta1.external.metrics.k8s.io) status FailedDiscoveryCheck if you have Istio installed on the cluster.

To mitigate this problem, please follow this guide.