Kubernetes cost allocation splits node, disk, load-balancer and idle capacity onto namespaces or workloads. The invoice only shows the node pool and a few add-ons, so you need in-cluster measurement plus a billing export. On Google Kubernetes Engine, enable GKE cost allocation so Cloud Billing labels include cluster name and namespace. On Amazon EKS, AWS documents Kubecost for cost monitoring. On Azure Kubernetes Service, use Azure Cost Management plus cluster labels and, if you run it, Kubecost. Shared clusters without requests and limits will leave a large unallocated remainder. Documentation dated 2026-08-30 is the product source.
The worksheet on this site is the Kubernetes cost allocation calculator. A spend jump on the cluster is Kubernetes cluster cost increase.
Assumptions
- You operate EKS, AKS or GKE and can read the cluster plus the billing export.
- In-cluster measurement (GKE cost allocation, AKS cost analysis, Kubecost or OpenCost) is available or you can enable it.
- Shared clusters without CPU and memory requests will leave an unallocated remainder. That is a finding, not a rounding error.
- The work is attributing spend. Kubernetes versus functions is a separate comparison.
What the cloud bill can see
The provider bills:
- Worker nodes (EC2, Virtual Machine Scale Sets, GCE)
- Control plane hours on EKS, AKS and GKE (product-specific)
- Persistent volumes, load balancers, NAT, egress
- Add-ons you enabled (cluster autoscaler is usually free; a service mesh is not)
It cannot see that namespace/payments used 30% of a node’s CPU unless you export in-cluster usage and join it to the node SKU price. That join is cost allocation. The FinOps Framework calls this allocation. It is not the same as a discount.
Idle capacity is a first-class line. If you size the node pool for a peak and run at 20% CPU, someone pays for the idle. Either charge it to a platform cost center or keep shrinking the pool.
GKE: turn on cost allocation, then query billing
GKE cost allocation writes cluster and namespace into the Cloud Billing export. Google documents that enabling it does not backfill older days.
gcloud container clusters describe prod-gke \
--region=asia-southeast1 \
--format='value(costManagementConfig.enabled)'
gcloud container clusters update prod-gke \
--region=asia-southeast1 \
--enable-cost-allocation
costManagementConfig.enabled of True means new usage should carry labels such as goog-k8s-cluster-name and k8s-namespace in the BigQuery export. False means you still only see node SKUs. After you enable it, wait for the next export tables. A query that finds no k8s-namespace on day one is expected.
GKE also documents extra BigQuery storage and query cost as label cardinality grows. High-cardinality pod labels will hurt you.
EKS: Kubecost as documented by AWS
AWS documents installing Kubecost on Amazon EKS for in-cluster cost monitoring, including an AWS-distro path. Kubecost reads Kubernetes usage and your AWS price or CUR data. It does not replace the Cost and Usage Report. It attributes the report.
Confirm the cluster can reach the cost API and that node labels match instance families you actually run (Graviton versus x86 changes the hourly rate). If Kubecost shows $0 on nodes, the pricing source is wrong, not the scheduler.
kubectl get deploy -n kubecost
kubectl -n kubecost get svc cost-analyzer
A missing cost-analyzer Service means the install never finished. A running Service with empty allocation usually means AWS credentials for CUR or Spot data are absent.
AKS: Cost Management and OpenCost
Microsoft documents AKS cost analysis as an add-on built on OpenCost (CNCF Incubating). Usage is reconciled with the Azure invoice and shown in Cost Management under Kubernetes cluster and namespace views. The cluster must be Standard or Premium, not Free. Microsoft documents up to 24 hours before data appears, and Kubernetes views only for Enterprise Agreement and Microsoft Customer Agreement offers.
az aks show --name CLUSTER --resource-group RG --query sku.tier -o tsv
Free means the add-on is not available. Do not upgrade the tier only to see namespace cost unless you accept the published Standard or Premium control-plane fee. Microsoft documents --enable-cost-analysis on az aks update for an existing Standard or Premium cluster.
Tag the AKS node resource group and the cluster with the same cost-center and environment keys you use in cloud tagging and cost allocation. Azure Cost Management can roll those tags if you enable tag inheritance. If cost analysis is off, namespaces still need OpenCost or Kubecost you run yourself, or you stop at the node pool and the MC_... resource group.
Shared-cluster rules that apply everywhere
Require CPU and memory requests on every namespace that you intend to charge. Allocation tools split node cost by request, usage or a blend. If requests are zero, that namespace looks cheap and the idle bucket looks huge.
Prefer one production cluster per compliance boundary, not one cluster for the whole company, unless you have NetworkPolicy, quota and a platform team that will run allocation as a product.
Interpret a monthly allocation table
A healthy shared cluster looks like this in spirit: namespace shares sum to less than 100%, idle is explicit, system namespaces (kube-system, gke-managed-*, amazon-guardduty) are a platform line. A table that allocates 100% of node cost to user namespaces and hides idle is lying about efficiency.
DaemonSets (logs, security agents) belong to platform cost. Charge them back as a tax or keep them in the platform center. Do not invent a per-app share of the DaemonSet unless finance asked for that precision.
Risks and limitations
GKE cost allocation, AKS cost analysis and Kubecost disagree on idle and on how they treat GPU or Windows node pools. Pick one system of record for chargeback.
Spot, committed use and Savings Plans change the effective node rate. If you allocate with on-demand list price, product teams will dispute the number. Feed CUR or billed rates.
Control-plane hours and NAT sit outside namespace math. Allocate them by cluster owner, not by pod CPU.
Kubernetes versus functions is a different decision: Kubernetes vs serverless. Terms are in the cloud glossary.