I was just exploring some CNCF projects and then I got to know about Keda. So, in this article, we will be talking about Kubernetes Event-driven Autoscaling (KEDA).
Scaling applications in Kubernetes is pretty cool, right? But what if I told you there’s a smarter way to scale — not just based on CPU or memory, but based on real-world events like incoming messages, pending jobs, or HTTP requests?
Let me introduce you to KEDA — Kubernetes Event-Driven Autoscaler.
Whether you’re new to Kubernetes or someone who's been running clusters for a while, you’ll love how KEDA changes the way we think about autoscaling.
KEDA was accepted to CNCF on March 12, 2020, moved to the Incubating maturity level on August 18, 2021, and then moved to the Graduated maturity level on August 22, 2023.
The Challenge with Traditional Autoscaling
So, imagine this: you’ve set up your application to scale with HPA, which primarily focuses on CPU and memory usage. That’s great for CPU-heavy apps, but what about those applications that don’t rely solely on these metrics for performance?
Think of apps that process message queues, listen to streaming events (like Kafka), or handle background jobs based on database records. Often, these apps can have a large backlog of tasks while their CPU is barely hitting 10%. Frustrating, right?
In Kubernetes, we usually scale our apps with the Horizontal Pod Autoscaler (HPA).
But here’s the thing:
- HPA mostly cares about CPU and memory usage.
That’s fine if your app is CPU-heavy. But what if your app:
- Processes a message queue?
- Listens for events from a streaming platform like Kafka?
- Runs background jobs based on database records?
In these cases, CPU and memory aren’t always the right signals to decide whether to scale up or down.
You could have a huge backlog of work, but the CPU is chilling at 10%.
This is where KEDA comes in.
Enter KEDA
This is where KEDA comes to the rescue. It’s an open-source project that allows you to scale your Kubernetes applications based on the number of messages in a queue, the rate of events, or other custom metrics. It empowers us to scale our workloads dynamically and efficiently, depending on specific triggers and workloads rather than just CPU or memory.
How Does KEDA Work?
KEDA works by using a set of scalers—these are components that listen to various events and determine when and how much to scale your applications. It integrates seamlessly with existing tools like HPA, allowing it to use the scaling logic of Kubernetes, but with the added finesse of reacting to specific event-driven conditions.
Here’s how it typically functions:
Scaler Configuration: You define which event source (like a Kafka queue or Azure Queue Storage) KEDA should monitor and specify the scaling logic within a Custom Resource Definition (CRD).
Event Monitoring: KEDA continuously watches the specified external event sources. For instance, if you set it to monitor a message queue, it will check how many messages are in the queue.
Autoscaling: When the defined threshold is reached—say, the number of messages exceeds a certain value—KEDA triggers the HPA to scale up the pods. If the backlog decreases (or if the queue is empty), it will scale down accordingly.
Why KEDA is Worth Using
Flexibility: KEDA supports a wide range of event sources, from message queues to databases and custom metrics, making it adaptable for various use cases.
Cost-Efficiency: By scaling your application based on actual demand (number of events, messages, etc.), you’re only using the resources you need, potentially reducing costs.
Simplicity: The setup is relatively straightforward, especially if you're already familiar with Kubernetes. With KEDA's CRDs, you can quickly get started integrating advanced autoscaling capabilities.
Real-World Use Cases
Let’s take a look at how KEDA can shine in real-life situations:
Background Jobs: If you have a system that processes data in batches (think image processing), KEDA can scale your worker pods based on the number of images waiting to be processed in a queue.
Event Stream Processing: If you're capturing events from a data streaming platform like Kafka, KEDA can monitor the number of unprocessed events and scale your consumers up or down accordingly, ensuring that no event is left hanging.
Microservice Communication: In a microservices architecture, certain services may only need to scale based on specific triggers, such as the number of requests or messages from another service. KEDA can handle this beautifully.
Refer this for more
Conclusion
If you’re looking to optimize your Kubernetes applications and enhance their autoscaling capabilities, KEDA is definitely worth giving a try. It helps bridge the gap between traditional scaling methods and the dynamic workloads that today’s applications often require.
Let me know if you end up experimenting with KEDA. I’d love to hear about your experiences or any challenges you encounter along the way! If you have any suggestion, you can connect me on x!
Happy scaling! 🍻
Top comments (2)
Is this use case suitable for an e-commerce application where scaling is required based on HTTPS request traffic received via an AWS ALB (Application Load Balancer)?
absolutely