How to Scale Kubernetes Apps with KEDA: Architecture, Step-by-Step Demo, and Real Examples

In a Kubernetes environment, autoscaling typically depends on CPU or memory usage. But what if your application needs to scale based on external events, like the length of a message queue? This is where KEDA (Kubernetes Event-Driven Autoscaling) comes in handy. KEDA allows Kubernetes to automatically scale your applications when specific events occur, like messages piling up in a queue or external metrics being triggered.

In this blog, we will cover:

• What KEDA is and how its architecture works.
• The benefits and use cases of KEDA.
• How to deploy KEDA on your Kubernetes cluster.
• A hands-on demo of scaling an app using RabbitMQ queue length.
• Key points, real-life examples, and a call to action.

Understanding KEDA’s Architecture

KEDA extends the standard autoscaling functionality of Kubernetes by allowing event-driven triggers from outside the cluster. Here’s how its components work together:

1. KEDA Operator

The KEDA Operator is like the brain of KEDA. It listens for events from external sources and triggers scaling when needed. It works with Kubernetes to scale your applications based on these events.

2. External Scalers

Scalers are plugins that connect KEDA to different event sources. These scalers can listen for triggers from systems like:

• RabbitMQ for message queue lengths.
• Prometheus for custom metrics.
• Kafka, AWS SQS, or Azure Monitor for other external systems.

These scalers keep track of the event data and pass it to KEDA.

3. ScaledObject

A ScaledObject is a configuration file in Kubernetes that defines how an application should scale. It tells Kubernetes what event source to listen to, the number of pods to scale up or down, and the conditions under which scaling should happen.

4. Metrics Adapter

The Metrics Adapter collects data from the external sources and injects it into Kubernetes so that the system knows when to scale based on the event data. This ensures that scaling decisions are made based on the right information.

Benefits of Using KEDA

KEDA adds a lot of value to Kubernetes environments:

• Event-Based Scaling: KEDA scales applications based on external events, not just CPU or memory usage.
• Cost Efficiency: Applications only scale when needed, reducing unnecessary cloud costs.
• Multiple Event Sources: KEDA supports many different event sources, including message queues, custom metrics, and APIs.
• Seamless Kubernetes Integration: KEDA works natively with Kubernetes and doesn't require additional overhead.
• Zero-Pod Scaling: KEDA can scale workloads down to zero, which is useful for event-driven applications like batch jobs or background processors.

How to Deploy KEDA on an Existing Kubernetes Cluster

Let's go step by step on how to install and set up KEDA in your existing Kubernetes cluster.

Step 1: Install KEDA

You can install KEDA using Helm. Here’s the command:

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

This installs the KEDA operator in the keda namespace.

Step 2: Verify Installation

Make sure KEDA is running by checking the pods in the keda namespace:

If everything is working, you should see the pod status is running (1/1).

Demo: Scaling an Application with RabbitMQ and KEDA

In this demo, we’ll deploy a sample application that processes messages from a RabbitMQ queue. Then, we'll use KEDA to scale the application based on how many messages are in the queue.

Note: In this Demo we are deploying RabbitMQ in our same Kubernetes. If your RabbitMQ server is running on different Kubernetes cluster or on baremetal instance then also you can implement autoscaling. In this demo i'll attaching configuration file for both scenarios.

In Upcoming blogs we'll implement demo based on other popular scalers such as Apache Kafka topic, Amazon Web Services (AWS) CloudWatch, Cron Schedule, Elastic search template query, MongoDB queries, Splunk saved search results and a lot more.

Step 1: Deploy RabbitMQ

First, we’ll deploy RabbitMQ, which will act as our event source. Run the following command:

kubectl create namespace demo
helm install rabbitmq bitnami/rabbitmq --namespace demo        

This will deploy RabbitMQ in the demo namespace.

Step 2: Deploy the Sample Application

Now, let’s deploy a simple application that processes messages from RabbitMQ. Here’s a sample deployment file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: message-processor
  namespace: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: processor
  template:
    metadata:
      labels:
        app: processor
    spec:
      containers:
      - name: processor
        image: myrepo/message-processor:latest
        env:
            - name: RABBITMQ_DEFAULT_USER
               valueFrom:
                  secretKeyRef:
                    name: rabbitmq-secret
                    key: RABBITMQ_DEFAULT_USER
            - name: RABBITMQ_DEFAULT_PASS
               valueFrom:
                  secretKeyRef:
                    name: rabbitmq-secret
                    key: RABBITMQ_DEFAULT_PASS        

Apply the deployment with:

kubectl apply -f message-processor.yaml        

This application will start processing messages from the RabbitMQ queue. Please do not forget to replace your actual image name. In our case we used an internal image. you can try with public sample image from DockerHub for this demo.

Step 3: Create a KEDA ScaledObject

Next, we’ll define a ScaledObject to tell KEDA how to scale the application based on the queue length. Here’s the configuration:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: rabbitmq-scaledobject
  namespace: demo  
spec:
  scaleTargetRef:
    name: message-processor
    kind: Deployment  
  pollingInterval: 15  # How often KEDA checks the metrics (in seconds)
  cooldownPeriod:  75 # The period to wait after the last trigger to scale back to 0
  minReplicaCount: 0   # Minimum number of replicas for the Deployment
  maxReplicaCount: 5   # Maximum number of replicas
  triggers:
  - type: rabbitmq
    metadata:
      protocol: amqp
      queueName: test-queue # Replace with your actual queue name
      host: rabbitmq.demo.svc.cluster.local # RabbitMQ service name
      queueLength: "3"  # Target queue length per consumer
    authenticationRef:
      name: rabbitmq-trigger-auth
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: rabbitmq-trigger-auth
  namespace: demo
spec:
  secretTargetRef:
  - parameter: host
    name: rabbitmq-secret
    key: host
  - parameter: username
    name: rabbitmq-secret
    key: RABBITMQ_DEFAULT_USER
  - parameter: password
    name: rabbitmq-secret
    key: RABBITMQ_DEFAULT_PASS        

This file tells KEDA to scale the message-processor based on the number of messages in the RabbitMQ queue.

Note: If your RabbitMQ server is out of Kubernetes cluster then update trigger section of your configuration file as mentioned below and apply the yaml file. - type: rabbitmq

    metadata:
      protocol: amqp
      queueName: test-queue # Replace with your actual queue name
      host: "<>" # Replace with your external RabbitMQ IP or hostname
      port: "5672" # Default RabbitMQ port, change if you're using a different port
      vhost: "/" # Replace with your vhost if different
      queueLength: "3"
    authenticationRef:
      name: rabbitmq-trigger-auth        

Create a Kubernetes secret to host your RabbitMQ server credentials:

apiVersion: v1
kind: Secret
metadata:
  name: rabbitmq-secret
  namespace: demo
type: Opaque
stringData:
  host: amqp://<username><password>@<host-ip or k8s service>:5672
  RABBITMQ_DEFAULT_USER: <username> 
  RABBITMQ_DEFAULT_PASS: <password>        

Deploy this ScaledObject and apply Kubernetes secret:

kubectl apply -f rabbitmq-scaledobject.yaml
kubectl apply -f rabbitmq-secret.yaml        

Step 4: Test Auto-Scaling

Now, let’s see KEDA in action. Add some messages to the RabbitMQ queue, and as the queue grows, KEDA will automatically scale up the number of pods running the message-processor.

To watch the scaling in real time, use this command:

kubectl get pods -n demo -w        

As more messages get added, you'll see more pods being created to handle the workload. Later you can optimise your application and these manifest files based on your requirement.

Key Points and Real Use Cases of KEDA

Key Points:

• KEDA allows event-driven scaling, letting your applications scale based on real-world events like queue length or custom metrics.
• It helps you save costs by scaling workloads only when necessary.
• KEDA integrates smoothly with multiple external systems like RabbitMQ, Kafka, Prometheus, and more.
• It’s lightweight, easy to deploy, and can scale your applications down to zero when not in use.

Real Use Cases:

1. Message Queue Processing: Scale your message consumers based on the number of messages waiting in a queue, ensuring you always have the right number of pods to process them.
2. Batch Jobs: Scale your applications up or down automatically based on batch workloads or data processing tasks.
3. API Scaling: Automatically scale based on custom Prometheus metrics, such as the number of API requests, ensuring you can handle traffic spikes.
4. Event-Driven Serverless: Handle serverless workloads like video processing or report generation by scaling in response to events.

Conclusion: Start Using KEDA for Smarter Scaling

KEDA is a powerful tool that extends Kubernetes autoscaling beyond CPU and memory usage, enabling your applications to scale dynamically based on real-world events. It’s easy to set up and integrates with a wide range of event sources.

If you're interested in learning more about Kubernetes, scaling techniques, and other DevOps tools, be sure to follow me so you don’t miss out on future blog posts!

By the way, I recently started a YouTube channel, and a lot of interesting content is coming soon! You can subscribe now from here so you don’t miss anything.