In a previous blog post – Serverless anywhere with Kubernetes – I wrote how you could write serverless code and run it in a container wherever you want without any vendor lock-in.

KEDA (Kubernetes-based Event-Driven Autoscaling) is an opensource project built by Microsoft in collaboration with Red Hat, which provides event-driven autoscaling to containers running on an AKS (Azure Kubernetes Service), EKS ( Elastic Kubernetes Service), GKE (Google Kubernetes Engine) or on-premises Kubernetes clusters 

KEDA allows for fine-grained autoscaling (including to/from zero) for event-driven Kubernetes workloads. KEDA serves as a Kubernetes Metrics Server and allows users to define autoscaling rules using a dedicated Kubernetes custom resource definition. Most of the time, we scale systems (manually or automatically) using some metrics that get triggered.

For example, if CPU > 60% for 5 minutes, scale our app service out to a second instance. By the time we’ve raised the trigger and completed the scale-out, the burst of traffic/events has passed. KEDA, on the other hand, exposes rich events data like Azure Message Queue length to the horizontal pod auto-scaler so that it can manage the scale-out for us. Once one or more pods have been deployed to meet the event demands, events (or messages) can be consumed directly from the source, which in our example is the Azure Queue.

Quote from Serverless anywhere with Kubernetes

A while has passed since I wrote about KEDA; I implemented it in some projects. Unfortunately, I can’t detail those implementations; I can say that all the projects where KEDA was implemented had a boom in scalability with lower costs.

So you can say that everybody was happy. Of course, there were some problems at the beginning of the implementation, but you need to look at the end result.

Going back to the subject, version two of KEDA received general availability, and it got better, let’s say awesome 🙂

Read More – keda/CHANGELOG.md

There are significant improvements around ScaledObjects where you now can scale StatefulSets or CustomResources and not just Deployments or Jobs resources. The CustomResources that you want to use with KEDA require a scale subresource implemented, and that’s it.

Also, there are improvements around metrics and operator pods where it now exposes liveness and readiness probes so you can monitor the state and health of the system. As a bonus, the metrics server also exposes Prometheus metrics for each scaler that you’re using.

Regarding scalers -there are many more since I wrote about it, so go ahead and check them out.

During some KEDA implementations, we had some issues where Jobs were either stuck or had similar behaviors with deadlocks, not because KEDA was buggy or broken. Long-running executions were not a thing for version one of KEDA, which caused some issues with Service Bus or RabbitMQ. Let’s say that it was a feature and not a bug.

With version 2.0, we now have a new CRD called ScaledJob, where instead of scaling code as deployment, you can now scale the code as a Kubernetes Job, which, guess what it fixes the problem of having long-running execution jobs not being killed while running. Jeff Hollan called it the Thanos snap of Kubernetes 🙂

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: scaledjob-example
spec:
  jobTargetRef:
    parallelism: 1
    completions: 1
    activeDeadlineSeconds: 600
    backoffLimit: 6
    template:
      ## template
  pollingInterval: 30
  successfulJobsHistoryLimit: 5
  failedJobsHistoryLimit: 5
  maxReplicaCount: 100
  triggers:
    - type: example-trigger
      metadata:
        property: example-property

ScaledObject mostly remained the same but came with some improvements and some breaking changes:

OldNew
apiVersion: keda.k8s.ioapiVersion: keda.sh
spec.scaleTargetRef.deploymentNamespec.scaleTargetRef.name
spec.scaleTargetRef.containerNamespec.scaleTargetRef.envSourceContainerName
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: example-scaledobject
spec:
  scaleTargetRef:
    name: example-deployment
  pollingInterval: 30
  cooldownPeriod: 300
  minReplicaCount: 0
  maxReplicaCount: 100
  triggers:
    - type: example-trigger
      metadata:
        property: example-property

This brings me to migrating to the new version of KEDA

This brings me to migrating to the new version of KEDA

  1. KEDA v1 and KEDA v2 cannot run in parallel, so you need to uninstall the first version and remove its associated CRDS from the cluster.
  2. The API Namespace has changed from keda.k8s.io to keda.sh as shown in the example above.
  3. The deploymentName label is no longer necessary under the metadata node.
  4. Job scaling should be done via ScaledJob and not ScaledObject.

If you didn’t get started with KEDA then this is a great time to get started with it and I will redo a shameful plug to my article where you can play around with it: Serverless anywhere with Kubernetes

The main difference is the KEDA version and that helm 3.0 requires the namespace to exist

#Login to your AKS cluster
az aks get-credentials -n <aksClusterName> -g <resourceGroupofSaidCluster>
#Install KEDA using Helm
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
kubectl create namespace keda
helm install keda kedacore/keda --version 2.0.0 --namespace keda
#Validate that KEDA is up and running
kubectl get pods -n keda
#--> you should see the keda-operator pod up and running

That being said, happy sailing and scalling!

Pin It on Pinterest