To use the GKE cost optimization dashboard, enable GKE cost allocation on each cluster, turn on the Cloud Billing detailed usage export to BigQuery, then read spend by cluster, namespace, and label against requested versus used CPU and memory. The gap between request and usage is idle waste you are paying for. GKE cost allocation data is queryable only in the BigQuery billing export, so that export is the prerequisite for any dashboard. Native visibility is free; you act on the workloads with the widest request to usage gap first.
Last updated: June 2026. Written by Morten Andersen and reviewed by Fredrik Filipsson, built on our See, Cut, Lock, Run method.
This article sits in our complete guide to Google Cloud cost optimization, the cluster pillar it links up to, and connects to the broader cloud cost optimization playbook. For a related slot level lever on the data side, see our companion guide on how to reduce BigQuery slot and reservation costs. Reading the dashboard is a See step task: you cannot Cut what you cannot attribute.
Request versus usage. On GKE Standard you pay for the CPU and memory your pods request, not what they consume, so a namespace requesting 100 vCPU but using 40 is burning 60 percent of that line. The dashboard exists to surface that ratio per workload so you rightsize the worst offenders instead of guessing. Aim for sustained usage above 60 percent of requests on steady workloads before you consider the cluster tuned.
What is the GKE cost optimization dashboard?
The GKE cost optimization dashboard is the set of views in Google Cloud that break a cluster bill down to namespace, workload, and label, and compare requested resources to actual usage. It is not a single button; it is GKE cost allocation feeding the Cloud Billing reports and the BigQuery export, optionally surfaced through Looker Studio or Grafana. The point is attribution plus efficiency in one place: who spent it, and how much of what they reserved they actually used. Without it, a GKE bill is one large compute line with no owner and no waste signal.
How do I enable GKE cost allocation?
Enable GKE cost allocation per cluster in the Google Cloud console or with gcloud, and the cluster name and namespace start flowing into the Cloud Billing labels field. Per the GKE cost allocation documentation, this is what lets billing break cluster cost down to the namespace and label level. Enabling it is free. The data is forward looking, so turn it on before you need the history, not the week you start the audit.
How do I set up the dashboard, step by step?
Set up the dashboard by enabling cost allocation, exporting billing to BigQuery, connecting a dashboard layer, then reading request against usage. Five steps:
- Enable GKE cost allocation on each cluster. In the console under the cluster's Features, or with gcloud container clusters update, turn on cost allocation. Result: cluster name and namespace appear in the billing labels going forward.
- Turn on the detailed usage export to BigQuery. In Cloud Billing, enable the detailed usage cost export. Result: a queryable table where GKE cost allocation data is the only place it can be read, per Google's documentation.
- Connect a dashboard layer. Point Looker Studio or Grafana at the BigQuery export and group cost by cluster, namespace, and label. Result: a per team and per app view of spend you can refresh.
- Add request versus usage. Join workload CPU and memory requests against actual usage from metrics. Result: an idle gap column that shows the waste in each namespace.
- Act on the widest gaps first. Rightsize requests, consolidate nodes, and apply Spot and committed use discounts on the worst offenders. Result: the requested total falls toward usage and the bill follows.
How do I read request versus usage?
Read it as a ratio: actual usage divided by requested resources, per namespace and workload. A workload using 40 vCPU of 100 requested is at 40 percent efficiency and is the first thing to fix. Low usage with stable traffic means over requested pods, which you correct by lowering CPU and memory requests until usage sits comfortably under the new request with headroom for peaks. High usage near the request ceiling means the workload is tuned and you should leave it alone or scale it horizontally. The dashboard makes this visible per owner so platform teams can hand each gap to the team that created it.
Want the GKE waste found and fixed, not just charted?
Our Google Cloud cost audit reads your cost allocation and request versus usage data, ranks the namespaces by waste, and rightsizes the worst offenders. On the performance model, you pay only from realized savings. No savings, no fee.
Book a Google Cloud cost audit →What should I do once the gaps are visible?
Once the gaps are visible, work the largest waste lines in order: rightsize over requested pods, then improve bin packing so nodes run dense, then layer Spot and committed use discounts on the steady baseline. The dashboard is the See step; the savings come from the Cut and Lock steps that follow. Set a recurring review so new workloads do not quietly reintroduce the gap, and tie each namespace's efficiency target into the team that owns it. The full GKE and broader GCP tuning sequence lives in our Google Cloud guide.
The Google Cloud Cost Optimization Field Guide includes the cost allocation setup checklist and the request versus usage targets referenced above. It is the downloadable companion to this walkthrough.
Frequently asked questions
Where do I see GKE cost allocation data?
GKE cost allocation data is visible only in the Cloud Billing detailed usage cost export to BigQuery. Once you enable cost allocation on a cluster, the cluster name and namespace appear in the labels field of the billing export, where you can query spend by team and workload. The Cloud Billing reports console also surfaces a GKE cost breakdown by cluster and namespace.
Does enabling GKE cost allocation cost anything?
Enabling GKE cost allocation itself is free. You may incur small BigQuery storage and query charges for the billing export and any dashboards that read it, but those are typically negligible against the Kubernetes spend they help you cut. Confirm current BigQuery rates in the Google Cloud pricing documentation.
What is the difference between requested and used resources in GKE?
Requested resources are the CPU and memory your pods reserve, which is what you pay for on Standard nodes. Used resources are what the pods actually consume. The gap between the two is idle waste, and the GKE cost optimization view exists to make that gap visible so you can rightsize requests to match reality.
Do I need Kubecost to optimize GKE costs?
No. Native GKE cost allocation plus the Cloud Billing BigQuery export and a Looker Studio or Grafana dashboard cover cluster, namespace, and label level visibility without third party tools. Kubecost or OpenCost add deeper per pod and idle cost detail and cross cloud views, which matter once you run chargeback or multiple clusters.
The short version
Enable GKE cost allocation, export billing to BigQuery, surface it in Looker Studio or Grafana, and read request versus usage per namespace. The gap is the waste; rightsize the worst offenders first, then pack and commit. When you want the dashboard read and the savings realized for you, that is what our Google Cloud cost optimization service delivers.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: Google Cloud pricing ↗, Google Cloud documentation ↗ and FinOps Foundation Framework ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.