Google Kubernetes Engine (GKE) 1.37 introduces native scale-to-zero capabilities, letting sporadic workloads such as batch processors, event-driven workers, and development environments scale down to zero replicas so they stop consuming compute resources while idle. When demand returns, these workloads can restart quickly on GKE capacity buffers, reducing infrastructure waste and decoupling the cost of always-on infrastructure from workload readiness.

The new approach builds on two components: HPA with AutoscalingMetric, a managed metrics signal pipeline that reads external signals directly from Google Cloud Managed Service for Prometheus, Pub/Sub, Cloud Monitoring, or Load Balancer signals without requiring an adapter; and KEP-2021, the Kubernetes Enhancement Proposal that enables minReplicas: 0 in the HorizontalPodAutoscaler. This lets the HPA stop all pods when metrics fall below a threshold and wake the deployment when pending work appears. Compared with Kubernetes Event-Driven Autoscaling (KEDA), which requires managing ScaledObject CRDs and operators and can involve thousands of lines of YAML for large fleets, GKE’s native version is a managed service with minimal YAML and an internalized signal path that reduces reaction time and cold-start delays.

To configure scale-to-zero, you define a metric source using the AutoscalingMetric CRD to map an external Cloud Monitoring metric to your cluster, then configure the HPA with minReplicas: 0 to reference that metric. This native external-metrics support extends the AutoscalingMetric custom resource to query metrics from Google Managed Service for Prometheus without third-party adapters, reducing latency and simplifying security.

The main challenge is cold start: the time to provision a node and pull and start the container. GKE capacity buffers address this by maintaining pooled warm compute resources shared by multiple scale-to-zero workloads, so a pod can claim resources immediately when the HPA jumps from 0 to 1. This avoids the 60-90 second wait for a new node, reducing startup latency from minutes to an instant while the workload itself maintains zero cost. Capacity buffers come in two forms: a small active buffer can serve hundreds of scaled-to-zero workloads as wildcard capacity, while a larger, cheaper standby buffer refills the active buffer for sustained load.

The article also notes upcoming roadmap work for finer-grained control over recurring scaling, such as scaling development environments down at 8:00 PM and back up at 7:00 AM. To get started, the suggested steps are to identify a workload with fluctuating demand and idle periods, configure AutoscalingMetric and set minReplicas to zero, and add capacity buffers to keep response times fast.