The KEDA Blog
Updates, tutorials, and more
Ratnadeep Debnath (Zapier)
March 10, 2022
RabbitMQ is at the heart of Zap processing at Zapier. We enqueue messages to RabbitMQ for each step in a Zap. These messages get consumed by our backend workers, which run on Kubernetes. To keep up with the varying task loads in Zapier we need to scale our workers with our message backlog. For a long time, we scaled with CPU-based autoscaling using Kubernetes native Horizontal Pod Autoscale (HPA), where more tasks led to more processing, increasing CPU usage, and triggering our workers’ autoscaling.
Daniel Yavorovych (Dysnix), Yuriy Khoma (Dysnix), Zbynek Roubalik (KEDA), Tom Kerkhove (KEDA)
February 14, 2022
Introducing PredictKube—an AI-based predictive autoscaler for KEDA made by Dysnix Dysnix has been working with high-traffic backend systems for a long time, and the efficient scaling demand is what their team comes across each day. The engineers have understood that manually dealing with traffic fluctuations and preparations of infrastructure is inefficient because you need to deploy more resources before the traffic increases, not at the moment the event happens. This strategy is problematic for two reasons: first, because it’s often too late to scale when traffic has already arrived and second, resources will be overprovisioned and idle during the times that traffic isn’t present.
Žilvinas Urbonas (CAST AI), Annie Talvasto (CAST AI), and Tom Kerkhove (KEDA)
August 4, 2021
How CAST AI uses KEDA for Kubernetes autoscaling Kubernetes comes with several built-in autoscaling mechanisms - among them the Horizontal Pod Autoscaler (HPA). Scaling is essential for the producer-consumer workflow, a common use case in the IT world today. It’s especially useful for monthly reports and transactions with a huge load where teams need to spin up many workloads to process things faster and cheaper (for example, by using spot instances).
Aaron Schlesinger and Tom Kerkhove
June 24, 2021
Over the past few months, we’ve been adding more and more scalers to KEDA making it easier for users to scale on what they need. Today, we leverage more than 30 scalers out-of-the-box, supporting all major cloud providers & industry-standard tools such as Prometheus that can scale any Kubernetes resource. But, we are missing a major feature that many modern, distributed applications need - the ability to scale based on HTTP traffic.
May 27, 2021
With the addition of Azure Piplines support in KEDA, it is now possible to autoscale your Azure Pipelines agents based on the agent pool queue length. Self-hosted Azure Pipelines agents are the perfect workload for this scaler. By autoscaling the agents you can create a scalable CI/CD environment. 💡 The number of concurrent pipelines you can run is limited by your parallel jobs. KEDA will autoscale to the maximum defined in the ScaledObject and does not limit itself to the parallel jobs count defined for the Azure DevOps organization.
Yan Xun, Andy Shi, and Tom Kerkhove
April 6, 2021
This blog post was initially posted on CNCF blog and is co-authored by Yan Xun, Senior Engineer from Alibaba Cloud EDAS team & Andy Shi, Developer Advocator from Alibaba Cloud. When scaling Kubernetes there are a few areas that come to mind, but if you are new to Kubernetes this can be a bit overwhelming. In this blog post; we will briefly explain the areas that need to be considered, how KEDA aims to make application auto-scaling simple, and why Alibaba Cloud’s Enterprise Distributed Application Service (EDAS) has fully standardized on KEDA.
March 26, 2021
We provide various ways to deploy KEDA in your cluster including by using Helm chart, Operator Hub and raw YAML specifications. These deployment options all rely on the container images that we provide which are available on Docker Hub, the industry standard for public container images. However, we have found that Docker Hub is no longer the best place for our container images and are migrating to GitHub Container Registry (Preview).
November 4, 2020
A year ago, we were excited to announce our 1.0 release with a core set of scalers, allowing the community to start autoscaling Kubernetes deployments. We were thrilled with the response and encouraged to see many users leveraging KEDA for event driven and serverless scale within any Kubernetes cluster. With KEDA, any container can scale to zero and burst scale based directly on event source metrics. While KEDA was initially started by Microsoft & Red Hat we have always strived to be an open & vendor-neutral project in order to support everybody who wants to scale applications.
September 11, 2020
Today, we are happy to share that our first beta version of KEDA 2.0 is available! 🎊 Highlights With this release, we are shipping majority of our planned features. Here are some highlights: Making scaling more powerful Introduction of ScaledJob (docs) Introduction of Azure Log Analytics scaler (docs) Support for scaling Deployments, Stateful Sets and/or any Custom Resources (docs) Support for scaling on standard resource metrics (CPU/Memory) Support for multiple triggers in a single ScaledObject (docs) Support for scaling to original replica count after deleting ScaledObject (docs) Support for controlling scaling behavior of underlying HPA Easier to operate KEDA Introduction of readiness and liveness probes Introduction of Prometheus metrics for Metrics Server (docs) Provide more information when querying KEDA resources with kubectl Extensibility Introduction of External Push scaler (docs) Introduction of Metric API scaler (docs) Provide KEDA client-go library For a full list of changes, we highly recommend going through our changelog!
March 31, 2020
Over the past year, We’ve been contributing to Kubernetes Event-Driven Autoscaling (KEDA), which makes application autoscaling on Kubernetes dead simple. If you have missed it, read about it in our “Exploring Kubernetes-based event-driven autoscaling (KEDA)” blog post. We started the KEDA project to address an essential missing feature in the Kubernetes autoscaling story. Namely, the ability to autoscale on arbitrary metrics. Before KEDA, users were only able to autoscale based on metrics such as memory and CPU usage.