GKE Cost Optimization Starts With Kubernetes Workload Requests

Google’s Kubernetes experience has made infrastructure management in GKE easier to automate. It hasn’t removed a stubborn source of cloud waste: workloads often ask for far more compute than they use. That gap matters because GKE can provision capacity to satisfy a request, but it can’t know whether the application truly needs what its configuration declares.

The 2026 State of Kubernetes Optimization Report puts numbers to the problem. Before automated optimization was enabled, average GKE CPU utilization was 8%, memory utilization was 20%, and GPU utilization was 6%. CPU overprovisioning reached 69%, while memory overprovisioning reached 79%. The analysis drew on direct measurements from more than 23,000 Kubernetes clusters and millions of compute resources across AWS, GCP and Azure.

Those figures don’t point to a failure of Google’s scheduler or node automation. Google created Kubernetes and has operated it at enormous scale; that experience informs GKE features such as Autopilot, which automates parts of infrastructure management. The remaining decisions sit closer to the application: teams have to determine what their workloads need, how much spare capacity is justified and which workloads can tolerate interruptions.

Start with workload requests

Low utilization can look like a node-pool issue, but changing node capacity won’t correct an oversized pod request. On GKE Autopilot, resource requests directly affect the cost of running a workload. On GKE Standard, they can also influence scheduling and lead the cluster to provision more node capacity than the application consumes.

Requests need enough headroom for real production variation. The waste appears when a defensive estimate becomes permanent, even after traffic patterns change or the original reason for the setting has been forgotten. The report found CPU overprovisioning across 69% of GKE clusters, up from 40% the previous year; memory overprovisioning affected 79%.

A useful starting point is to compare declared CPU and memory requests with observed consumption over a representative period. For a production service with weekly traffic cycles, seven to 14 days of data can reveal more than a snapshot from a quiet hour. The goal isn’t to reduce every request to its lowest observed value. It’s to distinguish justified headroom from padding that no longer serves the workload.

Consider a service that requests two CPUs and 2 GiB of memory while typically using about 500 millicores and 700 MiB. Increasing or shrinking the node pool doesn’t address that mismatch. Kubernetes is acting on the information it has: the application says it needs the larger allocation.

Teams can lower the risk of rightsizing by beginning with a small group of workloads, checking their behavior in production, and then widening the change. Automated rightsizing in the report cut provisioned CPU by roughly half while reducing out-of-memory kills to near zero. That result suggests that lower allocations don’t have to mean weaker reliability, provided changes follow observed workload behavior.

Keep autoscaling signals in sync

Vertical Pod Autoscaler can adjust resource requests, while Horizontal Pod Autoscaler can change the number of pod replicas. Running both against CPU or memory can create a feedback loop: VPA changes a request, HPA recalculates desired replicas, the new replica count changes utilization, and VPA responds again.

A safer first step is to run VPA in recommendation-only mode and review its suggestions. Where both autoscalers are needed, teams can consider application-level HPA signals such as request rate or queue depth. Those measures can better reflect demand for some services than CPU or memory alone.

The same care applies to rollout scope. A cluster-wide adjustment can make it difficult to identify which workload or setting caused an unexpected change. A limited rollout gives teams a clearer way to compare observed resource use, application behavior and reliability before expanding the policy.

Rightsize before tuning the node fleet

GKE Standard gives practitioners more direct control over the underlying Compute Engine fleet, and that control brings responsibility for unused capacity. Cluster Autoscaler remains the core scaling mechanism; Node Auto Provisioning can create node pools when workloads need machine types the cluster doesn’t already offer.

Neither mechanism can infer that application requests are inflated. If ten services each ask for twice the CPU they usually consume, autoscaling sees those declared requirements and provisions to meet them. Once requests reflect production needs more closely, however, node placement and scaling have a more useful baseline. The cluster can pack workloads more effectively, consider more suitable machine types, and remove capacity it no longer needs.

Match interruption risk to cheaper capacity

After workloads and baseline capacity are better aligned, teams can decide whether every workload needs on-demand compute. GKE Spot VMs can reduce costs for applications that tolerate interruption. Google’s Spot model provides roughly 30 seconds of preemption notice, so it isn’t a fit for every service.

Batch processing, CI/CD runners, stateless services with enough replicas, and machine-learning training jobs that checkpoint state are potential candidates. Production use still needs careful configuration: workloads should have suitable disruption budgets and termination handling, and the cluster should have an on-demand fallback when Spot capacity disappears. Without that fallback, a cost reduction can become an availability issue.

That creates a practical capacity mix. Keep workloads that need predictable availability on reliable capacity, while allowing interruption-tolerant jobs to use Spot when it’s available. The choice depends on what the application can withstand, not simply on whether a lower-cost capacity option exists.

Make expensive accelerators and CPUs work harder

GPU utilization is a different optimization problem from oversized CPU and memory requests. The report measured average GKE GPU utilization at 6%, with considerable variation during the day; GPU sharing remained relatively uncommon. If an inference workload uses only a fraction of a GPU most of the time, assigning it an entire device may leave expensive capacity idle. Sharing or partitioning can help multiple workloads use the same physical hardware, depending on the GPU and application.

One production example in the report moved seven models to GPU time-slicing, alongside improved bin-packing and Spot use. Costs fell by more than 70% compared with the previous platform while latency was maintained. The useful measure is whether the hardware completes more valuable work, not whether a utilization percentage improves on its own.

CPU architecture is another option for suitable workloads. ARM accounts for about 9% of the Kubernetes CPU fleet and has grown 3.5 times faster than x86 since the second quarter of 2024. GKE offers ARM choices including T2A and Google’s Axion-based C4A and N4A families. Teams can move a small set of scale-out workloads that support linux/arm64, then compare cost and performance before expanding. A cheaper processor won’t correct an oversized request by itself.

Set commitments after measuring the baseline

Pricing commitments make more sense after teams understand the capacity they consistently need. GCP’s Sustained Use Discounts apply automatically to eligible Standard node usage. Committed Use Discounts require a deliberate commitment against a baseline. If that baseline still contains excess capacity, a commitment can lock in the cost of today’s overprovisioning.

A more useful sequence is to make workload requests reflect production behavior, improve placement and node efficiency, assign interruption-tolerant work to Spot where appropriate, and increase use of GPU or ARM capacity when the workload fits. Then teams can assess the remaining baseline and decide how GCP pricing mechanisms apply.

GKE’s automation addresses many infrastructure tasks that become difficult at scale, but workload configuration still shapes the capacity the platform must provide. For practitioners, the concrete opportunity is to use production data to make that configuration more accurate, then expand changes in controlled steps. That puts cost, reliability and capacity decisions on a footing the cluster can act on.