For the complete documentation index and AI-optimized content, see /llms.txt. All pages support markdown format via .md extension or Accept: text/markdown header.

KEDA Best Practices

For the complete documentation index and AI-optimized content, see /llms.txt. All pages support markdown format via .md extension or Accept: text/markdown header.

These recommendations focus on safe, production-oriented autoscaling behavior for Kedify and KEDA. They are most useful when you already know which scaler to use and want more predictable outcomes from HPA behavior, fallback handling, and scaling logic.

For workload-level Kubernetes behavior such as pod startup, resource requests, probes, disruption handling, and graceful shutdown, see Kubernetes & Autoscaling Best Practices.

Specify ScaledObject Fallback

In KEDA, a ScaledObject can be configured to use a fallback mechanism to ensure reliability in scaling operations. The fallback configuration defines default scaling behavior in case the primary metrics are unavailable or misconfigured. This is crucial for maintaining a baseline level of service during failures.

Example Configuration:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: example-scaledobject
spec:
  scaleTargetRef:
    name: my-deployment
  fallback:
    failureThreshold: 3 # Number of consecutive failures to trigger fallback
    replicas: 6 # Number of replicas to scale to during fallback

In this example:

failureThreshold is set to 3, meaning the fallback mechanism will activate after three consecutive failures to retrieve metrics.
replicas is set to 6, ensuring that at least six replicas are maintained during fallback.

This configuration ensures that even if the primary scaling metrics fail, the application will maintain availability and performance by having a specified number of replicas running.

Specify Horizontal Autoscaler Behavior

The Horizontal Pod Autoscaler (HPA) behavior can be finely tuned to better manage scaling operations. Key configurations include stabilization windows, scale-up policies, and scale-down policies. These settings help control how quickly the HPA responds to changes in load, preventing rapid fluctuations and ensuring smoother scaling transitions.

Configure horizontal autoscaler behavior directly in the ScaledObject. Kedify KEDA applies advanced.horizontalPodAutoscalerConfig to the generated HPA or KPA. See the KEDA behavior documentation and KPA overview.

Example Configuration:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: my-scaledobject
spec:
  scaleTargetRef:
    name: my-deployment
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleUp:
          stabilizationWindowSeconds: 300 # Stabilization window to prevent flapping
          policies:
            - type: Percent
              value: 100
              periodSeconds: 60
        scaleDown:
          stabilizationWindowSeconds: 300 # Stabilization window to prevent flapping
          policies:
            - type: Percent
              value: 50
              periodSeconds: 60
  triggers:
    - type: rabbitmq
      metadata:
        queueName: my-queue
        host: rabbitmq.my-cluster.com
        queueLength: "5"

In this example:

scaleUp and scaleDown behaviors include a stabilizationWindowSeconds of 300 seconds to prevent rapid fluctuations (flapping) in the number of replicas.
Policies are set to scale by a percentage (Percent) of the current number of pods. For scaling up, it can increase by up to 100% of the current pods every 60 seconds. For scaling down, it can decrease by up to 50% every 60 seconds.

Understand Polling and Autoscaler Evaluation Intervals

KEDA and the horizontal autoscaler control different parts of the scaling loop. KEDA handles activation from zero and the return to zero, while HPA—or KPA when selected—handles scaling between one and N replicas.

Configure pollingInterval, cooldownPeriod, and activation thresholds for the KEDA-controlled path. Configure advanced.horizontalPodAutoscalerConfig.behavior for stabilization windows and scale-up or scale-down policies applied by the horizontal autoscaler.

Lowering ScaledObject.spec.pollingInterval does not make HPA evaluate an active workload more frequently. Native HPA uses the kube-controller-manager’s cluster-wide --horizontal-pod-autoscaler-sync-period, which is commonly 15 seconds.

If useCachedMetrics: true is enabled for a trigger, pollingInterval also controls how often KEDA refreshes the cached metric. The autoscaler may evaluate more frequently but receive the same value until the next cache refresh.

For a KPA-selected ScaledObject, use autoscaling.kedify.io/sync-period-seconds to configure the one-to-N evaluation cadence for that workload. This setting is separate from pollingInterval.

Scaling Modifiers

Scaling modifiers in KEDA create a composite metric for the horizontal autoscaler. This supports scaling logic based on several metrics and conditions. The same ScaledObject configuration is used when KPA is selected.

Example Configuration with Scaling Modifiers:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: rabbitmq-composite-scaledobject
spec:
  scaleTargetRef:
    name: my-rabbitmq-consumer
  advanced:
    scalingModifiers:
      formula: "(metric1 + metric2) / 2"
      target: 5
      activationTarget: 3
      metricType: AverageValue
  triggers:
    - type: rabbitmq
      name: metric1
      metadata:
        queueName: queue1
        host: rabbitmq-host1
        queueLength: "20"
    - type: rabbitmq
      name: metric2
      metadata:
        queueName: queue2
        host: rabbitmq-host2
        queueLength: "25"

In this example:

Two RabbitMQ triggers (metric1 and metric2) are defined, each monitoring different queues.
The formula calculates the average queue length by combining metric1 and metric2 and dividing by 2.
target is set to 5, meaning the desired average queue length is 5.
activationTarget is set to 3, which is the threshold for activating the ScaledObject.
metricType is AverageValue, indicating the use of the average value of the metrics.

By using scaling modifiers, you can create more nuanced and responsive scaling strategies, ensuring your applications scale intelligently based on a composite of multiple metrics.

Alert on Autoscaling Check Latency

Use autoscaling checks to validate that KEDA, the selected pod autoscaler, metrics sources, and the Kedify control plane still work together in the cluster. The check runners expose kedify_autoscaling_check_duration_seconds, a gauge containing the duration of the latest complete check iteration.

Use this metric for production alerts, for example:

kedify_autoscaling_check_duration_seconds > 300

The metric includes labels for the overall result and each step, so alerts and dashboards can show whether the slow iteration was waiting on the source metric, KEDA metric, pod-autoscaler metric or activity, scale-up, or scale-down. The hpa_metric and hpa_active label values apply to both HPA and KPA.