KEDA: Unlocking Advanced Event-Driven Scaling for Kubernetes - Zbynek Roubalik & Jorge Turrado

KEDA: Unlocking Advanced Event-Driven Scaling for Kubernetes

Speakers: Zbynek Roubalik, CTO Kifi; Jorge Turrado, Principal SRE CRM

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=317rLOIKfDQ

Overview

In this insightful KubeCon EU session, KEDA maintainers Jorge Turrado and Zbynek Roubalik delved into the capabilities and advanced use cases of Kubernetes Event-Driven Autoscaling (KEDA). The talk highlighted KEDA's pivotal role in modernizing application scaling within Kubernetes environments, moving beyond traditional CPU and memory-based metrics to embrace a more dynamic, event-driven paradigm. As organizations increasingly adopt microservices architectures and asynchronous processing, the need for intelligent autoscaling that directly responds to business events has become paramount.

KEDA addresses a critical gap in Kubernetes' native autoscaling mechanisms, primarily the Horizontal Pod Autoscaler (HPA), which, while effective for resource-centric scaling, often falls short for workloads driven by external queues, streams, or custom business logic. By integrating with over 70 different event sources, KEDA empowers developers and operators to precisely match application instances to actual demand, significantly reducing operational costs through efficient resource utilization, including the ability to scale to zero.

The speakers not only introduced KEDA's core functionalities but also explored advanced features like Scaling Modifiers, shared best practices for common scaling challenges, and outlined future developments such as predictive and HTTP-based autoscaling. This talk is essential for anyone looking to optimize their Kubernetes workloads for cost, performance, and resilience, particularly those dealing with event-driven architectures, message queues, or serverless functions.

Background

▶ Watch: Speakers, KEDA roles, and talk agenda (0:00)

The evolution of cloud-native applications has introduced complex scaling challenges that Kubernetes' built-in Horizontal Pod Autoscaler (HPA) struggles to address comprehensively. The HPA primarily monitors metrics like CPU and memory utilization, scaling pods up or down based on predefined thresholds. While effective for compute-bound workloads, this approach often proves inefficient or inadequate for applications whose demand is dictated by external events, such as messages in a queue, entries in a database, or changes in a data stream.

Consider an application consuming messages from a RabbitMQ queue or a Kafka topic. The CPU or memory consumption of this application might not immediately reflect the actual backlog of messages awaiting processing. A sudden surge in messages could lead to significant processing delays if the HPA only scales up after the existing pods become CPU-bound. Conversely, an idle application might continue to consume resources even when there are no messages to process, leading to unnecessary costs. Furthermore, achieving scale-to-zero—the ability to completely shut down an application when idle and restart it on demand—is not natively straightforward with the HPA, often requiring complex custom metric server implementations and feature gates.

This is where KEDA steps in. KEDA was designed to extend the Kubernetes autoscaling capabilities by allowing workloads to scale based on metrics from various external event sources. It acts as a bridge, translating event source metrics into a format the HPA can understand, effectively creating a more intelligent and responsive autoscaling system. This approach not only optimizes resource usage by ensuring that applications only run when needed but also significantly improves application performance by dynamically adjusting capacity to meet real-time demand. KEDA simplifies the previously complex task of integrating custom metrics with HPA, making event-driven autoscaling accessible and manageable for a wide range of cloud-native applications.

Key Findings

▶ Watch: KEDA's solution: scaling based on external metrics (3:15)

The talk highlighted several key findings and contributions that underscore KEDA's power and versatility in Kubernetes autoscaling:

• Extensive Scaler Ecosystem: KEDA boasts support for over 70 different event sources, referred to as "scalers." This vast array includes popular messaging systems like RabbitMQ, Kafka, and Azure Service Bus, cloud services from AWS, Azure, and Google Cloud, as well as monitoring systems like Prometheus. This broad compatibility allows KEDA to integrate seamlessly into diverse cloud-native environments, enabling scaling based on the most relevant business metrics.
• Native Scale-to-Zero Capability: A cornerstone of KEDA's offering is its robust support for scale-to-zero. Unlike traditional HPA, which requires custom metric servers and complex configurations to achieve this, KEDA simplifies the process, allowing applications to consume no resources when idle and instantly scale up when events arrive, leading to significant cost savings.
• ScaleJob for Stateful and Long-Running Workloads: Recognizing that not all workloads are stateless and horizontally scalable, KEDA introduced ScaleJob. This feature addresses scenarios like GitHub Actions runners or other CI/CD jobs, where pods need to complete their tasks before termination. ScaleJob ensures that a job runs to completion, providing a more reliable scaling mechanism for stateful or long-running processes that don't fit the HPA's ephemeral pod model.
• Enhanced Observability with CloudEvents: KEDA now supports CloudEvents specification, allowing it to publish events related to scaling activities. This provides operators with better visibility into the autoscaling process, enabling them to integrate KEDA events into their broader observability platforms via HTTP, Azure Event Grid, and other future targets.
• Improved Metric Alignment and Admission Webhooks: The project has focused on aligning KEDA's exposed metrics with community standards (e.g., using _second suffixes for time-based metrics in Prometheus). Additionally, admission webhooks have been enhanced to provide better validation and early problem detection for KEDA configurations, improving the overall user experience and reducing deployment errors.
• Advanced Authentication Mechanisms: Significant work has gone into improving authentication mechanisms, particularly for AWS services. This ensures secure and robust communication between KEDA and the external services it monitors, which is critical for enterprise deployments.
• HPA Scaling Behavior Best Practice: The speakers emphasized the importance of configuring HPA scaling behavior (native to HPA, used by KEDA) to control how quickly and aggressively HPA responds to load changes. This prevents replica fluctuations and stabilizes the scaling process, allowing for custom policies on how many pods to add/remove per iteration.
• Scaling Modifiers for Complex Logic: A powerful new feature, Scaling Modifiers, allows users to define complex mathematical formulas or nested conditions to combine metrics from multiple triggers. This goes beyond the HPA's default "maximum value" selection, enabling highly customized scaling logic (e.g., averaging metrics, applying specific weights) for intricate business requirements.
• Challenges with Remote Prometheus Scaler: The talk highlighted common challenges when using a remote Prometheus instance for scaling, including scaling delays due to scraping intervals, unnecessary cross-zone traffic, and the potential for overloading the Prometheus instance leading to connection timeouts. Solutions like an OpenTelemetry scaler or metric caching were proposed.
• Roadmap for Predictive and HTTP Scaling: Future developments include predictive scaling, which aims to anticipate load based on historical patterns to scale proactively, and an HTTP scaler to address the unique real-time scaling requirements of synchronous HTTP requests, including scaling from zero.

Technical Deep Dive

▶ Watch: Live demo: KEDA scaling from zero with RabbitMQ (4:00)

KEDA's architecture is built upon the foundational components of Kubernetes, specifically extending, rather than replacing, the Horizontal Pod Autoscaler (HPA). This design choice allows KEDA to leverage Kubernetes' native scaling capabilities while introducing a layer of intelligence for event-driven scenarios.

At its core, KEDA operates through Custom Resource Definitions (CRDs). The primary CRD is the ScaledObject. A ScaledObject acts as a wrapper around a standard Kubernetes Deployment, StatefulSet, or other scalable workload. It defines:

• scaleTargetRef: The target workload (e.g., Deployment, StatefulSet) that KEDA should manage.
• minReplicas and maxReplicas: The desired minimum and maximum number of replicas for the workload. Crucially, minReplicas can be set to 0, enabling KEDA's signature scale-to-zero capability.
• triggers: This is where KEDA's power truly lies. A trigger specifies an external event source (a "scaler") and the associated metrics KEDA should monitor. For example, a RabbitMQ trigger would monitor queue length, while a Prometheus trigger would execute a PromQL query. KEDA supports over 70 different scalers, each tailored to specific event sources. KEDA dynamically creates a custom metric server endpoint that the HPA then queries, effectively tricking the HPA into scaling based on external event metrics.

For workloads that are not suitable for horizontal pod autoscaling, such as CI/CD runners or batch jobs that must complete their execution before termination, KEDA provides the ScaledJob CRD. Instead of scaling a Deployment, a ScaledJob allows KEDA to spawn new Kubernetes Jobs based on event triggers. This ensures that long-running or stateful tasks are given sufficient time to finish, preventing premature termination during scale-down operations. The ScaledJob manifest includes a jobSpec field, mirroring a standard Kubernetes Job definition, which KEDA uses to create instances as needed.

A critical best practice highlighted in the talk is the proper configuration of HPA scaling behavior. This feature, native to HPA (and thus inherited by KEDA), allows users to fine-tune how aggressively the HPA scales up and down. By defining stabilizationWindow and policies (e.g., percent or pods for scaling out/in), operators can prevent "flapping" (rapid scaling up and down) and ensure a smoother, more predictable scaling experience. For example, scaleDown.stabilizationWindowSeconds can prevent immediate scale-down after a brief dip in demand.

One of the most powerful and recently introduced features is Scaling Modifiers. By default, if a ScaledObject has multiple triggers, the HPA will scale based on the trigger that requests the largest number of replicas. Scaling Modifiers allow users to override this default behavior by defining custom mathematical formulas or nested conditions that combine metrics from different triggers. For instance, instead of taking the max(scalerA, scalerB), a user could define a formula like scalerA + scalerB or (scalerA 0.8) + (scalerB 0.2) to create a weighted average. This is defined within an advanced section of the ScaledObject and provides immense flexibility for complex, multi-faceted scaling strategies.

While KEDA's Prometheus scaler is popular due to its flexibility, the speakers detailed several challenges:

• Delay: Metrics are often scraped from workloads by Prometheus, then KEDA scrapes them from Prometheus. This introduces a delay (potentially seconds to a minute) which can be problematic for real-time scaling.
• Traffic Overhead: Sending metrics from the cluster to a remote Prometheus instance and then back to KEDA can generate unnecessary cross-zone network traffic, incurring costs and latency.
• Prometheus Overload: Aggressively configuring scraping intervals to achieve near real-time scaling can overload the Prometheus instance, leading to connection timeouts and unreliable scaling.

To mitigate these, alternative approaches like an OpenTelemetry scaler (which pushes metrics directly to KEDA within the cluster) or using metric caching (to reduce the load on Prometheus) were suggested.

Looking ahead, KEDA is developing an HTTP scaler to address synchronous, real-time HTTP traffic. This involves deploying an interceptor that holds the initial HTTP request when an application is scaled to zero, waits for the application to scale up (from 0 to 1), and then forwards the request. This allows for true scale-from-zero for web applications, though features like WebSocket support are still in development. The concept of predictive scaling is also on the roadmap, aiming to analyze historical metric patterns to anticipate future load and scale applications proactively, before demand actually hits.

Finally, KEDA's extensibility was highlighted, allowing users to develop custom scalers via a gRPC interface if the built-in 70+ scalers and scaling modifiers don't meet their specific business logic requirements. KEDA can also scale any Kubernetes Custom Resource Definition (CRD), provided the CRD implements the /scale subresource, making it highly adaptable to operator-managed workloads.

Demo / Proof of Concept

▶ Watch: KEDA architecture: extending HPA with ScaleObject (7:00)

The session featured three distinct demonstrations that vividly illustrated KEDA's core capabilities and advanced features.

The first demo showcased KEDA's fundamental strength: event-driven autoscaling with scale-to-zero using RabbitMQ. Jorge Turrado initiated the demo by showing a Kubernetes namespace with no active pods for the consumer application. He then published a batch of messages to a RabbitMQ queue. Almost immediately, KEDA detected the pending messages, and the consumer application scaled from zero to one pod. As more messages accumulated, KEDA continued to scale the deployment, progressively increasing the replica count (e.g., from 1 to 2, then 4, then 8) to process the workload efficiently. Once all messages were consumed and the queue was empty, KEDA gracefully scaled the application back down to zero pods, demonstrating significant resource and cost savings. This seamless, demand-driven scaling from complete idleness was a powerful illustration of KEDA in action.

The second demonstration focused on the advanced feature of Scaling Modifiers. Jorge presented a ScaledObject configured with two simple cron triggers, which by default, the HPA would scale based on the maximum value reported by either trigger. He showed the HPA's status reflecting this "max" behavior with two distinct metrics. To demonstrate the power of modifiers, he then applied an update to the ScaledObject by adding an advanced section with scalingModifiers. Within this section, he defined a custom mathematical formula, such as scalerA + scalerB. Upon applying this change, the HPA automatically updated to display a single "composite trigger," whose value was the result of the specified formula (e.g., 1 + 1 = 2 becoming the basis for scaling). This demo, though using a "super stupid example" with cron triggers, effectively conveyed how operators can implement highly customized and complex scaling logic that goes far beyond simple maximum or minimum selections, enabling intricate combinations of metrics from various sources.

The final demo introduced the HTTP Scaling capability, which addresses synchronous request-driven workloads. Similar to the first demo, the HTTP consumer application started with zero pods. Jorge then attempted to access the application via a web browser. KEDA, through its HTTP interceptor, detected the incoming request. It held the request, rapidly scaled the application from zero to one pod, and then routed the request to the newly provisioned instance. After a period of inactivity, KEDA automatically scaled the application back down to zero, ready to repeat the process for the next incoming request. This demonstration highlighted KEDA's ability to efficiently handle bursty, request-based traffic, providing a "serverless-like" experience for HTTP services within Kubernetes, while ensuring optimal resource utilization.

Defensive Implications

▶ Watch: ScaleJob: handling stateful workloads and CI runners (7:45)

KEDA's capabilities offer significant defensive implications for organizations operating Kubernetes environments, primarily revolving around resource optimization, performance, resilience, and operational efficiency.

1. Cost and Resource Optimization: The most immediate benefit is the ability to achieve scale-to-zero and granular, event-driven scaling. By ensuring applications only consume resources when actively processing events, organizations can drastically reduce their cloud infrastructure costs. This is particularly critical for workloads that experience intermittent demand, such as batch jobs, scheduled tasks, or applications processing messages from queues. KEDA acts as a financial defense mechanism against over-provisioning and idle resource waste.
2. Enhanced Application Performance and Responsiveness: KEDA allows applications to scale out precisely when demand increases, directly responding to event backlogs in queues (e.g., RabbitMQ, Kafka) or increased API requests (with HTTP scaling). This dynamic scaling ensures that applications maintain optimal performance and responsiveness, preventing bottlenecks and improving user experience. It's a proactive defense against service degradation under fluctuating loads.
3. Improved Observability and Troubleshooting: With KEDA's support for CloudEvents and its commitment to aligning metrics with community standards, defenders gain enhanced visibility into the autoscaling process. This improved observability facilitates quicker identification of scaling issues, performance bottlenecks, or misconfigurations, strengthening the ability to diagnose and resolve operational problems.
4. Secure Authentication for External Services: The continuous improvements in KEDA's authentication mechanisms (e.g., for AWS services) are crucial for maintaining a strong security posture. Ensuring that KEDA communicates securely with external event sources protects sensitive credentials and prevents unauthorized access to critical data streams, which is a fundamental defensive measure.
5. Mitigating Prometheus Bottlenecks for Real-time Scaling: The discussion around the challenges of using remote Prometheus for scaling highlights a critical defensive consideration. Relying on a monitoring system that introduces delays, generates excessive traffic, or can be overloaded can undermine the effectiveness of autoscaling. Defenders should evaluate alternative scalers like the OpenTelemetry scaler or implement metric caching to ensure real-time, reliable scaling without compromising the monitoring infrastructure. This prevents a single point of failure or performance degradation from impacting autoscaling decisions.
6. Preventing Infrastructure Overload: The warning that autoscaling applications can inadvertently overload shared infrastructure, such as databases or custom services, is a key defensive point. Defenders must consider the downstream impact of rapid application scaling and implement strategies to either scale the underlying infrastructure in conjunction or control the maximum number of connections/replicas to prevent cascading failures.
7. Optimizing GPU Workloads: For AI/ML workloads, where GPUs are expensive, KEDA's ability to scale based on GPU utilization or job queues is a significant defensive strategy against excessive costs. Proper scaling ensures that expensive GPU resources are only utilized when needed, providing cost efficiency and preventing resource contention.
8. Synergy with Cluster Autoscalers: The interplay between KEDA (pod autoscaling) and cluster autoscalers (node autoscaling like Carpenter) is vital for true dynamic infrastructure. Defenders must correctly configure both to ensure that new nodes are provisioned in time to accommodate scaled-out pods. Kifi's Cluster API-based POC for proactive node scaling represents a defensive innovation to bridge the latency gap between pod and node scaling, preventing resource starvation at the cluster level.
9. Adaptability for Custom Workloads: KEDA's support for scaling any CRD that implements the /scale subresource, along with the ability to create custom gRPC scalers, empowers defenders to integrate event-driven autoscaling into highly specialized or proprietary workloads, extending the benefits of efficient scaling across the entire Kubernetes ecosystem.

Key Takeaways

• Event-Driven Autoscaling Beyond HPA: KEDA extends Kubernetes' native HPA, enabling applications to scale based on over 70 diverse external event sources (e.g., RabbitMQ, Kafka, Prometheus) rather than just CPU/memory, crucially supporting scale-to-zero for cost efficiency.
• Specialized Scaling for Stateful Workloads: The ScaledJob CRD provides a robust solution for autoscaling stateful or long-running tasks like CI/CD runners, ensuring that jobs complete their execution before pods are terminated, which is vital for reliability.
• Advanced Customization with Scaling Modifiers: KEDA's Scaling Modifiers empower users to define complex mathematical formulas and nested conditions to combine metrics from multiple triggers, allowing for highly tailored and intelligent autoscaling logic beyond simple maximum value selection.
• Mindful Prometheus Integration: While powerful, using a remote Prometheus scaler can introduce delays, generate unnecessary network traffic, and risk overloading the Prometheus instance; alternatives like an OpenTelemetry scaler or metric caching should be considered for real-time or high-scale scenarios.
• Holistic Autoscaling Requires Synergy: Effective dynamic scaling necessitates proper configuration of HPA's native scaling behaviors and close coordination with cluster autoscalers (e.g., Carpenter) to ensure nodes are available when pods scale out, with proactive node scaling being a key area of innovation.
• Roadmap for Synchronous and Predictive Scaling: KEDA is actively developing an HTTP scaler to address the unique real-time requirements of synchronous web traffic, including scale-from-zero, and is exploring predictive scaling to anticipate future demand based on historical patterns.

About the Speaker(s)

Jorge Turrado is a Principal SRE at CRM, the international division of the SWARS group. He is an active maintainer of KEDA, contributing significantly to the project's development and community engagement. Jorge is also recognized as a CNCF ambassador and a Microsoft MVP, highlighting his expertise and contributions to the cloud-native ecosystem.

Zbynek Roubalik is also a KEDA maintainer, having been involved with the project since its inception, even before its donation to the CNCF. He is the founder and CTO of Kifi, a company dedicated to providing enterprise autoscaling solutions built around KEDA, demonstrating his deep understanding and commercial application of the technology.