KEDA - Kubernetes Event-driven Autoscaling

Autoscaling is one of my favorite features of Kubernetes. So far we have discussed the Horizontal Pod Autoscaler (HPA) which can scale pods based on CPU or RAM usage. This is a nice start but especially in distributed applications, you often have several components outside of your pods. This can be an Azure Blob Storage, Azure Service Bus, Mongo Db, or Redis Stream. The HPA can not scale your pods based on metrics from these components. That’s where KEDA comes into play.

KEDA, Kubernetes event-driven autoscaling allows you to easily integrate a scaler into your Kubernetes cluster to monitor an external source and scale your pods accordingly.

This post is part of “Microservice Series - From Zero to Hero”.

What is KEDA

KEDA is a Kubernetes event-driven autoscaler that allows you to scale your applications according to events that occur inside or outside of your Kubernetes cluster. It is very easy to install KEDA using a Helm chart and it also runs on any platform no matter what vendor or cloud provider you use. The community and the KEDA maintainers have created more than 30 built-in scalers that allow scaling on events from sources like Azure Service Bus, Azure Storage Account, Redis Streams, Apache Kafka, or PostgreSQL. Additionally, it provides out-of-the-box integration with environment variables, K8s secrets, and pod identity.

Another neat feature is that KEDA can scale deployments or jobs to 0. Scaling to zero allows you to only spin up containers when certain events occur, for example, when messages are placed in a queue. This is the same behavior as serverless solutions like Azure Functions but this feature allows you to run Azure Functions outside of Azure.

KEDA is a CNCF Sandbox project and you can find more information about the project on Github or Keda.sh.

Deploy KEDA to your Kubernetes Cluster

KEDA can be easily installed using Helm charts. If you want to learn more about Helm see Helm - Getting Started and Deploy to Kubernetes using Helm Charts.

First, add the KEDA Helm repo and update it.

Next, create a new namespace called keda and install Keda there. You must install the Helm chart in the keda namespace, otherwise, KEDA will not work.

That’s already it. You have successfully installed KEDA in your Kubernetes cluster.

Configure KEDA to scale base on an Azure Service Bus Queue

You can find the code of the demo on Github.

After KEDA is installed, it is time to create your first scaler. The scaler is a custom resource in Kubernetes and is of the kind ScaledObject. This scaled object references a deployment or job that should be scaled, a trigger, in our example an Azure Service Bus, a reference to a Kubernetes secret that contains the connection string to the queue, and some configuration properties about the scaling itself.

This scaled object defines that it should run a minimum of 0 replicas and a maximum of 10 of the kedademoapi. The cooldown period between scale events is 30 seconds and the queue it monitors has the name KedaDemo. When the queue has 5 messages, the scale-up event is triggered.

The second custom resource you have to define is a TriggerAuthentication. This object contains a reference to a Kubernetes secret that contains the connection string to the Azure Service Bus Queue. The SAS (Shared Access Signature) of the connection string has to be of type Manage. You can learn more about Azure Service Bus and SAS in Replace RabbitMQ with Azure Service Bus Queues.

You can display the secrets of the namespace kedademoapi-test with the following command:

You can also find the secret in the dashboard. See Azure Kubernetes Service - Getting Started for more information about Octant and how to access your Kubernetes cluster.

If you take a look at the screenshot above, you will see that the name and key of the TriggerAuthentication object correspond with the values in the dashboard.

Place the ScaledObject and the TriggerAuthentication in a .yaml file and deploy it to the namespace where the application you want to deploy is running. Deploy it with the following command:

You could also place both objects in separate files and execute the command for each file.

Testing the Keda Service Bus Scaler

If you are using my KedaDemoApi, you can execute the Post method to write random messages into the queue. If you want to learn more about how to deploy applications into Kubernetes and how to set the connection string, see my “Microservice Series - From Zero to Hero”.

Open the Azure Service Bus Queue and you will see the messages there.

This should automatically trigger the scale-out event and start more pods with your application. You can check the running pods with the following command:

As you can see, five pods are now running.

Testing Scale to 0

You can use the Get method of the KedaDemoApi to receive all messages on the queue. The method will return the number of received messages.

When you check the Azure Service Bus Queue, you will see that there are no messages left.

Since there are no messages left in the Queue, the KEDA scaler should scale the application to 0. Execute the get pods command again and you should see that no pods are running anymore.

Conclusion

KEDA is a great tool to scale your workloads in Kubernetes. It allows you to choose from a wide variety of scalers and even lets you connect to external resources like Azure Monitor or a database like PostgreSQL. Especially the scale to 0 feature allows you to remove the allocated resources to a minimum and helps you to save money operating your Kubernetes cluster.

You can find the code of the demo on Github.

This post is part of “Microservice Series - From Zero to Hero”.