Discover the Power of Event-Driven Autoscaling with Keda

What is Autoscaling?

Autoscaling in general refers to capability of a system to automatically adjust its resources, such as computing power, storage or network bandwith, based on the current workload or demand. Autoscaling in Kubernetes extends this automation to dynamically adjust the number of running (pods) based on resource usage and other metrics.

Horizontal Pod Autoscaling (HPA)

Horizontal Pod Autoscaler (HPA), a Kubernetes API resource and a controller belonging to API version autoscaling/v2, automatically updates a workload resource such as a Deployment or StatefulSet, with the aim of automatically scaling the workload to match demand.Horizontal scaling involves deploying more Pods to respond to increased load. If the load decreases and the number of Pods is above the configured minimum, the HorizontalPodAutoscaler instructs the workload resource, the Deployment, StatefulSet, or other similar resource, to scale back down.

Example HPA Resource:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: example-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: example-deployment
  minReplicas: 1
  maxReplicas: 3
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70

What is KEDA?

KEDA (Kubernetes event-driven autoscaling) is an open source project designed to extend Kubernetes, empowering developers to scale their applications seamlessly in response to varying workloads triggered by events. These events could range from changes in message queue depths to incoming HTTP requests to custom-defined metrics. KEDA acts as a bridge between Kubernetes and event sources, allowing for autoscaling of containerized workloads.KEDA is a Cloud Native Computing Foundation (CNCF) graduated project.

Keda vs HPA

Scaling Trigger

• KEDA: Event-driven, allowing scaling based on custom metrics or external events.
• HPA: Metric-driven, typically scaling based on CPU or memory utilization.

Versatility

• KEDA: Highly versatile, supporting a broad range of event sources.
• HPA: Limited to scaling based on metrics directly associated with the pods.

Use Cases

• KEDA: Ideal for applications with variable workloads triggered by events, such as message queue depths or external triggers.
• HPA: Well-suited for applications with predictable scaling needs based on standard resource metrics.

KEDA’s Beneficial Features

KEDA plays a crucial role in enhancing the efficiency of autoscaling by providing a flexible and event-driven approach to adapt to real-time workloads. In the broader cloud native landscape, KEDA contributes to efficient autoscaling in a multitude of ways.

1. Event-Driven Scaling
2. Diverse Event Sources Support
3. Optimal Resource Utilization
4. Cost Efficiency
5. Compatibility with Kubernetes Ecosystem
6. Enhanced Developer Productivity
7. Scalability Across Microservices

How KEDA Works

KEDA is a lightweight and single-purpose component that can be added to any Kubernetes cluster. KEDA can expand functionality without overwriting or duplicating existing components when used in conjunction with other standard Kubernetes components like the Horizontal Pod Autoscaler. With KEDA, you may map applications directly to an event-driven scale while keeping other applications operational. Because of this, KEDA may be used safely and adaptably with any number of other Kubernetes frameworks or applications.

There are three major roles that KEDA performs on a Kubernetes cluster:

1. Agent — KEDA enables Kubernetes deployments to scale to and from zero on no events. The container keda-operator is responsible for this on the cluster. It runs after KEDA has been enabled on the cluster.
2. Metrics — KEDA directly exposes metrics such as stream lag and message queue length to HPA enabling it to scale the deployments on metrics obtained. Thus KEDA also acts as a Kubernetes metrics server. The container keda-operator-metrics-apiserver is responsible for this metric serving.
3. Admission Webhooks — KEDA can be used in conjunction with an admission controller to automatically detect resource configuration changes, keeping the deployments and the cluster at large in a stable state. It also preserves a scale target from being scaled by multiple ScaledObjects.

Architecture of KEDA

KEDA integrates with the already mentioned Horizontal Pod Autoscaler in Kubernetes. Components such as external event sources and the etcd data store are also used to read events in the cluster and scale accordingly, if needed. Here is a visual representation of the same.

Keda Architecture

In the picture above, the ScaledObject resource defines how a scale target such as a deployment, custom resources, jobs, or StatefulSets must be scaled by KEDA. The “KEDA block” works with an external event source, monitoring it for events that should trigger the scaling of the target resource. KEDA transfers the scaling request to the HPA that scales the workload.

A “scaler” detects if a deployment should be activated or deactivated, and feeds custom metrics for a specific event source. There are several scalers available depending on the external event sources and cluster metrics. A few examples of supported event sources are: Google Cloud Platform Storage, memory, Redis, PostgreSQL, and many others.

KEDA Custom Resource Definitions (CRDs)

Kubernetes comes with a set of API resources that enables users to create objects such as pods, deployments, and jobs. When KEDA is installed into a Kubernetes cluster, it comes with four Custom Resource Definitions (CRDs) as part of the KEDA installation. These CRDs function similarly to other API resources, allowing users to map event sources. They enable authentication to access events from these sources and support scaling of targets such as Deployments, StatefulSets, Jobs, or other customer resources.

scaledobjects.keda.sh

ScaledObjects defines how KEDA should scale a specific deployment or workload. The configuration for ScaledObjects includes the following main elements:

• scaleTargetRef: Specifies the target deployment or workload that KEDA will scale.
• triggers: Defines the event sources and corresponding parameters that trigger autoscaling.
• minReplicaCount and maxReplicaCount: Specify the minimum and maximum number of replicas for the target workload.

Example code snippet of ScaledObject:

apiVersion: keda.sh/v1alpha1
 kind: ScaledObject
 metadata:
 name: my-scaledobject
 spec:
 scaleTargetRef:
 name: my-deployment
 triggers:
 - type: azure-queue
 metadata:
 queueName: my-queue
 connection: azure-secret
 queueLength: '5'
 minReplicaCount: 1
 maxReplicaCount: 10

scaledjobs.keda.sh

ScaledJob is a custom resource designed for autoscaling Kubernetes Jobs.

Similar to ScaledObject, it defines scaleTargetRef and triggers specific to Jobs. It also allows autoscaling based on job completion or failure events.

Example code snippet of ScaledJob:

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
 name: my-scaledjob
spec:
 scaleTargetRef:
 name: my-job
 triggers:
 - type: job-completion

triggerauthentications.keda.sh

TriggerAuthentication is used to secure the communication between KEDA and external event sources. It ensures that only authenticated sources can trigger autoscaling. The configuration requires authentication details such as API keys and secrets for the external event sources.

Example code snippet of TriggerAuthentication

apiVersion: keda.sh/v1alpha1
 kind: TriggerAuthentication
 metadata:
 name: my-triggerauth
 spec:
 secretTargetRef:
 - parameter: apiKey
 name: my-secret
 key: api-key

KEDA Installation

KEDA can be deployed through several methods: using the Operator Hub, a YAML file, or the Helm chart. Here, we will focus on deployment via Helm. It’s important to note that KEDA requires a Kubernetes cluster version 1.24 or higher.

Like any other Helm deployment, this only involves three simple steps:

1. Add Helm repository:
   helm repo add kedacore ht‌tps://kedacore.github.io/charts
2. Update the Helm repository:
   helm repo update
3. Install the KEDA Helm chart:
   helm install keda kedacore/keda — namespace keda — create-namespace

Uninstalling KEDA

The following two steps are needed to uninstall KEDA:

1. Remove any ScaledObjects and ScaledJobs that you have created:
   kubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \
   -o jsonpath=’{“-n “}{.items[*].metadata.namespace}{“ “}{.items[*].kind}{“/”}{.items[*].metadata.name}{“\n”}’)
2. Uninstall the Helm chart:
   helm uninstall keda -n keda

Sources I benefited from:

KEDA | Kubernetes Event-driven Autoscaling

Scaling Cloud Native Applications with KEDA | Linux Foundation

Thank you for reading until the end. Before you go:

Please remember to clap for this article and follow me! 👏 If you want to follow me, LinkedIn