GKE Cost Optimization: 7 Ways to Cut Google Kubernetes Engine Costs

Google Kubernetes Engine is one of Google Cloud's flagship products and the managed Kubernetes service with the longest track record of any major cloud provider. GKE introduced managed control planes years before EKS and AKS followed, and it shows in the maturity of its autoscaling, node management, and Autopilot offerings.

But mature tooling doesn't prevent cost waste. It just means the waste accumulates in more places. GKE clusters running for 12+ months typically carry significant orphaned storage — persistent disks provisioned for PVCs that no Pod has mounted in months. They often have load balancers attached to Services whose backends were scaled to zero. And teams running older Kubernetes versions are now paying Google's extended support surcharge on top of their normal Compute Engine costs.

This guide covers 7 ways to reduce your GKE bill. The largest immediate opportunity for most teams is the orphaned resource audit — finding what you're paying for and not using before touching anything active.

GKE Cost Breakdown

Understanding where GKE costs originate is the prerequisite to reducing them effectively.

Compute Engine nodes are the primary cost driver. GKE Standard clusters run on Compute Engine VMs — n2-standard-4, e2-medium, c2-standard-8 — billed at standard Compute Engine rates. The cluster manages them, but you pay the full VM price. Over-provisioned nodes running at low utilization are the most common source of unnecessary GKE spend.

Persistent Disks back GKE PersistentVolumeClaims. A pd-standard volume costs $0.04/GB/month; pd-ssd runs $0.17/GB/month; pd-balanced sits at $0.10/GB/month. Critically, persistent disks are not deleted when Pods or Deployments are removed. The disk continues billing at full capacity regardless of whether any Pod has mounted it. This is the GCP equivalent of orphaned EBS volumes, and it's equally invisible to most cost dashboards.

Cloud Load Balancers are provisioned for each Kubernetes Service of type LoadBalancer. GCP charges a per-hour forwarding rule fee plus a per-GB data processing charge. A load balancer serving zero traffic still incurs the forwarding rule fee. Teams with a history of frequent Service creation and deletion often accumulate several idle load balancers.

Network egress costs $0.08–$0.12/GB for traffic leaving Google Cloud, depending on destination. Cross-region traffic within GCP runs $0.01–$0.08/GB. Workloads that make frequent external API calls or replicate data across regions can generate significant egress charges.

Extended support fees are charged for GKE clusters running Kubernetes versions that have passed their end of standard support date. The surcharge is approximately $0.015/vCPU/hour — on a cluster with 40 vCPUs across 10 nodes, that's roughly $432/month on top of normal compute costs. This is an increasingly common hidden cost as teams defer version upgrades.

GKE Autopilot pricing is per Pod resource request (CPU + memory) rather than per node. It can be cost-effective for clusters with bursty, variable workloads. For steady-state workloads with consistent load, Standard GKE with Cluster Autoscaler typically costs less.

7 Ways to Cut GKE Costs

1. Find and Delete Orphaned Persistent Disks

Orphaned persistent disks are the fastest, safest GKE cost reduction available. A persistent disk with no mounting Pod provides zero value, can be deleted without any production impact, and reduces your bill immediately upon deletion.

A PVC becomes orphaned when its Pod or workload controller (Deployment, StatefulSet, Job) is deleted without also deleting the PVC. Kubernetes intentionally does not auto-delete PVCs on workload deletion to protect data. The result: every environment teardown, every StatefulSet deletion, and every database migration leaves behind PVCs — and the disks they represent.

To find orphaned PVCs manually: kubectl get pvc --all-namespaces lists all claims. Cross-reference with running and pending Pods across all namespaces. Any PVC not appearing in a Pod's volumes spec is a deletion candidate. For PVs in Released state, the associated claim was already deleted but the disk was retained.

For a complete guide on the mechanics and validation process, see How to Find Orphaned PVCs and PVs Before They Inflate Your Cloud Bill.

KorPro automates this cross-reference. Connect your GKE cluster with read-only IAM permissions, and the orphaned PVC/PV report runs in under a minute with volume sizes and estimated monthly cost per disk.

2. Remove Unused Cloud Load Balancers

GKE's cloud controller manager provisions a Cloud Load Balancer for every Kubernetes Service of type LoadBalancer. When the Service is deleted, the load balancer deprovisions — in theory. In practice, there are several failure modes that leave load balancers running with no associated Service:

• The Service was deleted but the cloud controller was unresponsive, leaving the LB orphaned in GCP.
• The NetworkEndpointGroup cleanup was incomplete after a GKE upgrade.
• An Ingress or BackendService was left behind from a removed Ingress resource.

Check your GCP console under Network services > Load balancing. For each load balancer, verify there is a corresponding active Kubernetes Service. Any LB without an active Service backend is safe to delete.

3. Use Spot VMs for Stateless Workloads

GKE Spot VMs run at 60–91% discounts compared to standard Compute Engine pricing for equivalent instance types. For stateless workloads — web servers, API services, batch jobs, CI runners, ML training — Spot is the single highest-impact cost lever available in GKE.

Configure a separate node pool with Spot VMs and use node selectors or Pod affinity rules to schedule tolerant workloads onto it. Keep a small on-demand node pool for stateful and latency-sensitive workloads that can't tolerate Spot interruptions.

GKE provides a managed spot pool option that handles node selection and replacement automatically. Combined with PodDisruptionBudgets and graceful termination, Spot VMs are operationally manageable for the majority of cloud-native workloads.

4. Enable Cluster Autoscaler or Switch to Autopilot

Static node pools sized for peak load waste money during off-peak hours. A cluster sized for Black Friday traffic runs at 20% utilization for 95% of the year.

Cluster Autoscaler for GKE Standard scales node pools in response to pending Pods and underutilized nodes. It's the standard approach for Standard clusters and works well with managed node pools. Enable it per node pool and set minimum and maximum node counts based on your actual traffic patterns.

GKE Autopilot removes node management entirely. Autopilot clusters provision and scale nodes automatically based on Pod resource requests, and Google manages the underlying Compute Engine fleet. For teams with highly variable or unpredictable workloads, Autopilot eliminates the over-provisioning problem by design — you pay for what Pods request, not for idle node capacity.

The right choice depends on workload predictability. Steady-state production workloads with consistent load profiles often cost less on Standard + Cluster Autoscaler. Variable development, CI/CD, or batch workloads frequently cost less on Autopilot.

5. Clean Up Unused Secrets and ConfigMaps Across Namespaces

Stale Secrets and ConfigMaps don't incur direct compute costs, but they increase etcd size, slow API server list operations, and indicate accumulated configuration debt that makes clusters harder to audit and govern.

More practically: if you can't easily enumerate what configuration exists in your cluster, you can't confidently clean up other resources that depend on it. A systematic ConfigMap and Secret audit is part of the discipline of cluster hygiene that makes storage and compute audits possible.

Common sources of stale ConfigMaps: Helm releases that were uninstalled without --purge, CI/CD pipelines that create per-build configs without cleanup, and deprecated feature flag stores that were superseded but not removed.

For a step-by-step approach, see How to Find and Remove Orphaned ConfigMaps in Kubernetes. KorPro's read-only scan cross-references all ConfigMaps and Secrets against active workloads and surface those with no live reference.

6. Use Committed Use Discounts for Predictable Baselines

Google Cloud Committed Use Discounts (CUDs) provide 1-year and 3-year commitments on Compute Engine resources at 37–55% discounts over on-demand pricing. For GKE Standard clusters with stable baseline node counts, CUDs are a straightforward way to reduce the cost of capacity you know you'll use.

The key is sizing the commitment to your baseline, not your peak. Commit to the node count you run 24/7 and use Cluster Autoscaler + Spot VMs to handle burst capacity above that baseline. Committing to peak capacity defeats the purpose — you'd be locking in over-provisioning rather than fixing it.

Resource-based CUDs (CPU and memory) are more flexible than machine-type-specific commitments and can apply across multiple node pools and regions within a project.

7. Upgrade to Supported Versions to Avoid Extended Support Fees

GKE's extended support policy charges approximately $0.015/vCPU/hour for clusters running Kubernetes versions that have passed standard support end dates. This fee applies to all nodes in the cluster — not just the control plane.

On a 10-node cluster of n2-standard-4 instances (4 vCPU each = 40 vCPUs total), the extended support surcharge is approximately $0.015 × 40 × 720 hours/month = $432/month. For larger clusters, the surcharge can exceed $1,000/month.

Check your GKE cluster version against the GKE release schedule. Upgrading to a supported minor version removes the extended support fee entirely and is almost always the right call unless there's a specific compatibility blocker.

If a version upgrade is blocked by a deprecated API or application dependency, the extended support fee is the cost of deferring that work. Treat it as a signal to prioritize the upgrade.

GKE Cost Audit with KorPro

A systematic audit before cleanup prevents deleting resources that are still in use. Here's the recommended workflow for GKE:

1. Connect KorPro to your GKE project with read-only IAM permissions. The required permissions are minimal — container.viewer and storage.objectViewer are sufficient. No write access, no agents to install, no cluster-side components to deploy. See the GCP setup guide for the exact IAM configuration.

2. Run the orphaned PVC/PV scan. KorPro lists every PVC not mounted by a running Pod, with the underlying persistent disk size, storage class, and estimated monthly cost. Review the list and mark items for deletion.

3. Run the unused Services scan. Services of type LoadBalancer with no backend Pods are surfaced alongside estimated GCP load balancer cost.

4. Run the ConfigMap and Secret scan. Every ConfigMap and Secret not referenced by an active workload in the same namespace is flagged.

5. Review estimated total savings. KorPro aggregates all findings into a monthly savings estimate before any deletion is performed. Share this with your team to prioritize.

For more on the cost recovery workflow, see Kubernetes Cost Recovery and the KorPro cost optimization guide.

After cleanup, set a recurring audit cadence — monthly for active clusters, weekly for clusters with frequent deployments. Orphaned resources accumulate faster than most teams expect.

Conclusion

GKE cost optimization starts with understanding what you're paying for, then systematically eliminating spend that provides no value. Orphaned persistent disks and unused load balancers are immediate, zero-risk wins. Spot VMs and autoscaling deliver sustained savings on compute. Staying on supported Kubernetes versions eliminates a surcharge that grows silently with cluster size.

Start with the 5-minute audit. Connect KorPro to your GKE clusters with read-only access and get a complete picture of orphaned resources and estimated savings before deleting anything. See the GCP setup guide to get started.