Learn KEDA - Pre-Requisites Skill & Setup Environment

#Introduction

Welcome to the Learn KEDA series! Over the next 22 episodes, we will build an understanding of KEDA (Kubernetes-based Event Driven Autoscaling) from scratch: an open-source operator that lets Kubernetes workloads scale themselves based on events — not just CPU or memory.

But there's one non-negotiable requirement: KEDA sits at the intersection of two worlds — Kubernetes and event-driven concepts (queues, streams, message brokers). If one of those foundations isn't solid, the rest of the material will feel like reading a recipe book without ever cooking. That's why episode 0 is dedicated to preparing the entire foundation: the skills you must have, the tools you must install, and the verification steps so everything is ready when the series continues.

#Kubernetes Skills You Must Master

KEDA runs inside the cluster as an operator. All the objects it manages are ordinary Kubernetes objects, so the skills below aren't "nice to have" — they're "must have".

#Deployment, Service, and Pod Scheduling

You need to be comfortable reading and writing Deployment, Service, ConfigMap, and Secret manifests. Most importantly, understand pod scheduling: how Kubernetes chooses a node for a pod, and what nodeSelector, affinity, and tolerations are. This is relevant because in episode 3 we'll talk about placing KEDA pods on specific nodes using tolerations.

#Namespace and RBAC

Understand Namespace as a resource isolation boundary, and RBAC (Role, RoleBinding, ClusterRole, ClusterRoleBinding) as Kubernetes' authorization system. KEDA uses RBAC to manage your HPAs, and episode 6 will cover KEDA authorization in detail.

#Horizontal Pod Autoscaler (HPA)

HPA is the foundation closest to KEDA. KEDA actually doesn't replace HPA — it creates and manages HPAs for you automatically. Make sure you understand how HPA works, resource metrics (requests.cpu, requests.memory), and how to inspect it:

Viewing HPAs in the cluster

kubectl get hpa
kubectl describe hpa my-deployment
kubectl get deploy -n keda

For the second command in particular, HPA reads metrics from metrics-server. Without metrics-server, kubectl top node and CPU-based autoscaling will fail — we'll install it in the setup section.

#Event-Driven Autoscaling Concepts

This is the part that most sets this series apart from typical Kubernetes series. KEDA thrives on the idea that something comes into the system, and its volume isn't always proportional to CPU usage.

#Queue Depth and Consumer Lag

The first term you must memorize is queue depth — the number of messages waiting inside a queue. The higher the queue depth, the more consumers are needed. The second term is consumer lag (specific to streams like Kafka): the difference between the last offset produced and the last offset consumed. A large lag means consumers are overwhelmed.

#Message Brokers: Kafka, RabbitMQ, and SQS

You don't need to be an expert, but you must understand each broker's role because KEDA has a dedicated scaler for each:

#Prometheus Metrics

Prometheus is the de facto standard for observability in the Kubernetes ecosystem. Understand the concepts of metric, label, and simple PromQL queries, because later episodes will write queries like sum(rate(http_requests_total[1m])) inside a Prometheus scaler. If you're already used to kubectl top node, think of this as a far richer version you can build yourself.

#Tools and Software to Prepare

For a local lab, I recommend kind for a quickly created cluster and k3s if you want an experience closer to production. All are valid — choose whichever is most comfortable with your OS.

#Environment Setup

#Creating a Local Cluster

kind create cluster --name keda-lab
kubectl config current-context
kubectl get nodes

#Installing metrics-server

On minikube, run minikube addons enable metrics-server. On other clusters, install via Helm:

helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm upgrade --install metrics-server metrics-server/metrics-server
kubectl get apiservices | grep metrics

Note the pipe to grep metrics — inside a table, a pipe like that must be escaped, for example `kubectl get apiservices \| grep metrics{:bash}`.

#Installing KEDA

KEDA is distributed as an official Helm chart from kedacore. The latest stable version at the time of writing is v2.20.2 (July 2026):

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

#Verifying the Setup

Before moving on to episode 1, make sure everything is running:

helm list -n keda
kubectl get pods -n keda
kubectl get crd | grep keda
kubectl top node

Expected output: three active Deployments in the keda namespace (keda-operator, keda-metrics-server, keda-admission-webhooks), several new CRDs whose names start with keda.sh, and kubectl top node successfully displaying node resource metrics.

#Conclusion

Episode 0 is the gateway to this series. Here's what you must bring along:

• Master Deployment, Service, Namespace, RBAC, and HPA in Kubernetes.
• Understand queue depth, consumer lag, and the role of brokers like Kafka, RabbitMQ, and SQS.
• Prepare a verified cluster, kubectl, Helm, and metrics-server.
• Install KEDA v2.20.2 and make sure the operator, metrics server, and webhooks are running.

In episode 1 we'll step back for a moment to answer the most fundamental question: why CPU-based autoscaling alone isn't enough, how KEDA was born in 2019 from Microsoft and Red Hat, and why it became a graduated CNCF project. All the foundations are ready — let's begin!