Kubernetes bills keep climbing faster than anyone budgeted for, and most platform teams still can’t say which namespace, deployment, or team is actually driving the spend. That’s the gap Kubecost was built to close. This tutorial walks through installing Kubecost with Helm, connecting it to real cloud billing data from AWS, Azure, or Google Cloud, reading cost allocation reports, setting budgets and alerts, and hardening the setup for production — 12 steps, start to finish, in roughly 90 minutes, using nothing beyond a working cluster, Helm, and kubectl.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Kubecost Does and Why Kubernetes Cost Visibility Is Broken in 2026
Kubernetes was never designed with a cost ledger attached. A cluster reports CPU requests, memory limits, and node counts, but it has no native concept of “this namespace cost $412 last month.” Kubecost fills that hole by scraping cluster metrics, cross-referencing them against real cloud invoices, and rendering the result as cost-per-namespace, cost-per-deployment, and cost-per-label breakdowns that a FinOps analyst or an engineering lead can actually act on.
The tool sits on top of OpenCost, the CNCF-hosted open source cost allocation engine that Kubecost’s creators donated to the foundation. OpenCost handles the core metering logic; Kubecost wraps it with a full dashboard, budgeting, alerting, multi-cluster federation, and enterprise governance features that the bare open source project doesn’t ship with. Understanding that lineage matters, because it explains why Kubecost can be installed for free and still compete with paid FinOps platforms on functionality.
The urgency behind this tutorial isn’t hypothetical. Industry FinOps trend reports for 2026 flag AI-driven and Kubernetes-driven cost sprawl as the dominant budgeting headache for platform teams this year, and cloud waste figures published earlier in 2026 put unused or misallocated cloud spend at roughly 29% of total bills as AI workloads blow past forecasts. Kubecost is one of the few tools purpose-built to put a dollar figure on that waste inside a cluster rather than just at the account level, which is what AWS Cost Explorer, Azure Cost Management, and Google Cloud Billing do.
That distinction — account-level versus pod-level visibility — is what makes Kubecost worth the extra install step instead of stopping at a native cloud billing dashboard. AWS Cost Explorer can tell you an EKS cluster cost $18,400 last month. It cannot tell you that $6,200 of that came from a single over-provisioned staging deployment that nobody remembered to scale down. Kubecost closes exactly that gap, and it does it using metrics your cluster is already emitting, which is why the install itself is comparatively lightweight next to what it reports back.
Prerequisites: Tools, Versions, and Access You Need First
Before starting the install, confirm you have the following in place. Skipping any of these is the single biggest cause of a stalled Kubecost rollout.
- A running Kubernetes cluster on a supported version — the current Kubecost 3.x Helm chart line targets Kubernetes 1.22 through 1.32. Anything outside that window risks pod scheduling failures.
- Helm 3.x installed locally, with 3.12 or newer recommended if you’ll also deploy the Vertical Pod Autoscaler or KEDA alongside it. Check with
helm version. - kubectl configured and pointed at the target cluster context — verify with
kubectl config current-context. - Cluster-admin or namespace-admin RBAC permissions to create a namespace, install CRDs, and deploy workloads.
- At least 2 vCPU and 4–8 GiB RAM of spare capacity in the cluster for the Kubecost pod and its bundled Prometheus instance — more if you’re running a large cluster with long metric retention.
- A persistent volume provisioner (EBS, Azure Disk, Persistent Disk, or an equivalent CSI driver) so cost history survives pod restarts.
- Cloud billing export access if you want reconciled cloud costs — an AWS Cost and Usage Report (CUR) bucket, an Azure Cost Management export, or a GCP BigQuery billing export table, depending on where the cluster runs.
- A free Kubecost token from kubecost.com if you want the full feature set unlocked; Kubecost will run without one, but with restricted functionality.
Step 1: Confirm Your Cluster Meets Kubecost’s Requirements
Start by checking the Kubernetes server version and confirming you have enough headroom for another workload. Run:
kubectl version --short
kubectl get nodes -o wide
kubectl top nodesIf kubectl top nodes fails, you don’t have a metrics server running yet — install one before continuing, since Kubecost depends on the metrics pipeline to compute utilization-based cost allocation. Confirm Helm is on 3.x with helm version; the current Kubecost chart line is written exclusively for Helm v3 and will not install on Helm 2 setups still lingering in older environments.
Step 2: Add the Kubecost Helm Repository
Kubecost publishes its Helm chart at a GitHub Pages-hosted repository. As of the 3.x chart line, the primary repo moved from the legacy cost-analyzer path to a new kubecost chart repository, though the older repo is still maintained for backward compatibility. Add it and refresh your local index:
helm repo add kubecost https://kubecost.github.io/kubecost/
helm repo update
helm search repo kubecostIf you’re following an older tutorial that references https://kubecost.github.io/cost-analyzer/, that repository still works and installs the cost-analyzer chart rather than the newer kubecost chart — functionally similar, but you should standardize on one so your Helm releases don’t fragment across two chart lineages.
Step 3: Create a Dedicated Kubecost Namespace
Isolate Kubecost in its own namespace so its RBAC scope, resource quotas, and network policies stay separate from application workloads:
kubectl create namespace kubecostYou can skip this manual step if you plan to use --create-namespace on the install command in the next step, which does the same thing inline. Creating it explicitly here just makes it easier to attach resource quotas or labels before the workload lands.
Step 4: Install Kubecost With Helm
With the repo added and the namespace ready, run the base install. This example includes a cluster ID label, which matters the moment you start monitoring more than one cluster from a single Kubecost instance:
helm install kubecost kubecost/kubecost \
--namespace kubecost \
--create-namespace \
--set global.clusterId="production-cluster" \
--set kubecostToken="YOUR_KUBECOST_TOKEN"Leave off kubecostToken entirely if you’re just testing the free tier locally — Kubecost will still install and run, just with a subset of features gated. Watch the rollout with kubectl get pods -n kubecost -w until every pod reports Running. On a small test cluster this typically takes two to four minutes; larger clusters with bundled Prometheus and Thanos sidecars can take longer on first boot while historical metrics backfill.
Step 5: Turn On Persistent Storage and Extend Prometheus Retention
Never run Kubecost in production without persistence — without it, a pod restart wipes historical cost data and every trend chart resets to zero. Upgrade the release with a persistent volume and a longer retention window:
helm upgrade --install kubecost kubecost/kubecost \
--namespace kubecost \
--set kubecostToken="YOUR_KUBECOST_TOKEN" \
--set persistentVolume.enabled=true \
--set persistentVolume.size=64Gi \
--set prometheus.server.retention=90d \
--waitA 64Gi volume with 90 days of retention is a reasonable production baseline for a mid-sized cluster. Scale the volume size up if you’re running a large multi-tenant cluster or want retention closer to a full year for year-over-year budget planning — just remember that longer retention and bigger clusters both drive up the CPU and memory footprint of the bundled Prometheus server, so revisit your resource requests at the same time.
Step 6: Open the Kubecost Dashboard
For a quick look or a lab environment, port-forward the cost-analyzer service directly to your workstation instead of standing up an Ingress:
kubectl port-forward --namespace kubecost deployment/kubecost-cost-analyzer 9090Open http://localhost:9090 in a browser and you should land on the Kubecost overview screen, showing cluster-wide efficiency, monthly cost projection, and a namespace breakdown table. For anything beyond a one-off test, replace the port-forward with a proper Ingress resource behind SSO — the dashboard exposes granular billing data, and leaving it reachable only via a manually run port-forward is not a substitute for real access control once more than one person needs it.
What the Dashboard and CLI Output Actually Look Like
It helps to know what a healthy install actually produces before you’re staring at your own cluster wondering if something’s broken. Right after the pods report Running, checking status with kubectl get pods -n kubecost should show output close to this:
NAME READY STATUS RESTARTS AGE
kubecost-cost-analyzer-6b7f9c8d4f-x2n7q 2/2 Running 0 3m12s
kubecost-prometheus-server-0 2/2 Running 0 3m9s
kubecost-kube-state-metrics-7d9f6b-tqk2m 1/1 Running 0 3m12s
kubecost-network-costs-daemonset-abcde 1/1 Running 0 3m10sThe dashboard’s overview page shows a monthly cost projection, a cluster efficiency percentage, and a ranked namespace table once billing data and a few hours of metrics have accumulated. A typical kubectl cost namespace --window 7d run against a mid-sized cluster looks something like this:
Namespace CPU Cost Memory Cost PV Cost Network Cost Total Cost Efficiency
production $312.40 $198.20 $41.10 $12.80 $564.50 68%
staging $84.10 $52.30 $9.40 $3.10 $148.90 41%
kube-system $28.90 $19.60 $0.00 $1.20 $49.70 N/A
monitoring $22.50 $31.80 $6.90 $0.90 $62.10 57%That efficiency column is the number worth acting on first. In this example, staging costs roughly a quarter of what production costs in absolute dollars, but at 41% efficiency it’s actually the more wasteful namespace relative to what it’s requesting — a classic case of dev/staging environments left running with production-sized resource requests long after a deploy freeze.
Step 7: Connect Your Cloud Bill (AWS CUR, Azure, or GCP BigQuery)
In-cluster metrics alone only get you an estimate. To reconcile Kubecost’s numbers against what your cloud provider actually charges, connect a real billing export. On AWS, that means pointing Kubecost at an AWS Cost and Usage Report exported to S3 and queried through Athena:
helm upgrade kubecost kubecost/kubecost \
--namespace kubecost \
--reuse-values \
--set kubecostProductConfigs.athenaBucketName="s3://your-cur-bucket" \
--set kubecostProductConfigs.athenaRegion="us-east-1" \
--set kubecostProductConfigs.athenaDatabase="athenacurcfn_cur_report" \
--set kubecostProductConfigs.athenaTable="cur_report" \
--set kubecostProductConfigs.projectID="your-aws-account-id"On Azure, Kubecost ingests cost data through an Azure Cost Management export configured against the subscription hosting your AKS cluster. On Google Cloud, it reads a BigQuery billing export table tied to the project running your GKE cluster. Both integrations are configured through the same kubecostProductConfigs Helm value block used above, just with provider-specific keys — check the current chart’s values.yaml for the exact field names before your first upgrade, since they get renamed occasionally between chart versions.
This is also the step where readers coming from AWS-native tooling will notice the overlap with billing dashboards they already use. If you’ve set up AWS Cost Explorer and Budgets at the account level, Kubecost doesn’t replace that — it adds a Kubernetes-aware layer underneath it, breaking the same AWS invoice down by namespace and pod instead of stopping at the service level.
Step 8: Read Cost Allocation by Namespace, Deployment, and Label
With billing data reconciled, the Allocation view becomes the most-used screen in Kubecost day-to-day. It breaks total cluster spend down by namespace, controller, deployment, service, or any Kubernetes label you’ve applied — team, environment, cost-center, whatever your tagging convention already uses. Filter by a date range, group by label, and export the result as CSV for a chargeback report.
The efficiency score shown alongside each allocation is worth paying attention to before you draw conclusions from raw dollar figures. A namespace can look expensive purely because it’s requesting far more CPU and memory than it actually uses — Kubecost’s efficiency percentage exposes that gap directly, so an “expensive” namespace and a “wasteful” namespace aren’t always the same thing. Sort by efficiency, not just by cost, to find the deployments worth rightsizing first.
Step 9: Set Budgets, Alerts, and Act on Savings Recommendations
Under the Savings tab, Kubecost surfaces concrete recommendations: unused persistent volumes, over-provisioned requests, idle nodes, and spot/reserved instance opportunities, each quantified in real dollars using your actual reconciled pricing rather than list price. Business and Enterprise tiers add budget alerts, so you can set a monthly ceiling per namespace or cluster and get notified — via email, Slack, or a webhook — before a runaway workload blows past it.
If you’re already tracking account-level waste with a tool like AWS’s FinOps Agent, treat Kubecost’s savings tab as the Kubernetes-specific complement — it catches the pod-level rightsizing opportunities that an account-wide billing tool has no visibility into, since it never sees inside the cluster.
Step 10: Query Costs From the Terminal With kubectl cost
For engineers who live in the terminal, install the kubectl cost plugin and skip the dashboard entirely for quick checks:
kubectl krew install cost
kubectl cost namespace --window 7d
kubectl cost deployment --namespace production --window 30dThis is especially useful wired into a CI pipeline — run kubectl cost against a staging namespace after a deploy and fail the pipeline, or at least post a Slack warning, if projected monthly cost jumps more than some threshold compared to the previous release. That turns Kubecost from a passive dashboard into an active guardrail.
Step 11: Wire Kubecost Into Prometheus and Grafana
Kubecost either deploys its own bundled Prometheus or, in larger environments, connects to one you already run. If you’re standardizing on an existing observability stack, point Kubecost at your external Prometheus instead of letting it install a second one:
helm upgrade kubecost kubecost/kubecost \
--namespace kubecost \
--reuse-values \
--set global.prometheus.enabled=false \
--set global.prometheus.fqdn="http://prometheus-server.monitoring.svc.cluster.local"Kubecost exposes its own metrics in Prometheus exposition format on the cost-model API, so an external Prometheus can scrape cost data alongside cluster health metrics, and you can build Grafana panels that overlay cost and performance on the same timeline — genuinely useful when you’re trying to prove that a cost spike tracks with a traffic spike rather than a misconfiguration.
Step 12: Harden the Deployment for Production and Plan Upgrades
Before calling the rollout done, run through a short production checklist: confirm persistence is enabled (step 5), put the dashboard behind SSO instead of an open port-forward (step 6), set resource requests and limits on the Kubecost pods themselves so they don’t get evicted under cluster pressure, and enable network policies restricting which namespaces can reach the cost-analyzer API.
For upgrades, always check the release notes for Helm value renames before running helm upgrade — the chart repository move from cost-analyzer to kubecost in the 3.x line is a reminder that the project restructures its Helm values periodically. Run helm get values kubecost -n kubecost before every upgrade to capture your current configuration, and diff it against the new chart’s default values.yaml so nothing silently reverts.
Kubecost vs OpenCost: Which One Should You Actually Run
This is the question every team asks once they realize Kubecost’s engine is open source under a different name. The short answer: OpenCost is the right starting point if you want raw cost metrics exposed as Prometheus data and you’re comfortable building your own Grafana dashboards on top. Kubecost is the right call the moment you need a polished UI non-engineers can read, budget alerts, multi-cluster federation, or governance features like SSO and RBAC that OpenCost doesn’t ship with out of the box.
| Capability | OpenCost (CNCF) | Kubecost Free | Kubecost Business/Enterprise |
|---|---|---|---|
| License cost | Free, always | Free, always | From $449/mo (Business); custom (Enterprise) |
| Metric retention | Depends on your Prometheus | 15-day default | Extended to unlimited |
| Dashboard UI | Minimal, API/Grafana-first | Full web dashboard | Full web dashboard |
| Budget alerts | Not built in | Not included | Included |
| SSO / RBAC / audit logs | Not built in | Not included | Included (Enterprise) |
| Multi-cluster federation | Manual setup | Limited | Included |
| Governance model | Community, CNCF Sandbox | Vendor-supported | SLA-backed (Enterprise) |
Note that these aren’t mutually exclusive. Kubecost is built on OpenCost’s engine, so choosing Kubecost doesn’t mean abandoning the open source project — you’re paying for the layer on top, not a replacement.
Kubecost Helm Chart and Kubernetes Version Compatibility
Chart-to-cluster version mismatches are one of the quieter reasons a Kubecost install fails partway through, since the error messages rarely say “wrong Kubernetes version” directly — they show up as scheduling failures or webhook timeouts instead. Before you install or upgrade, cross-check your cluster’s server version against the chart’s documented support window.
| Kubecost chart line | Minimum Kubernetes | Maximum Kubernetes | Minimum Helm |
|---|---|---|---|
| Kubecost 3.x (current) | 1.22 | 1.32 | 3.12+ |
| cost-analyzer 2.6 | 1.22 | 1.32 | 3.0+ |
| cost-analyzer 2.5 | 1.22 | 1.32 | 3.0+ |
| cost-analyzer 1.x (legacy) | 1.20 | 1.28 | 3.0+ |
If your cluster runs a control-plane version older than 1.22 — increasingly rare in 2026, but still common on long-lived on-prem clusters — you’ll need the legacy 1.x chart line rather than the current release, and you should plan a Kubernetes upgrade before you plan a Kubecost upgrade, not the other way around.
Kubecost Pricing Tiers in 2026
Kubecost, now part of IBM’s Apptio portfolio, keeps a genuinely free tier rather than a time-limited trial, which is worth calling out since a lot of “free” FinOps tooling quietly isn’t. Published 2026 pricing breaks down roughly as follows — always confirm current numbers on Kubecost’s own pricing page, since enterprise quotes are negotiated directly.
| Tier | Price | Cluster size limit | Key features |
|---|---|---|---|
| Free / Foundations | $0, permanent | Up to 250 cores combined | Cost allocation, monitoring, multi-cluster support, basic retention |
| Business | From $449/month | Scales with contract | Budget alerts, advanced savings recommendations, extended retention, email support |
| Enterprise | Custom / reported near $499 per cluster/month | Unlimited | SSO, RBAC, air-gapped deployment, audit logs, SLA support, unlimited retention |
For most teams under 250 combined cores, the free tier is genuinely sufficient to run this entire tutorial in production, not just as a demo. The upgrade trigger for most organizations isn’t cluster size — it’s wanting budget alerts and SSO once more than a handful of engineers depend on the dashboard.
Budget for the upgrade path in advance rather than discovering it mid-negotiation. If your organization is already running multiple clusters that individually sit under the 250-core free-tier ceiling but collectively exceed it once you add multi-cluster federation, IBM’s sales team will price the contract on combined usage, not per-cluster — worth flagging to whoever owns the budget conversation before a Business or Enterprise quote lands as a surprise.
Tracking GPU and AI Workload Costs With Kubecost
GPU nodes are the single fastest-growing line item on most 2026 Kubernetes bills, and they break the assumptions a lot of older cost-monitoring setups were built around. A GPU node often costs five to ten times what a comparable CPU-only node costs per hour, and it’s frequently shared across several pods through node selectors, taints, and tolerations rather than dedicated one-to-one — which means a naive per-pod cost split can badly misattribute spend if it isn’t accounting for actual GPU utilization.
Kubecost allocates GPU node cost the same way it allocates CPU and memory: by reading resource requests and, where available, actual utilization metrics, then splitting the node’s hourly price across the workloads scheduled on it. In practice, that means the Allocation view from step 8 will show a training or inference workload’s GPU cost broken out as its own line, separate from CPU and memory, once you’re running on GPU-backed node pools. Filter by the node label or instance type your cloud provider uses for GPU instances to isolate that spend specifically.
Two practical habits matter here. First, tag GPU-heavy workloads with a distinct label — workload-type: gpu-training or similar — before you scale past one or two experiments, since GPU cost tends to dwarf everything else on the bill and you’ll want to filter it out cleanly from your general Kubernetes cost report rather than have it skew every namespace-level number. Second, watch efficiency on GPU nodes specifically, not just CPU/memory efficiency — a GPU sitting at 20% utilization while fully billed is a far more expensive form of waste than an idle CPU pod, given the per-hour price difference, and it’s exactly the kind of gap that a cluster-metric-only view (without Kubecost) tends to hide entirely.
Common Pitfalls When Installing Kubecost
- Skipping persistence entirely. Teams install Kubecost with defaults, look at cost trends a month later, and find they reset every time the pod restarted. Enable
persistentVolume.enabled=truefrom day one, even in a test environment. - Installing on an unsupported Kubernetes version. The 3.x chart line targets 1.22–1.32. Deploying on a much older or much newer control plane produces cryptic scheduling errors that look like a Kubecost bug but are actually a compatibility gap.
- Mixing the old and new Helm repos. Running
helm upgradeagainstkubecost/kubecostwhen the original install usedkubecost/cost-analyzer(or vice versa) can produce duplicate releases or orphaned resources. Pick one repo and stick with it. - Leaving the dashboard on a bare port-forward in shared environments. It works for a solo test, but it’s not access control, and cost data is more sensitive than teams tend to assume — it reveals team headcount-adjacent spend and project priorities.
- Under-sizing the Kubecost pod itself. A 90-day retention window on a large cluster needs more than the bare 1 vCPU / 2 GiB minimum some quickstart guides show — under-provisioning causes the bundled Prometheus to throttle or OOM-kill under query load.
- Forgetting to configure cloud billing integration. Without it, Kubecost’s numbers are cluster-metric estimates, not reconciled invoice data — useful, but not the number to hand to a CFO without the CUR/Cost Management/BigQuery connection from step 7.
Troubleshooting Kubecost: Fixes for the Errors You’ll Actually Hit
Most Kubecost problems fall into a short list of recurring categories, and almost none of them require filing a support ticket to resolve — the fixes below cover what platform teams run into most often during and after a first install. Work through the relevant one before assuming the tool itself is broken.
- Pods stuck in Pending after install. Almost always a resource or PVC provisioning issue. Run
kubectl describe pod -n kubecostand check events for insufficient CPU/memory or a missing StorageClass. - PVC stuck in Pending state. Confirm your cluster has a default StorageClass with
kubectl get storageclass. If none is marked default, set one explicitly or specifypersistentVolume.storageClassin your Helm values. - Dashboard loads but shows $0 or blank cost data. The metrics pipeline hasn’t backfilled yet — this typically takes several hours after first install as Prometheus accumulates enough scrape history to compute trends. Give it time before assuming it’s broken.
- Cloud costs don’t reconcile with in-cluster estimates. Check the Athena table name, S3 bucket path, and region in your
kubecostProductConfigsvalues — a typo in any of these silently fails the CUR integration while the rest of Kubecost keeps working normally. - Helm install hangs or times out. Usually a webhook or CRD conflict from a previous partial install. Run
helm uninstall kubecost -n kubecostto fully clean up, verify withkubectl get all -n kubecost, then reinstall. - kubectl cost plugin returns “no data”. Confirm the plugin is pointed at the right cluster context and that the Kubecost service is reachable — it queries the cost-analyzer API directly, so a networking or RBAC block will surface here first.
- High memory usage on the Prometheus sidecar. Long retention windows on large clusters are the usual cause. Either shorten retention, increase the pod’s memory limit, or move to an external, already-scaled Prometheus per step 11.
- Upgrade fails with a Helm values schema error. The chart’s value structure changes between major versions. Run
helm get values kubecost -n kubecost -ato see your full current config, then compare it field-by-field against the new chart version’svalues.yamlbefore retrying the upgrade. - Multi-cluster view shows only one cluster. Each cluster needs a unique
global.clusterIdset at install time and a shared token or federated storage backend — a duplicate cluster ID across clusters is the most common cause of this.
Advanced Tips for Running Kubecost at FinOps Scale
Once the base install is stable, a few practices separate a working Kubecost deployment from one that actually changes engineering behavior. First, tag everything consistently at the label level before you scale past a handful of teams — Kubecost’s allocation views are only as useful as the labels applied to workloads, and retrofitting a tagging convention across hundreds of deployments later is far more painful than enforcing it via admission policy from the start.
Second, feed Kubecost’s savings recommendations directly into your existing ticketing system rather than leaving them to sit in a dashboard nobody checks weekly. A scheduled export via the API into Jira, paired with a monthly review, converts “Kubecost said we could save $3,000” into an actual rightsizing PR.
Third, if you’re running clusters across AWS EKS, Azure AKS, and Google GKE simultaneously, use Kubecost’s multi-cluster federation rather than standing up a separate instance per cloud. This is the point where the tool starts doing something a native cloud billing tool structurally can’t: giving you one Kubernetes-native cost view across three different billing systems, comparable to how EKS, AKS, and GKE differ on control-plane pricing but converge under a single Kubecost dashboard.
Finally, pair Kubecost’s pod-level view with account-wide FinOps practice rather than treating them as competing tools. A mature setup uses Kubecost for the “what inside the cluster is expensive” question and a broader FinOps program, along the lines described in recent CFO-level FinOps coverage, to answer the “what should we be spending overall” question.
One more habit worth building early: treat the Kubecost API as a first-class data source, not just a dashboard. Because it exposes cost data as Prometheus-format metrics, you can pull namespace-level cost directly into an existing internal developer platform or a self-service portal, so an engineer opening a new namespace request sees a projected monthly cost estimate before they ever open the Kubecost UI. That’s a small change that tends to do more to curb runaway spend than any dashboard alert, because it puts the number in front of people at the moment they’re making the decision that creates the cost, not a month later when the invoice lands.
A Complete Working Project: Multi-Cluster Cost Dashboard in One Afternoon
Here’s the full sequence assembled into one project you can run end to end against a real or test cluster, combining every step above into a single production-leaning deployment.
# 1. Add the repo and confirm cluster readiness
helm repo add kubecost https://kubecost.github.io/kubecost/
helm repo update
kubectl version --short
# 2. Create the namespace
kubectl create namespace kubecost
# 3. Install with persistence, retention, and a named cluster ID
helm install kubecost kubecost/kubecost \
--namespace kubecost \
--set global.clusterId="prod-us-east-1" \
--set kubecostToken="YOUR_KUBECOST_TOKEN" \
--set persistentVolume.enabled=true \
--set persistentVolume.size=64Gi \
--set prometheus.server.retention=90d \
--wait
# 4. Connect AWS billing data for reconciled cost
helm upgrade kubecost kubecost/kubecost \
--namespace kubecost \
--reuse-values \
--set kubecostProductConfigs.athenaBucketName="s3://your-cur-bucket" \
--set kubecostProductConfigs.athenaRegion="us-east-1" \
--set kubecostProductConfigs.athenaDatabase="athenacurcfn_cur_report" \
--set kubecostProductConfigs.athenaTable="cur_report" \
--set kubecostProductConfigs.projectID="your-aws-account-id"
# 5. Verify pods are healthy
kubectl get pods -n kubecost
# 6. Open the dashboard
kubectl port-forward --namespace kubecost deployment/kubecost-cost-analyzer 9090
# 7. Pull a quick cost report from the terminal
kubectl cost namespace --window 7dRepeat steps 1 through 3 on a second and third cluster with a different global.clusterId value each time, point them at the same federated storage backend or Business/Enterprise license, and you have the multi-cluster FinOps dashboard most platform teams set out to build in the first place — built from free and open source components, upgraded to paid tiers only where budgeting alerts or SSO genuinely justify the added monthly cost.
Frequently Asked Questions
Is Kubecost free to use?
Yes. Kubecost’s Free/Foundations tier is permanent, not a trial, and covers clusters up to roughly 250 combined cores with cost allocation, monitoring, and multi-cluster support. Paid Business and Enterprise tiers add budget alerts, extended retention, SSO, and audit logs.
What’s the difference between Kubecost and OpenCost?
OpenCost is the CNCF-hosted open source cost allocation engine that Kubecost’s creators originally built and later donated to the foundation. Kubecost is the commercial product built on top of that same engine, adding a full dashboard, budgeting, alerting, and enterprise governance features that OpenCost doesn’t include by default.
Does Kubecost work with AWS EKS, Azure AKS, and Google GKE?
Yes, on all three. It connects to AWS Cost and Usage Reports via S3/Athena, Azure Cost Management exports, and GCP BigQuery billing export tables to reconcile in-cluster metrics against each provider’s actual invoice.
How much Kubernetes resource overhead does Kubecost add?
A practical baseline is 1–2 vCPU and 4–8 GiB RAM for the main Kubecost pod, scaling up for larger clusters or longer Prometheus retention windows. Enabling persistence and extending retention past the default increases CPU and memory usage further.
Which Kubernetes versions does Kubecost support?
The current 3.x Helm chart line targets Kubernetes 1.22 through 1.32. Always check the chart’s compatibility matrix before installing on a cluster running a much older or newer control plane.
Can I run Kubecost without a license token?
Yes, but functionality is restricted. Getting a free token from kubecost.com and passing it via the kubecostToken Helm value unlocks the full free-tier feature set at no cost.
Why does my Kubecost dashboard show no cost data right after install?
The metrics pipeline needs time to backfill — usually several hours after first install as Prometheus accumulates enough scrape history to compute trends and cost projections. This is expected behavior, not a broken install.
Does Kubecost replace AWS Cost Explorer or Azure Cost Management?
No. Those tools report account-level and service-level cloud spend; Kubecost adds a Kubernetes-native layer underneath, breaking the same cloud invoice down by namespace, deployment, and label. Most teams run both together rather than choosing one over the other.
Does Kubecost track GPU costs for AI and ML workloads?
Yes. Kubecost allocates GPU-backed node costs to individual workloads using resource requests and available utilization metrics, the same allocation model it uses for CPU and memory, breaking GPU spend out as its own line in the Allocation view once GPU node pools are in the cluster.
Related Coverage
- How to Set Up AWS Cost Explorer & Budgets: 12 Steps, 90 Min [2026]
- AWS FinOps Agent Launches Free in $16.5B Market [2026]
- Cloud Waste Hits 29% as AI Spend Breaks Budgets [2026]
- Kubernetes on AWS EKS Setup: 12 Steps, 100 Min [2026]
- EKS vs AKS vs GKE: $73/mo vs Free Control Plane [2026]
- FinOps in 2026: How CFOs Are Finally Taming Runaway Cloud Costs
- How to Deploy Applications with Kubernetes and Helm: Complete Tutorial (2026)
