Использован автоперевод
Kubernetes Event-driven Autoscaling
What is a good software?
One of answers is doing the right things, with as little cost in operations as possible.
How can we reduce operations costs?
We can use autoscaling
Autoscaling, also known as automatic scaling, is a cloud computing feature that allows you to automatically adjust the capacity of your resources based on actual workload. This capability ensures that you have the right amount of computing resources available to handle varying levels of demand without manual intervention. Auto Scaling is commonly used in cloud environments, like Amazon Web Services (AWS) and Microsoft Azure, to maintain high availability, optimize costs, and improve system performance.
Types of Autoscaling
- Vertical Pod Autoscaling — VPA (Up and Down)
- Horizontal Pod Autoscaling — HPA (Out and In)
- Dynamic Autoscaling
- Predictive Autoscaling
- Event-Driven Autoscaling
Event-Driven Autoscaling
Event-Driven Autoscaling allows you to trigger scaling actions based on specific events or conditions. For example, you can scale your application in response to increased user traffic, the arrival of new data, or the launch of a specific job.
KEDA
KEDA stands for Kubernetes Event-Driven Autoscaling, is an open-source project that provides event-driven auto-scaling for container workloads running on Kubernetes. It enables Kubernetes applications to scale based on external events, such as messages arriving in a queue, the number of HTTP requests, or custom event triggers. KEDA helps make your applications more efficient, cost-effective, and responsive to changes in workloads.
Why Event Driven with KEDA
Kubernetes allows you to autoscale in various ways: horizontally, vertically, or by nodes.
Disadvantages of another solutions
- Supporting only standard Kubernetes objects (deployment, stateful set, replica set) and relying on the metrics server
- There isn’t a way of observing their behavior, so you need to devise your own set of KPIs to see if they’re behaving as expected. So, if HPA or VPA aren’t working as expected for some obscure reason, you won’t receive precise alerts.
- There is not a metric adapter compatible with your data source to build autoscaling rules based on custom metrics. If you have no metric adapter available, you need to stick to resource metrics (CPU or memory).
KEDA vs Traditoinal Autoscalling
Why Event Driven with KEDA
KEDA fills two gaps which you will face while building distributed, cloud-native application at
massive scale.
1. KEDA gives you more control. More control over your instances in contrast to running them
in the public cloud. You can leverage existing Kubernetes cluster and run your, i.e. Azure
Functions, right next to other application building blocks of your overall architecture. KEDA
allows you to specify custom boundaries for scaling behavior.
2. On the other hand, KEDA lets you scale deployments in Kubernetes based on external
events or metrics. In Kubernetes, you can use Horizontal Pod Autoscaler (HPA) to scale
Deployments based on metrics generated inside of the cluster. Especially when running
Kubernetes in combination with external, cloud-based services such as Azure Service Bus,
your application artifacts have to scale on those external metrics.
KEDA provides a structured, streamlined strategy of how to address those needs without adding
much complexity to your overall architecture.
Key Benefits of KEDA
- Efficient Resource Usage
- Event-Driven Architecture
- Cost Optimization with scale-to-zero
- Flexible Integration (50+ scalers)
- Improved Performance
Potential Cost Savings
- Traditional HPA: always keeps minimum pods → higher cost
- KEDA enables idle apps to scale to zero
- Reduces compute resources
- Example: batch processor scaling from 0 to 10 saves up to 70%
KEDA architecture
KEDA monitors your event source and regularly checks if there are any events. When needed, KEDA activates or deactivates your pod depending on whether there are any events by setting the deployment's replica count to 1 or 0, depending on your minimum replica count. KEDA also exposes metrics data to the HPA which handles the scaling to and from 1.
Key components of KEDA
- Scaler: Connects to an external component (e.g., ServiceBus) and fetches metrics (e.g., queue depth)
- Operator (Agent): Responsible for “activating” a Deployment and creating a Horizontal Pod Autoscaler object
- Metrics Adapter: Presents metrics from external sources to the Horizontal Pod Autoscaler
Use Case example. WebApp, ServiceBus, Azure Function
Recap
- KEDA is a thin layer built on top of Kubernetes to allow scalable message processing using Azure Functions and other development models. It gives you more fine-granular control over scale-in and scale-out operations, which generally happen behind the scenes when running Azure Functions directly in Azure.
- Although KEDA has first-class Azure Functions support built-in, it is not limited to Azure Functions. The concept works for all kind of message-driven applications that has to be scaled based on metrics such as messages in an Azure Service Bus.
- Reduce costs, improve responsiveness
- Ideal for bursty, event-based workloads
- Works across cloud and on-prem
Whatsapp
73
Комментарии 0
Авторизуйтесь чтобы оставить комментарий