Guide KEDA (Kubernetes Event-Driven Autoscaler) avec exemple

Tutorial: Cron-based Scaling with KEDA Kubernetes

Let’s consider a scenario where you need to scale a job to run only during business hours. This can be achieved using KEDA’s Cron scaler.

Step 1: Install KEDA

You should install KEDA in your cluster using Helm or other methods:

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --namespace keda --create-namespace

Step 2:  Define the Deployment and the Cron Scaler

Define Deployment:

envsubst < keda-deployment.yaml | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-cron-job
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-cron-job
  template:
    metadata:
      labels:
        app: my-cron-job
    spec:
      containers:
        - name: busybox
          image: busybox
          command: [“sleep”, “3600”]

Then, create a `ScaledObject` that defines the scaling behavior based on a cron schedule:

envsubst < scaledobject.yaml | kubectl apply -f -
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaler
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-cron-job
  triggers:
  - type: cron
    metadata:
      timezone: Asia/Kolkata
      start: 0 6 * * * # At 6:00 AM
      end: 0 20 * * * # At 8:00 PM
      desiredReplicas: "10"

With this configuration, the `my-cron-job` deployment will scale to ten replicas from 6 AM to 8 PM in the Asia/Kolkata timezone and scale down to zero outside these hours.

KEDA is an excellent choice for dynamic and event-heavy workloads. Under the hood, KEDA uses the Horizontal Pod Autoscaler (HPA) to implement its scaling decisions. While HPA traditionally depends on metrics like CPU and memory usage, KEDA introduces event-driven triggers, eliminating the need to monitor resource utilization directly.

In PerfectScale, you can easily jump over HPA using the switcher above the table.

From there, you can see the HPA view provides a clear overview of workloads utilizing Horizontal Pod Autoscaler (HPA). This feature enables users to quickly identify the workloads where HPA has been introduced and adjust HPA thresholds with the provided informative tooltips that offer tailored recommendations. These recommendations are particularly helpful in optimizing scaling decisions, minimizing resource waste, and ensuring efficient operation of workloads.

At PerfectScale by DoiT, we discover HPA configurations for workloads in clusters and optimize the pod resource requests and limits while accounting for horizontal scaling behaviors. With KEDA, this process becomes even more seamless, as scaling decisions are decoupled from resource metrics, focusing solely on external events or custom triggers. This enables teams to achieve cost efficiency and performance consistency without over-provisioning or under-utilizing resources.

Best Practices for Running KEDA in Production

Choose Scaling Thresholds Carefully

Scaling thresholds determine when KEDA adds or removes application replicas, making them one of the most important configuration settings. If thresholds are too low, the application may scale up and down too frequently, increasing resource usage and putting unnecessary load on the Kubernetes control plane. If they are too high, workloads may struggle to keep up with incoming events, resulting in higher processing latency and growing backlogs.

Instead of relying on default values, define thresholds based on production traffic patterns and application performance. Load testing is an effective way to identify the point at which additional replicas improve throughput without causing excessive scaling activity. Review and adjust these thresholds regularly as workloads and traffic patterns change.

Configure Polling Intervals and Cooldown Periods

KEDA periodically polls external systems to determine whether scaling is required. Short polling intervals allow workloads to respond quickly to new events but increase the number of requests sent to message queues, databases, or monitoring systems. Longer intervals reduce this overhead but may delay scaling during sudden traffic spikes.

Cooldown periods are equally important because they determine how long KEDA waits before scaling down after activity decreases. Setting an appropriate cooldown period prevents workloads from repeatedly scaling up and down during temporary fluctuations. This results in more stable applications and avoids unnecessary pod creation and termination.

Set Appropriate Minimum and Maximum Replicas

Define minReplicaCount and maxReplicaCount based on the application's availability requirements and the capacity of the Kubernetes cluster. For asynchronous background workers, allowing the workload to scale to zero can significantly reduce infrastructure costs during idle periods. For latency-sensitive services, keeping one or more replicas running can eliminate startup delays.

A reasonable maximum replica count is just as important as the minimum. Without limits, an unexpected surge in events could cause hundreds of pods to be created, consuming cluster resources and potentially affecting other workloads. Capacity planning should include both application performance and the available CPU and memory in the cluster.

Secure Authentication and Secrets

Many KEDA scalers require credentials to connect to external systems such as cloud messaging services, databases, or monitoring platforms. These credentials should never be embedded directly in ScaledObject definitions or stored in plain text within configuration files. Instead, use TriggerAuthentication or ClusterTriggerAuthentication to separate authentication from scaling configuration.

Authentication resources can retrieve credentials from Kubernetes Secrets, cloud-managed identities, or external secret management solutions such as HashiCorp Vault. This approach improves security, simplifies credential rotation, and allows multiple applications to reuse the same authentication configuration without duplicating sensitive information.

Monitor Scaling Behavior and Scaler Health

Production deployments should monitor not only Kubernetes metrics but also the event sources that drive autoscaling. Metrics such as queue length, Kafka consumer lag, processing latency, replica count, and scaler errors provide valuable insight into whether KEDA is scaling applications as expected. Monitoring these metrics helps detect bottlenecks before they affect users.

Integrating KEDA with observability tools such as Prometheus and Grafana makes it easier to visualize scaling activity and identify trends over time. Alerting on failed scaler queries, authentication errors, or unusually large event backlogs enables teams to respond quickly to operational issues and maintain reliable event-driven applications.

Video: KEDA Kubernetes Explained

Ant Weiss, our Chief Cluster Whisperer, recentlyhosted a webinar with Zbynek Roubalik, the CTO of Kedify and maintainer of KEDA. The session was packed with Kubernetes Event-Driven Autoscaling (KEDA) overview, why event-driven autoscaling matters, what benefits it brings to the table, and what challenges the community still needs to solve.

**KEDA Kubernetes FAQ

**

What is KEDA?

Kubernetes Event-Driven Autoscaling (KEDA) scales Kubernetes workloads based on events and external metrics, such as queue length, Kafka lag, or incoming requests. It works with the Kubernetes Horizontal Pod Autoscaler (HPA).

How is KEDA different from HPA?

HPA commonly scales workloads based on CPU and memory usage. KEDA supports these metrics but can also scale workloads based on external events. This allows scaling to begin before resource utilization increases.

Can KEDA replace HPA and VPA?

KEDA can replace a directly configured HPA because it creates and manages an HPA resource under the hood. It does not replace the Vertical Pod Autoscaler (VPA), as KEDA only changes the number of pods.

Using horizontal and vertical autoscaling on the same workload and metric can create conflicting scaling decisions.

How is KEDA different from HPA with Prometheus custom metrics?

KEDA provides simpler per-workload configuration and includes a built-in Prometheus scaler. It also supports many other event sources without requiring separate metrics adapters for each integration.

What workloads can KEDA scale?

KEDA can scale Deployments, StatefulSets, Kubernetes Jobs, and other workloads that expose a scalable target. For example, it can create Jobs dynamically in response to CI/CD pipeline events.

Which event sources does KEDA support?

KEDA supports numerous scalers, including Apache Kafka, Confluent Kafka, AWS SQS, Prometheus, databases, message queues, and cloud services. Organizations can also build custom scalers for unsupported systems.

How is KEDA different from Karpenter?

KEDA scales pods, while Karpenter scales cluster nodes. When used together, KEDA adjusts the number of pods and Karpenter provisions or removes nodes based on the resulting scheduling demand.

Can KEDA support time-based autoscaling?

Yes. The KEDA Cron scaler can maintain a specified replica range during scheduled periods. This can prevent workloads from scaling below a required capacity during seasonal peaks or business-critical processing windows.

Does KEDA work on Oracle Cloud Kubernetes clusters?

KEDA can run on Kubernetes clusters hosted on Oracle Cloud Infrastructure. However, community-provided scalers for OCI-specific services may be more limited than those available for other major cloud platforms.

Is KEDA free?

Yes. KEDA is an open-source project and is free to use. Kedify provides a commercial platform built on KEDA with additional capabilities such as support, dashboards, security fixes, and features for larger deployments.

Is the KEDA HTTP add-on production-ready?

The open-source HTTP add-on remains in beta and is not generally recommended for production use. It routes traffic through an interceptor that collects metrics and supports scaling to zero, but this component can introduce performance and reliability limitations.

When should organizations consider KEDA?

KEDA is appropriate when CPU- and memory-based autoscaling cannot meet latency, throughput, reliability, or cost requirements. It is particularly relevant when workload demand can be measured through events such as queue depth, request volume, or message lag.

Can KEDA determine the CPU and memory required by each pod?

No. KEDA only performs horizontal scaling by changing the number of workload replicas. Pod resource requests and vertical scaling must be handled separately.

Final Thoughts

KEDA makes event-driven autoscaling in Kubernetes easier, more flexible, and more efficient, especially when resource-based scaling falls short. Whether you’re dealing with unpredictable workloads, integrating external services, or optimizing your infrastructure costs, KEDA provides a powerful solution to scale your applications dynamically.

If you’re new to KEDA, start by exploring the KEDA docs to understand how it can fit into your Kubernetes environment. And if you're looking for a way to optimize both horizontal and vertical scaling, give PerfectScale a try. Start your free trial today and see how it can fine-tune your autoscaling strategy!