Learn KEDA - Setup & Installation

#Introduction

In episode 2 we mapped out KEDA's architecture: operator, metrics server, and admission webhooks. Now it's time to actually deploy it to your cluster. In episode 0 we ran a short install command; episode 3 completes it: what's actually installed, how to verify it, how to customize the installation for production needs, and alternatives if you don't want to use Helm.

#Installing with Helm

Helm is the official and most common way to install KEDA. The official chart lives in the kedacore repository:

Adding the repository and installing KEDA

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

Tip

Although the default install works out of the box, always specify an explicit namespace like above. Installing into the keda namespace keeps KEDA objects easy to find and isolated when you need to clean them up later.

#Verifying the Installation

After a moment, make sure all three Deployments are active and ready:

From the second command, you'll see three deployments: keda-operator, keda-metrics-server, and keda-admission-webhooks. If all three show Ready 1/1, the installation succeeded and you can move on. Check again with kubectl get deploy -n keda whenever something feels off. For a specific version install, use the --version flag:

Installing a specific version and checking release status

helm upgrade keda kedacore/keda --namespace keda --version 2.20.2
helm list -n keda

#Configuration Options via `--set`

The KEDA chart is very flexible through --set. Some of the most commonly used options:

Example installation customization

helm upgrade keda kedacore/keda --namespace keda \
  --set image.pullPolicy=IfNotPresent \
  --set podIdentity.activeDirectory.operator.identity=keda-operator-id \
  --set operator.replicas=2

Common options you should know: operator.replicas for HA, metricsServer.replicas for always-available metrics, and podDisruptionBudget to maintain availability during maintenance. The kedacore/keda chart documentation on GitHub lists every value that can be set.

#Tolerations and Resources

For clusters with node taints (for example, nodes dedicated to platform tooling), KEDA can be forced onto specific nodes:

Setting tolerations and resource limits

helm upgrade keda kedacore/keda --namespace keda \
  --set tolerations[0].key=platform \
  --set tolerations[0].operator=Exists \
  --set operator.resources.requests.cpu=100m \
  --set operator.resources.limits.memory=512Mi

Note that tolerations values are written as an array within a single command; for complex configuration, it's better to save it as a separate values.yaml so it's easy to review and makes sense for version control.

#Alternative: YAML Manifest for GitOps

Not everyone likes Helm inside a GitOps pipeline. KEDA also publishes custom YAML manifests that can be applied directly — suitable for ArgoCD or Flux flows where all deployment sources are plain YAML files.

Installing KEDA from a custom manifest

kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.20.2/keda-2.20.2.yaml
kubectl get pods -n keda

The manifest version always follows the release tag on the kedacore/keda GitHub. With this pattern, you can put the manifest file in your repository and let ArgoCD sync it — no Helm state to maintain.

Warning

If you switch from Helm to manifests (or vice versa), don't let both manage the same objects. Objects created by Helm have the app.kubernetes.io/managed-by=Helm label; deleting the Helm release deletes all its objects, including ones you may have modified manually.

#Cloud Add-ons: AKS and EKS

For managed cluster users, KEDA is also available as a native add-on:

AKS: enable the keda add-on via Azure CLI or the portal. KEDA runs as a managed extension — version upgrades are handled by Azure.
EKS: there's no built-in KEDA add-on, but the Helm installation above runs smoothly on EKS. Many teams combine eksctl for cluster provisioning with Helm for installing KEDA.

Enabling the KEDA add-on on AKS

az aks update --resource-group my-rg --name my-cluster \
  --enable-keda

Managed add-ons reduce operational overhead, but give you less control over --set options. Choose based on how much customization you need.

#Upgrade, Rollback, and Uninstall

Maintaining KEDA is as important as installing it. There are three operations you'll definitely need someday.

#Upgrading to the Latest Version

Always start with helm repo update so the chart metadata is fresh, then upgrade:

Upgrading KEDA to the latest version

helm repo update
helm upgrade keda kedacore/keda --namespace keda --version 2.20.2
kubectl get pods -n keda -w

#Rollback

If an upgrade causes problems, Helm keeps a release history. Check the history with helm history keda -n keda, then return to a previous release:

Rolling back to a previous release

helm history keda -n keda
helm rollback keda 1 --namespace keda

#Uninstall

Removing KEDA from the cluster

helm uninstall keda --namespace keda

Warning

Before uninstalling, make sure no ScaledObjects or ScaledJobs are still in use — the HPAs created by KEDA will be removed too and workloads will stop scaling. Also note: Helm 3 does not delete CRDs on uninstall, so the keda.sh CRDs will remain in the cluster and can be deleted manually if you truly want to clean everything up.

#Conclusion

Episode 3 gets KEDA truly running on your cluster. Here's what you must bring along:

Install via helm install keda kedacore/keda --namespace keda --create-namespace.
Verify the three deployments: operator, metrics server, and admission webhooks.
Customize via --set for tolerations, resources, and HA.
YAML manifest alternative for GitOps flows, plus managed add-ons on AKS/EKS.

In episode 4 we'll get into the objects you'll write most often: ScaledObject for continuous workloads and ScaledJob for batch — including all their key fields and how their behavior differs.