Autoscaling Kubernetes pods using KEDA
Introduction:
KEDA is a Kubernetes-based Event Driven Autoscaler. Using KEDA, we can simulate the scaling of containers in Kubernetes based on the events occurring at some external resource. With KEDA, it allows any Kubernetes workloads to benefit from the event-driven based models/architecture.
Also, we will see how we can leverage KEDA and the scaling based on Azure Service Bus queue length.
The Document contains the following sections:
- Working of KEDA
- Brief background for this document.
- Prerequisites.
- Assumptions.
- Working with KEDA
How does KEDA work?
KEDA uses three components to fulfill its tasks:
- Scaler: Connects to an external component (e.g., Azure Service Bus Queue) and fetches metrics (e.g., message count).
- Controller(Agent): Responsible for “activating” a Deployment and creating a Horizontal Pod Autoscaler object.
- Metrics Adapter: Presents metrics from external sources to the Horizontal Pod Autoscaler.
Background:
Autoscaling is one of the important features when we have multiple workloads to process our requests. Horizontal Pod Autoscaler (HPA) is an already existing feature in Kubernetes. Then it is obvious to think what KEDA brings on top of that for us?
So HPA is responsible for scaling of pods based on CPU or RAM usage, whereas KEDA as the name implies can scale the pods on particular events. Earlier, it was not possible to autoscale the pods on a particular event.
For example, if we are using azure service bus queues to push our messages, so once you push your request then only the relative pod will scale and perform the task. This is also a cost-effective feature since we do not have idle pods running all the time. KEDA is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like Horizontal Pod Autoscaler and can extend functionality without overwriting or duplication.
Prerequisites:
Here we will be using Azure for explaining the usage so as a part of prerequisite we need to have:
- An Azure Subscription with access to create and update resources on Azure.
- A K8s cluster on AKS and a namespace with access to create new deployments.
- A Service Bus namespace and access to fetch the connection string for the same.
Assumptions:
Before we get started with the article, we assume that:
- You have good knowledge of Azure and Azure Services.
- You have good knowledge of Kubernetes and its features.
- Furthermore, you have good knowledge of writing YAML and deployment files.
Getting Started:
The Scaler is an important part of KEDA and is responsible for the two aspects:
- Keeping watch on new ScaledObjects.
- To make sure that the deployments, where no events have occurred, are scaled back to 0 replicas. Once the event occurs, it also makes sure that it scales from 0 to n number of replicas.
The controller is responsible for scaling the deployments from 0 to 1 replicas or vice versa, but scaling from 1 to n replicas is done by Kubernetes HPA. This will be automatically created by the controller once it scales it to 1 replica because of the events that are occurring, and the HPA will consume the custom metric server to determine if it should scale out further.
The triggering is done by the scalers which are defined as triggers in every ScaledObject as TriggerAuthentication. They define what external resources should be monitored and what thresholds are to be observed, and will report metrics back to the metric server so that the HPAs can consume them.
Installing KEDA
KEDA can be installed and configured in multiple ways on your cluster. It can be installed using Helm charts and YAML declarations.
Here we have used the YAML approach for installing KEDA. If you would like to follow the same approach, then please execute the below command:
kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.0.0/keda-2.0.0.yaml
Once the above command is executed successfully, you can verify the installation.
kubectl get all -n keda
Now that we have installed KEDA, for the magic to happen we need to create three items:
- Secret: It’s nothing but a connectionString of Azure Service Bus namespace.
- TriggerAuthentication: A trigger to authenticate and connect to Service bus using the Secret and trigger the scaling.
- ScaledObject: A definition for autoscaling the pods and the thresholds to monitor for autoscaling.
Secret:
TriggerAuthentication:
ScaledObject:
Remember, you can create a separate file for all the above code, or the same can reside in your application deployment file, so that when you deploy the application the KEDA configuration goes with it.
Pros:
- KEDA enables you to autoscale your workloads based on the events occurring on external sources, which was not possible before with HPA.
- KEDA saves a lot of cost when there are no idle running pods.
- Works with the already existing feature HPA to scale the pods.
- Increases the replicas based on the number of events.
Conclusion:
This document gives users a taste of what KEDA is and how it works. This is really useful when having solutions that are event-driven, as Kubernetes would not need to always rely on the resource consumption as the indicator of scaling!
References:
