Learn KEDA - ScaledObject & ScaledJob

#Introduction

We've installed KEDA (episode 3) and understood its architecture (episode 2). Now it's time to touch the objects you'll write throughout your event-driven career: ScaledObject for workloads that live continuously, and ScaledJob for batch workloads that live and die.

Episode 4 dissects all the key fields you'll encounter, then explains why these two objects behave very differently despite their similar names.

#ScaledObject for Continuous Workloads

ScaledObject is used for workloads that are always alive but whose replica count follows events: Deployment, StatefulSet, or ReplicaSet. The simplest example:

ScaledObject with RabbitMQ

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-worker-scaledobject
spec:
  scaleTargetRef:
    name: order-worker
  pollingInterval: 30
  cooldownPeriod: 300
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: rabbitmq
      metadata:
        queueName: orders
        queueLength: "20"

Let's break down the fields one by one.

#scaleTargetRef

Points at the workload to scale, exactly the name of the Deployment (or StatefulSet/ReplicaSet). KEDA then creates an HPA targeting this deployment. If the deployment isn't found, the KEDA object will be in an inactive state.

#pollingInterval and cooldownPeriod

• pollingInterval (seconds): how often KEDA checks metrics from the scaler. Too small a value makes KEDA hammer the event source API; too large makes responses slow. 30 seconds is a reasonable starting point.
• cooldownPeriod (seconds): the time that must pass after the last event decreased before replicas are scaled down. This prevents replicas from bouncing due to momentary fluctuations. Default value is 300 seconds.

Viewing ScaledObject status and actual metrics

kubectl get scaledobject order-worker-scaledobject -o yaml
kubectl get hpa order-worker-scaledobject
kubectl get --raw /apis/external.metrics.k8s.io/v1beta1 | head -20

#minReplicaCount, maxReplicaCount, and idleReplicaCount

• minReplicaCount: the lower bound of replicas while events are active. A value of 0 enables scale-to-zero (covered fully in episode 5).
• maxReplicaCount: the upper bound of replicas. Always set this with cluster capacity and downstream capacity in mind.
• idleReplicaCount: if set, KEDA scales replicas down to this idle value when there are no events — a kind of "standby mode" that's cheaper than staying at full capacity.

#triggers

triggers is the list of metric sources. If more than one trigger is given, HPA uses the highest value among them. Each trigger has a type (scaler name) and metadata (scaler-specific parameters). Some scalers also need an authenticationRef pointing to a TriggerAuthentication — that's episode 6.

Multi-trigger: rabbitmq and cron

spec:
  triggers:
    - type: rabbitmq
      metadata:
        queueName: orders
        queueLength: "20"
    - type: cron
      metadata:
        timezone: Asia/Jakarta
        start: "0 8 * * *"
        end: "0 18 * * *"
        desiredReplicas: "5"

#ScaledJob for Batch Workloads

ScaledJob works for Kubernetes Jobs: one-shot jobs with a beginning and an end. Instead of changing the replica count of an always-running pod, KEDA creates a new Job every time the metric shows there's work to do.

SQS-based ScaledJob

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: report-generator-job
spec:
  jobTargetRef:
    template:
      spec:
        template:
          spec:
            containers:
              - name: worker
                image: my-registry/report-worker:latest
            restartPolicy: Never
  pollingInterval: 30
  maxReplicaCount: 10
  triggers:
    - type: aws-sqs-queue
      authenticationRef:
        name: keda-trigger-auth-sqs
      metadata:
        queueURL: https://sqs.ap-southeast-1.amazonaws.com/1234/orders
        queueLength: "5"

#Behavior Differences vs Deployment

Crucial difference: because each Job runs until completion, cooldownPeriod in ScaledJob controls how long KEDA stops creating new Jobs after events subside — not waiting for pods to finish. Think of ScaledJob as "a work queue that builds its own workers".

#Choosing the Right One

The rule of thumb is simple:

• Workloads that are always alive and process events when they arrive — use ScaledObject.
• Workloads that only exist when there's work (batch, ETL, reports) — use ScaledJob.

#Conclusion

Episode 4 gives you KEDA's two main weapons. Here's what you must bring along:

• scaleTargetRef points at the workload; pollingInterval, cooldownPeriod, and maxReplicaCount control sensitivity.
• minReplicaCount: 0 and idleReplicaCount open the path to scale-to-zero.
• triggers can be more than one; HPA uses the highest value.
• ScaledJob creates a new Job per event, rather than adding pod replicas.

In episode 5 we'll discuss the most important consequence of minReplicaCount: 0: when scale-to-zero is safe, when it's dangerous, and how activationThreshold prevents unnecessary flapping.