KEDA project adds finesse to Kubernetes autoscaling
As enterprise Kubernetes deployments expand in production, an incubating CNCF project injects nuance into the way the container platform responds to applications' resource needs.
A new take on Kubernetes autoscaling gained momentum this week with promotion from sandbox to incubation within the Cloud Native Computing Foundation.
To earn this promotion, Kubernetes Event-Driven Autoscaling (KEDA) passed a Cloud Native Computing Foundation (CNCF) due diligence process within the open source governance body that demonstrated the project has matured and broadened adoption among end users since the initial sandbox stage.
KEDA was created by Microsoft and Red Hat in 2019 and donated to the CNCF in March 2020. It installs as a Kubernetes Operator that adds or removes cluster resources in response to events emitted by various external data sources, such as Apache Kafka data pipelines and monitoring utilities such as AWS CloudWatch. KEDA connects to such external entities through a set of components called Scalers.
More than 30 Scalers currently supported by KEDA allow developers and platform engineers to move beyond the native Kubernetes Horizontal Pod Autoscaler (HPA) and Vertical Pod Autoscaler (VPA) utilities, which scale according to available cluster CPU and memory resources. Users can also autoscale via Cluster Autoscaler, which adjusts the size of a Kubernetes cluster according to the number of pods scheduled to run.
Federico Hernandez
"To scale [based] on CPU and memory is not that easy," said Federico Hernandez, principal software engineer on the platform team for Meltwater, a media intelligence provider based in San Francisco. "You need to have good knowledge of your application demands, and how ... requests propagate to CPU load."
Multidimensional Kubernetes autoscaling
KEDA's development is among many indicators to emerge over the past year that enterprise production Kubernetes deployments are maturing, expanding and encountering new obstacles at scale. KEDA has expanded its user base along with its codebase as a result, with 16 publicly announced users, including cloud provider Alibaba.
Over the last six months, development teams at Meltwater have used KEDA in production to let message volumes from broker applications such as Kafka, RabbitMQ and Redis drive Kubernetes autoscaling. It's possible to manually make such connections, but KEDA Scalers offer a shortcut, Hernandez said.
KEDA provides an easier-to-grasp translation from these direct indicators of load to how many containers and pods you want to have running.
Federico HernandezPrincipal software engineer, Meltwater
"The more messages you have in a queue, like Kafka or other message brokers, the more workers you want to launch to process those messages," Hernandez said. "KEDA provides an easier-to-grasp translation from these direct indicators of load to how many containers and pods you want to have running."
Using KEDA, software developers and platform engineers at Meltwater have come up with Kubernetes autoscaling configurations that dictate that new pods or containers be launched for every 1,000 messages in an application's queue, for example, Hernandez said.
As it matured in the sandbox stage, KEDA also expanded not just the event sources that can trigger Kubernetes autoscaling but what resources it can scale, which include Stateful Sets and Custom Resource Definitions, in addition to pods and containers, as of version 2.0 in November 2020.
"You can scale based on simple Prometheus metrics, based on messages in a queue, Azure Pipeline jobs waiting to be run, practically you name it and we can support it," said Tom Kerkhove, a KEDA maintainer and Azure Architect at Codit, a Microsoft partner and consultancy in Belgium.
KEDA sets Kubernetes autoscaling roadmap
While the CNCF Technical Oversight Committee granted KEDA incubation status, it had a few recommendations for the project before it reaches the final graduation stage. Among them was to recruit more project maintainers. Individuals from 16 companies have made contributions to KEDA, but more than 60% of contributions so far have come from Microsoft and Codit. The project has four maintainers from three companies: Microsoft, Codit and Red Hat.
CNCF due diligence discussions also raised the question of whether KEDA should be merged with the existing HPA project, and whether that integration should occur inside or outside core Kubernetes -- in other words, whether KEDA should become the official native approach to Kubernetes autoscaling.
Codit's Kerkhove acknowledged he's biased on this question, but that he'd like to see things move in that direction. Meltwater's Hernandez agreed.
"Even if KEDA continues to use HPA for CPU and memory scaling under the covers, it would be better to have just one concept rather than two different ones [within Kubernetes]," he said. "It could mean a better user experience for engineers and reduce confusion."
KEDA must also expand its support for Kubernetes autoscaling based on HTTP requests from web applications, which is currently the domain of the Knative event-driven computing project. KEDA maintainers also plan to add this support in future releases, along with support for CloudEvents, the storage of scaling information, predictive analytics and preemptive autoscaling, according to Kerkhove.
Meltwater has already implemented its own integration with open source Prometheus to link Kubernetes autoscaling to HTTP requests, but Hernandez said he likes what he's seen of KEDA's approach to this so far -- a beta project called HTTP Add-on or KEDA-HTTP. This utility uses a separate set of components for HTTP data collection that connect to the Kubernetes cluster via an NGINX Ingress controller.
"There are many ways to build this because each web server exposes this data in a different way," he said. "Rather than building 50 different Scalers, building a proxy [service] is a good decision."
Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.
Federico Hernandez
