Google Kubernetes Engine 1.37 adds a native, control‑plane‑driven ability to shrink a workload to zero replicas and automatically bring it back when demand returns. Engineers can now eliminate the KEDA add‑on, reduce configuration bulk, and keep cost‑related idle compute to a minimum while preserving quick start‑up behavior.
What changed in GKE 1.37
The new feature embeds scale‑to‑zero logic directly into GKE’s Horizontal Pod Autoscaler (HPA) via an AutoscalingMetric. No separate operators or custom resources such as ScaledObject are required. The control plane monitors workload signals and can set the replica count to zero, then allocate pods from GKE capacity buffers when traffic spikes.
Why the change matters to AI, cloud, DevOps, and security teams
Batch jobs, event‑driven workers, and on‑demand development environments often sit idle for long periods. By scaling to zero, those workloads stop consuming CPU and memory, directly lowering the bill. The removal of KEDA also cuts operational toil: teams no longer need to install, upgrade, or troubleshoot an extra component. Because the signal path stays inside the control plane, the latency between a trigger and pod creation is shorter than the polling‑based approach used by KEDA.
Architectural and operational implications
Workloads can be defined with standard HPA objects and a minimal YAML snippet that references the new metric. This simplifies version control and reduces the risk of configuration drift that can arise from thousands of lines of KEDA‑generated YAML. Capacity buffers provided by GKE act as a safety net, so engineers do not need to over‑provision nodes to guarantee rapid scaling. Monitoring should focus on replica‑count transitions and cold‑start latency to verify that the native path meets service‑level expectations.
Security considerations
Fewer moving parts mean a smaller attack surface: the KEDA operator and its CRDs are no longer present in the cluster. However, the scale‑to‑zero control still relies on the GKE control plane, so appropriate IAM permissions for modifying HPA objects remain essential. Teams should audit who can enable or disable the feature and ensure that any custom metrics used for scaling are sourced from trusted components.
Related CloudNinjas coverage: Google Cloud.
What This Means For Practitioners
Enable the native scale‑to‑zero flag on GKE 1.37 clusters and replace existing KEDA ScaledObject definitions with standard HPA configurations that reference the AutoscalingMetric. Run a controlled test to measure cold‑start times against your current KEDA setup, and verify cost savings by comparing idle resource usage before and after the change. Finally, update role‑based access policies to reflect the reduced component set and monitor the new HPA behavior for any unexpected scaling delays.
