Cluster Autoscaler & KEDA

In one line

HPA scales your pods, but if the cluster's own nodes are already full, that's not enough — the Cluster Autoscaler adds real new nodes when needed, and KEDA extends HPA to scale on genuinely event-driven signals, including down to zero.

0/4 · 0%

Think of it like this

Topic 4.3's HPA is like calling in more staff for a dinner rush — but if the restaurant building itself is already completely full, more staff can't physically fit. The CLUSTER AUTOSCALER is the decision to open up an entirely new dining room (a new physical/virtual machine) when the existing space genuinely runs out.

Key ideas

01
HPA (Topic 4.3) scales the number of PODS — but if every existing node is already fully allocated, new pods triggered by HPA will simply sit Pending, unable to be scheduled anywhere, no matter how correctly HPA itself is working. The CLUSTER AUTOSCALER solves this different, underlying problem: it watches for Pending pods caused specifically by insufficient node capacity, and automatically provisions BRAND NEW WORKER NODES from the cloud provider to fit them.
02
This means real, full autoscaling in a cloud-managed cluster typically involves BOTH working together: HPA decides how many pods should exist based on load, and the Cluster Autoscaler ensures there's always enough underlying node capacity to actually schedule them — neither one alone is sufficient at genuinely variable, unpredictable scale.
03
The Cluster Autoscaler also scales DOWN — it identifies nodes that are significantly underutilized and safely REMOVES them (after first draining and rescheduling their pods elsewhere) once demand drops, directly connecting to Phase 6's rolling-update-style safe pod eviction, now applied to entire nodes rather than individual pod updates.
04
KEDA (Kubernetes Event-Driven Autoscaling) extends the HPA model beyond just CPU/memory to scale based on genuinely EVENT-DRIVEN signals — the depth of a message queue (Kafka, SQS), the number of pending jobs, or virtually any custom metric a KEDA 'scaler' plugin supports — and, genuinely distinctively, KEDA can scale a workload all the way DOWN TO ZERO replicas when there's truly no work to do, which plain HPA cannot do at all (HPA's minimum is always at least 1).
05
Scaling to zero is a genuinely significant capability for cost efficiency — a workload that only needs to run when messages actually arrive on a queue (a background job processor, say) can sit at ZERO running pods, costing nothing, and KEDA automatically scales it up the moment real work appears, then back down to zero once the queue is empty again.

Code & diagrams

ClusterAutoscalerFlowdiagram

HPA and the Cluster Autoscaler solve two different, complementary layers of the same scaling problem.

Rendering diagram…

keda-scaledobject.yamlmarkdown

Scale a queue worker from zero to many, based purely on queue depth.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: queue-worker-scaler
spec:
  scaleTargetRef:
    name: queue-worker      # the Deployment to scale
  minReplicaCount: 0         # can scale ALL THE WAY to zero — HPA alone cannot
  maxReplicaCount: 20
  triggers:
    - type: aws-sqs-queue
      metadata:
        queueURL: https://sqs.us-east-1.amazonaws.com/123456789/my-queue
        queueLength: "5"     # target: roughly 5 messages per replica

cluster-autoscaler-keda.shmarkdown

Watch both layers of scaling work together.

# See pods stuck Pending due to insufficient node capacity —
# this is exactly the signal the Cluster Autoscaler watches for
kubectl get pods
kubectl describe pod <pending-pod>
# Events: "Insufficient cpu" or "Insufficient memory"

# Watch new nodes appear automatically (on a cluster with it enabled)
kubectl get nodes -w

# With KEDA installed, apply the queue-based scaler
kubectl apply -f keda-scaledobject.yaml

# With an empty queue, confirm it's genuinely scaled to zero
kubectl get deployment queue-worker
# READY: 0/0

# Send messages to the queue, then watch it scale up from zero automatically
kubectl get deployment queue-worker -w

Explain it without notes

Why isn't HPA alone sufficient for genuinely automatic scaling in a real cloud cluster, even though it correctly manages the pod count?

What can KEDA do that plain HPA fundamentally cannot, and why does that matter for cost?

Practice

If you have access to a cloud-managed cluster with the Cluster Autoscaler enabled, deliberately schedule enough load to exhaust existing node capacity and watch a new node appear automatically via kubectl get nodes -w.

If you have KEDA installed, set up a queue-based ScaledObject (adjusted for whichever queue system you have access to) and confirm the workload genuinely scales to zero replicas when the queue is empty.

Trade-offs

↔
Scaling to zero saves genuine cost for intermittent workloads, but it introduces real COLD-START latency — the very first request or message after scaling to zero has to wait for a new pod to actually start up before it's handled, which is a real, sometimes-noticeable trade-off compared to keeping at least one warm replica always running; whether that trade-off is acceptable depends entirely on how latency-sensitive the specific workload genuinely is.

Done when you can

I understand why HPA alone isn't sufficient without the Cluster Autoscaler in a real cloud cluster.
I can explain what the Cluster Autoscaler actually watches for and what it does about it.
I know KEDA can scale to zero and can trigger on event-driven metrics HPA alone doesn't support.