> For the complete documentation index, see [llms.txt](https://docs.onelens.cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.onelens.cloud/integrations/kubernetes/enable-cost-allocation-for-gke.md).

# Enable Cost Allocation for GKE

To view pod-level GKE costs in OneLens, you need to enable **GKE cost allocation** on each cluster and make sure your Cloud Billing data reaches OneLens through the **detailed BigQuery export**:

1. **GKE cost allocation**: a per-cluster flag that stamps Kubernetes identity (cluster, namespace, workload, pod labels) onto your billing rows.
2. **Detailed Cloud Billing export to BigQuery**: the only export that carries these labels. The *standard* export does not.

GKE cost allocation is **off by default and set per cluster**. Every cluster you want split must be enabled individually.

{% hint style="warning" %}
**There is no backfill.** Labels only exist on usage generated *after* enablement, so any period before that date is permanently un-splittable. Enable this early.
{% endhint %}

## Step-by-Step Guide

{% stepper %}
{% step %}

### Enable GKE Cost Allocation

Enable it per cluster using any of the following.

**gcloud CLI:**

```bash
gcloud container clusters update CLUSTER_NAME \
  --enable-cost-allocation
```

**Google Cloud Console:**

1. Go to **Kubernetes Engine → Clusters** and click the cluster name to open its details page.
2. On the **Details** tab, scroll to the **Features** section and click the edit (pencil) icon next to **Cost allocation**.
3. Tick **Enable GKE cost allocation**, then **Save changes**.

{% hint style="info" %}
Enabling causes no node recreation, restart, or disruption. It is a control-plane metadata flag.
{% endhint %}
{% endstep %}

{% step %}

### Ensure the Detailed BigQuery Billing Export Is Configured

The Kubernetes labels are written **only** to the Cloud Billing **detailed** usage cost export. If you are on the *standard* export, the labels will appear to be missing.

1. In the Cloud Console, go to **Billing → Billing export → BigQuery export**.
2. Confirm **Detailed usage cost** is enabled and pointed at a BigQuery dataset.
3. Verify the export table name contains the `_resource_` infix, e.g.:

   `PROJECT.DATASET.gcp_billing_export_resource_v1_XXXXXX_XXXXXX_XXXXXX`

This is the same detailed export OneLens ingests, so no additional OneLens configuration is required once cost allocation is on.
{% endstep %}

{% step %}

### Verify Cost Allocation Is Active

**gcloud CLI:**

```bash
gcloud container clusters describe CLUSTER_NAME \
  --region REGION \
  --format="value(costManagementConfig.enabled)"
```

Expect `True`.

**Console:** the state shows next to **Cost allocation** in the cluster's **Features** list.
{% endstep %}
{% endstepper %}

## What OneLens Uses

Once enabled, GKE adds these Google-generated keys to the `labels` array of each billing row. OneLens reads them to attribute cluster spend below the node:

| Label key               | Value                     | Purpose                                                                               |
| ----------------------- | ------------------------- | ------------------------------------------------------------------------------------- |
| `goog-k8s-cluster-name` | Cluster name              | Attribute costs by cluster (pair with project ID, since names aren't globally unique) |
| `k8s-namespace`         | Namespace                 | Split costs by namespace                                                              |
| `k8s-workload-name`     | Workload name             | Attribute to a specific workload                                                      |
| `k8s-workload-type`     | e.g. `apps/v1-Deployment` | Identify the controller (fully-qualified `apiVersion-Kind`)                           |
| `k8s-label/${key}`      | Pod label value           | Your own pod labels (team, env, service) propagate to billing                         |

## Notes & Limitations

* **Request-based allocation:** costs reflect resource *requests*, not consumption. A pod requesting 4 vCPU and using 0.1 is charged for 4.
* **Up to 3 days latency** before data appears in Cloud Billing after enabling.
* **Standard clusters** are the documented/tested target. On Autopilot the flag can be set but unsupported resources won't accrue (expect `goog-k8s-unsupported-sku` / `goog-k8s-unknown` / blanks).
* **Supported SKUs:** vCPU, RAM, GPU, Persistent Disks, Cloud TPU v4+. A4/A4X instances and externally-managed nodes are not tracked.
* **Persistent Disks** are attributed only when dynamically provisioned (PVC/ephemeral), access mode RWO/RWOP, and alive for at least 30 minutes.
* **Shared-CUD costs** may land in `goog-k8s-unsupported-sku` instead of a real namespace.
* **50-label cap:** pods with more than 50 Kubernetes labels surface none in billing.
* **BigQuery cost:** enabling increases label/namespace cardinality, modestly raising BigQuery storage and query costs.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.onelens.cloud/integrations/kubernetes/enable-cost-allocation-for-gke.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.