Learn KEDA - Basic Scalers

#Introduction

In episode 6, you mastered TriggerAuthentication — how KEDA gets secure access to various external systems. Now it's time to cover the part used most every day: triggers, often called scalers. In this episode we break down the four basic scalers that form the foundation of nearly all event-driven workloads: CPU/memory, cron, Prometheus, and HTTP. Why is this important? Because real production rarely gets by with just one trigger type — they combine resource, schedule, and business metrics signals all in a single ScaledObject.

#The Anatomy of a Trigger in ScaledObject

#Basic Structure

Each triggers list inside a ScaledObject's spec contains one or more triggers. Each trigger has three important parts: type determines which scaler is used, metadata holds scaler-specific parameters, and authRef (optional) points to a TriggerAuthentication for authenticated scenarios.

All values in metadata must be strings — that's why you see threshold: "100" in quotes, not a bare 100 number.

#One ScaledObject, One Workload

Important rule: one Deployment may only be managed by one ScaledObject. If you want to add a signal, add a new trigger inside the same ScaledObject. Never create a second ScaledObject for the same Deployment — the result is two HPAs fighting over replica control and conflict.

#CPU & Memory Scaler

#CPU Scaler

The CPU scaler works like CPU-based HPA, but integrated into the same mechanism as other triggers. It's suitable for workloads responsive to computational load such as APIs or web servers, and uses metrics already collected by metrics-server — no external credentials needed.

Here KEDA builds an HPA that keeps the average CPU utilization across all pods at 60 percent. When utilization passes that number, HPA increases replicas gradually. Verify the result with kubectl get scaledobject api-cpu -n production and kubectl get hpa -n production.

Trigger	Parameter	Description
`cpu`	`type`	`Utilization` or `AverageValue`
`cpu`	`value`	Target utilization percent or absolute CPU value
`memory`	`type`	Same as CPU
`memory`	`value`	Target memory in Mi/Gi units or percent

#Memory Scaler

The memory scaler is identical, only the metric changes. Suitable for RAM-hungry workloads, such as in-memory caches, data processing, or workers that gather data before processing.

Warning

CPU and memory are reactive metrics: they only rise after load arrives, not before. For event-driven workloads (queue, backlog), always also install an event-based trigger. More importantly, CPU/memory don't support scale-to-zero because their values are almost always above zero — use minReplicaCount: 1.

#Cron Scaler: Predictive Scaling

Unlike all other scalers that react to metrics, the cron scaler is predictive: it forces a certain number of replicas on a given schedule, no matter what traffic does. This is ideal for predictable business patterns — a 10 AM promo, evening live streaming, or midnight report batches.

Between 08:30 and 18:45 WIB every day, KEDA maintains 5 replicas; outside that schedule it scales down following other metrics — here to zero because of minReplicaCount: 0. This pattern is known as predictive scaling or schedule-based autoscaling.

Cron Expression	Meaning
`30 8 * * *`	Every day at 08:30
`0 9 * * 1-5`	Every Monday-Friday at 09:00
`0 22 1,15 * *`	On the 1st and 15th of every month at 22:00

Tip

Always set timezone explicitly. Without it KEDA uses the node's timezone, and a schedule can change meaning just because a cluster moved regions.

#Prometheus Scaler: Custom Queries

Prometheus is KEDA's eyes for seeing any metric that can be computed. With this scaler you're free to define queries — RPS, error rate, internal queue length, even business metrics — and KEDA scales pods according to the results.

RPS-based Prometheus scaler

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-rps
spec:
  scaleTargetRef:
    name: api
  minReplicaCount: 0
  maxReplicaCount: 20
  triggers:
    - type: prometheus
      metricType: AverageValue
      metadata:
        serverAddress: http://prometheus.monitoring.svc:9090
        metricName: http_requests_rate
        query: |
          sum(rate(http_requests_total{job="api"}[2m]))
        threshold: "100"

With metricType: AverageValue and threshold: "100", one pod is considered enough to handle an average of 100 requests per second.

Tip

For ever-increasing counters like http_requests_total, always wrap them in rate() or increase(). Reading a raw counter gives a constantly growing value and makes KEDA guess the replica count wrong.

#HTTP Scaler: Pending Requests

The http scaler monitors how many requests haven't finished being processed by the application — a combination of in-flight and queued requests. This is a much finer signal of latency and congestion than RPS: 100 slow requests are more dangerous than 1,000 fast ones.

When pending requests exceed 10, replicas are added. When there are no pending requests, pods can drop to zero — the application must be ready to accept a cold start.

Note

The http scaler only reads metrics exposed by the application or service mesh. If you want full HTTP scale-to-zero with an interceptor that holds requests while there are zero pods, you need the KEDA HTTP Add-on and HTTPScaledObject — we'll cover that fully in episode 12.

#Conclusion

You've now mastered four basic scalers:

CPU/memory: reactive resource metrics, suitable for computational workloads, no scale-to-zero.
Cron: predictive, forces replicas on schedule, perfect for predictable business patterns.
Prometheus: custom queries from any metric, the most flexible scaler.
HTTP: scales based on pending requests, a fine congestion signal.

These four signals still measure metrics inside or around the cluster. In episode 8 we head to where KEDA is most used in the real world: message queues and streams — from AWS SQS with IRSA, Azure Service Bus, GCP Pub/Sub, to RabbitMQ, Kafka, Redis Streams, and NATS JetStream. See you there!