How KEDA Fits Into Kubernetes Autoscaling

▶ Watch (3:17)

KEDA sits on top of Kubernetes and reuses as much of the platform as possible. The operator manages ScaledObject and ScaledJob resources. A separate metrics adapter exposes queue-depth and other external values to the Kubernetes API server. A validation webhook checks every resource at apply time. Scaling from zero to one replica is handled by the KEDA operator directly. Scaling from one to N replicas is delegated to HPA, which receives custom metrics from KEDA’s adapter. This split keeps KEDA’s scope small and Kubernetes-native.

ScaledObject vs ScaledJob: Picking the Right Resource

▶ Watch (4:48)

ScaledObject adds or removes replicas of a running deployment. It takes three sections: the target workload, min and max replica counts, and one or more trigger definitions. HPA handles the 1-to-N range using custom metrics KEDA supplies. ScaledJob schedules discrete Kubernetes Jobs instead of adjusting replicas. It fits long-running computation where HPA would scale down mid-job after an hour. Think of ScaledJob as a cron job that fires only when a queue depth or other metric crosses a threshold, not on a fixed schedule.

Scaling Modifiers: Custom Formulas Without Code

▶ Watch (16:40)

When multiple triggers target the same workload, HPA picks the largest value by default. Scaling modifiers intercept the metrics before they reach HPA and apply a user-defined formula. The demo combined two named triggers, “chrome” and “reference”, and drove a second workload to exactly twice the replica count of the first. One documented use case: if a database is overloaded and the queue is growing, an inverted-proportional formula can reduce the worker replica count instead of increasing it, preventing the database from collapsing further. No application code changes required.

Polling Intervals, Metric Caching, and Prometheus at Scale

▶ Watch (21:18)

Using Prometheus as a KEDA metric source works until scale pressure exposes two problems. First, scrape delay plus HPA’s 15-second poll cycle can push scaling latency past one minute. Second, large deployments with thousands of ScaledObjects can hammer a Prometheus instance or hit rate limits on hosted providers. Metric caching on the trigger level lets KEDA serve HPA’s 15-second requests from a local cache, so Prometheus sees only one request per polling interval. For external services with rate limiters, setting the polling interval to 60 seconds and enabling caching drops requests from four or more per minute to one.

HTTP Add-On: Scale to Zero for HTTP Traffic

▶ Watch (27:53)

The KEDA HTTP add-on intercepts incoming requests and holds them until the target deployment starts. The demo showed a workload at zero replicas receiving a request and becoming available within seconds. Without the interceptor, a cold-start returns a 502. The add-on removes that failure. It works with standard Kubernetes Deployments and can be combined with other KEDA scalers. Red Hat has committed engineering capacity to the project. Turrado described this as the year HTTP scale-to-zero in KEDA ships properly.

Q&A

How does KEDA HTTP scaling differ from Knative? KEDA’s HTTP add-on works with standard Deployments and any existing KEDA scaler, while Knative requires Knative Services; both solve cold-start problems but were built for different primary use cases. ▶ 29:34

Can scaling modifiers handle an overloaded API service the same way they handle an overloaded database? Yes. Any metric that can be exposed, whether CPU, queue depth, or a custom application metric pushed to Prometheus, can feed a scaling modifier formula. ▶ 31:04

Notable Quotes

the portfolio of scalers is more than 70 70 different sources just one click away Jorge Turrado · ▶ 08:40

you can use all the trigger portfolio that KDA supports as a metric source to build your own autoscaling solution without having to code any single line of code Jorge Turrado · ▶ 20:15

the magic is that HTTP addon of keta is hold is intercepting the request is holding the request till the target back end is up and running and then the request is passed to the target back end Jorge Turrado · ▶ 28:29

if you can expose the metric about the problem we can target it and use it for the scanning Zbynek Roubalik · ▶ 31:06

Key Takeaways

  • KEDA delegates 1-to-N scaling to HPA and handles zero-to-one itself, keeping architecture Kubernetes-native.
  • Scaling modifiers let teams write custom multi-source formulas to control replica counts without application changes.
  • Metric caching reduces external scrape requests from four or more per minute to one, preventing rate-limit failures at scale.
  • The HTTP add-on holds cold-start requests rather than returning 502s, enabling true scale-to-zero for HTTP workloads.
  • At 10,000 ScaledObjects, Prometheus polling intervals must be planned carefully or the Prometheus instance will be overloaded.

About the Speaker(s)

Jorge Turrado is a Principal SRE at SCRM Lidl International Hub with over 10 years in software development, infrastructure architecture, and monitoring. He holds the Microsoft MVP award for 7 consecutive years and serves as a CNCF Ambassador. He contributes extensively to the KEDA project in his spare time.

Zbynek Roubalik is founder and CTO of Kedify, which builds an enterprise-grade autoscaling platform on top of KEDA. He has maintained the KEDA project since its early days and works within the CNCF community to grow adoption of event-driven autoscaling on Kubernetes.