TL;DR: Optimize costs by scaling Kubernetes workloads to zero using KEDA on GKE.
When I started helping teams optimize GKE platform costs, one pattern kept showing up: clusters were technically “autoscaled,” but workloads still ran 24/7. CPU would drop, traffic would disappear, but pods never truly scaled to zero.
In several real environments, teams were paying for compute that delivered zero business value overnight, during weekends, or between batch processing windows.
That’s where I started using KEDA with GKE — not everywhere, but in targeted workloads where event-driven scaling actually makes sense.
This post explains how I think about scale-to-zero on GKE, where KEDA fits, and what teams should consider before implementing it in production.
Standard Kubernetes autoscaling using HPA works well when scaling is based on:
CPU usage
Memory usage
Custom metrics
But many real workloads scale based on events, not resource usage.
Examples I commonly see:
Queue consumers
Event-driven APIs
Batch jobs triggered by storage or messaging events
ML inference workloads with burst traffic
In these cases, CPU may stay low even when work is pending. Or worse — CPU drops to zero, but pods still exist and still cost money.
HPA alone cannot scale to zero safely in most scenarios. That’s where KEDA becomes useful.
KEDA is best thought of as an event-driven autoscaling layer on top of Kubernetes.
Instead of scaling based on resource utilization, KEDA can scale based on:
Pub/Sub messages
Kafka topics
HTTP request counts
Storage queue depth
Custom external metrics
In most production environments I’ve worked with, teams introduce KEDA first for one service, validate behavior, and then expand usage gradually.
KEDA is not a replacement for HPA. I usually position it alongside standard autoscaling — used only where event-driven behavior is required.
From what I’ve seen, scale-to-zero works best in these workload types:
Event Processing Services
Queue consumers and async processors benefit the most. If no events exist, there is no reason to keep pods alive.
Burst APIs
Some APIs receive traffic only during business hours or scheduled processing windows.
ML Inference Jobs
GPU or high-memory workloads can become extremely expensive if left running idle.
Batch Data Processing
Scheduled jobs often run only a few times per day.
In these scenarios, scale-to-zero can remove a large portion of wasted compute spend.
Installing KEDA is usually straightforward. The real challenge is designing workloads that tolerate:
Cold starts
Event-driven execution
Stateless processing
Retry-safe logic
In practice, teams struggle more with application architecture than with Kubernetes configuration.
If a service cannot safely restart or rehydrate state quickly, scale-to-zero may introduce reliability risks.
I rarely recommend enabling KEDA cluster-wide immediately.
Instead, I usually suggest:
Start with one event-driven service
Validate scaling behavior under load
Measure cold start latency impact
Confirm cost savings are real
Expand gradually
KEDA works best as a targeted optimization, not a blanket platform policy.
Cost vs Performance Tradeoffs
Scale-to-zero is powerful, but it is not free.
Tradeoffs I usually discuss with teams:
Cold Start Latency
Pods need time to start. This may impact user-facing APIs.
Connection Warmup
Database connections, caches, and model loading add delay.
Monitoring Complexity
Event-driven scaling adds another dimension to observability.
When teams understand these tradeoffs, adoption becomes much smoother.
In platform environments, I usually see KEDA included as part of a golden path option, not a requirement.
Platform teams can provide:
Pre-configured KEDA templates
Standard scaling policies
Guardrails via policy-as-code
Monitoring dashboards
This keeps developer experience simple while still enabling advanced scaling patterns.
I usually avoid recommending scale-to-zero for:
Latency-sensitive synchronous APIs
Stateful long-running services
Services with heavy startup initialization
Systems requiring always-warm connections
In these cases, traditional HPA scaling is usually better.
From what I’ve seen in real GKE environments, scale-to-zero is one of the fastest ways to eliminate wasted compute cost — especially for event-driven or burst workloads.
KEDA is not something every service needs. But when applied in the right places, it can significantly improve platform efficiency and cost control without adding major operational complexity.
Like most platform decisions, the key is not whether the technology is powerful — it’s whether it fits the workload.
