A Kubernetes bill arrives as one number. It doesn’t say which namespace burned through the budget, which team’s staging environment never got shut down, or why a single deployment quietly doubled its memory footprint last month. That gap between “here’s what we spent” and “here’s who spent it” is exactly what Kubecost was built to close, and it’s why the tool now shows up in search volume alongside terms like FinOps and cloud cost optimization.
This tutorial installs Kubecost on a live cluster with Helm, connects it to real cloud billing data instead of list-price estimates, and walks through reading a first cost allocation report. It also covers OpenCost, the open-source project Kubecost is built on, as a lighter-weight standalone option, plus the pitfalls, troubleshooting steps, and production-hardening details most quick-start guides skip. Expect to spend about 60 minutes end to end, longer if you’re also standing up a test cluster.
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 Is Kubecost, and Why Kubernetes Costs Are So Hard to Track
Kubernetes packs workloads from many teams onto shared nodes by design. That’s what makes it efficient, and it’s exactly what makes a cloud invoice useless for cost attribution. A single node might run pods from four different teams at once, so the bill for that node can’t be split fairly without knowing what actually ran on it, for how long, and at what resource level. Kubecost reads your cluster’s real resource usage, cross-references it against actual cloud pricing, and breaks the total down by namespace, deployment, label, team, or any dimension you define.
The company behind Kubecost is now part of IBM, folded into IBM’s Apptio FinOps product line, and current documentation is published under IBM’s own docs site as “IBM Kubecost.” Despite the change in ownership, the open-source engine the product is built on, a project called OpenCost, stays free and vendor-neutral. Real companies run this in production: a 2026 breakdown from FinOps platform Finout lists Audi, GitLab, and Rakuten among the enterprises using Kubecost for spend visibility across EKS, GKE, and AKS clusters.
The product keeps expanding past basic cost reporting too. Recent release notes describe GPU efficiency and savings insights for teams running expensive GPU node pools for AI workloads, plus expanded “Collections” controls for grouping and governing spend across multiple teams. Kubecost’s current major release line, referred to as Kubecost 3.0 in AWS’s own documentation and in the product’s release videos, also changed the underlying architecture: it eliminates the hard dependency on Prometheus that earlier versions required, replacing it with a unified agent and a ClickHouse-backed storage layer.
None of this exists in a vacuum. FinOps practitioners generally treat a handful of moves as standard practice once a team gets serious about Kubernetes spend: right-sizing requests and limits, running non-critical workloads on spot or preemptible capacity, and building namespace-level chargeback so cost stops being an abstract line item on someone else’s budget. Cluster autoscaling on its own doesn’t cover any of that. An autoscaler shrinks and grows node count in response to scheduling pressure, but it has no opinion on whether a workload’s requests were sensible in the first place, and it can’t tell you which team should own a spike in spend. Cost visibility tooling like Kubecost is what turns “the bill went up” into “here’s exactly why, and here’s who to talk to about it.”
That’s also why a monthly spend baseline matters before you touch anything else. Teams that jump straight to right-sizing or spot migration without first capturing a clean baseline usually can’t tell afterward whether a change actually helped or whether spend moved for an unrelated reason, like a traffic spike or a new feature launch. The steps below build that baseline first, then layer optimization on top of it.
Kubecost vs. OpenCost: How the Two Projects Fit Together
These two names get used almost interchangeably in search results, but they’re not the same thing, and mixing them up is the single most common source of confusion when people start looking at Kubernetes cost tooling. OpenCost is the free, open-source cost allocation engine. It’s an Incubating project under the Cloud Native Computing Foundation, originally created by the Kubecost team and now maintained, according to a CNCF blog post published in January 2026, by IBM Kubecost, infrastructure firm Randoli, and a wider group of partners and contributors. OpenCost measures real-time cost and resource allocation for Kubernetes workloads and cloud costs, and it’s the calculation core that sits underneath the commercial Kubecost product.
Kubecost, the commercial product now owned by IBM, wraps that OpenCost engine with a full dashboard, multi-cluster aggregation, historical data retention, request-sizing recommendations, budget governance, and enterprise integrations. Amazon even ships an “EKS-optimized Kubecost bundle” at no additional cost through its own EKS cost-monitoring documentation, and that bundle is explicitly exempted from a spend cap that Kubecost introduced for everyone else on its free tier.
| Detail | OpenCost | Kubecost |
|---|---|---|
| License / cost | Free, open source (Apache 2.0) | Free tier, plus paid Enterprise tiers |
| Governance | CNCF Incubating project | Commercial product, owned by IBM |
| Free-tier limit | None — fully open source | $100,000/month spend cap on the v3 free tier (AWS EKS-optimized bundle is exempt) |
| UI | Basic UI plus API/metrics endpoint | Full dashboard: allocation views, reports, alerts |
| Multi-cluster view | Per-cluster, manual aggregation | Built-in multi-cluster federation |
| Cloud billing integration | Manual configuration | Guided AWS/Azure/GCP billing integrations |
| Best for | Teams that want raw metrics and full control | Teams that want a ready dashboard and chargeback reporting |
Most teams starting from zero install Kubecost first, since it includes OpenCost’s engine internally and gives you a working dashboard immediately. Teams that already run a metrics stack and just want the raw allocation numbers to pipe into their own Grafana boards often install OpenCost standalone instead. This tutorial covers both, starting with Kubecost.
Prerequisites: What You Need Before You Start
Gather these before Step 1. None of them are unusual if you’re already running workloads on Kubernetes, but missing any one of them is the most common reason a Helm install stalls out.
- A running Kubernetes cluster: EKS, AKS, GKE, or self-managed. OpenCost’s own project documentation states it installs on any Kubernetes 1.20 or newer cluster, and that floor is a safe baseline for Kubecost too since it’s built on the same engine.
- Helm 3.x installed locally. Kubecost and OpenCost both ship as Helm charts, and this tutorial doesn’t touch Helm 2.
kubectlconfigured and pointed at the right cluster context, with permissions to create namespaces and install workloads (cluster-admin works, but see the production-hardening step below for a scoped alternative).- Cluster capacity to spare. Kubecost’s own components need dedicated headroom, so don’t install it onto a cluster that’s already scheduled to the edge of its capacity.
- If you want real dollar figures instead of list-price estimates: admin access to your cloud billing exports (AWS Cost and Usage Report, Azure Cost Management export, or GCP BigQuery billing export).
- About 60 minutes. Installation itself takes minutes, but cost data needs time to reconcile before the dashboard becomes genuinely useful.
Quick Reference: Helm Charts, Namespaces, and Ports
Search results and older blog posts mix up chart names and repository URLs across Kubecost’s version history, which wastes time when a copied command silently installs the wrong line. Bookmark this table before starting the install steps below.
| Component | Helm repo URL | Chart name | Default namespace | Default UI port | Requires Prometheus? |
|---|---|---|---|---|---|
| Kubecost (current, v3 line) | https://kubecost.github.io/kubecost/ | kubecost | kubecost | 9090 | No — unified agent + ClickHouse |
| Kubecost (legacy v1/v2) | https://kubecost.github.io/cost-analyzer/ | cost-analyzer | kubecost | 9090 | Yes |
| OpenCost (standalone) | https://opencost.github.io/opencost-helm-chart | opencost | opencost | 9090 (UI) / 9003 (API) | Yes |
Step 1-3: Confirm Access, Install Helm, and Add the Kubecost Repository
Step 1. Confirm your cluster context is correct and that you have working access before installing anything. Running the wrong install against the wrong cluster is an easy mistake when you manage more than one.
kubectl cluster-info
kubectl get nodes -o wide
kubectl auth can-i create namespacesStep 2. Confirm Helm 3 is installed. If helm version returns a v2 client, upgrade first, since the Kubecost and OpenCost charts both target Helm 3 syntax.
helm version --shortStep 3. Add the official Kubecost Helm repository and refresh your local chart index.
helm repo add kubecost https://kubecost.github.io/kubecost/
helm repo updateIf you’re following an older guide that references the cost-analyzer chart at https://kubecost.github.io/cost-analyzer/, that’s not wrong, it’s the repository path for Kubecost’s v1 and v2 lines. This tutorial uses the current kubecost chart, which is the v3 line referenced in Kubecost’s own current documentation.
Step 4-5: Install Kubecost and Open the Dashboard
Step 4. Install the chart into its own namespace, and set a clusterId so you can tell this cluster apart from others later if you add more.
helm install kubecost kubecost/kubecost \
--namespace kubecost --create-namespace \
--set global.clusterId=production-cluster-01Give it a few minutes, then check that everything came up healthy before moving on.
kubectl get pods -n kubecost
kubectl get deploy -n kubecostStep 5. Open the dashboard with a port-forward. Kubecost’s own install instructions, published by Apptio, use this exact command, and the UI listens on port 9090.
kubectl port-forward --namespace kubecost deployment/kubecost-cost-analyzer 9090Visit http://localhost:9090 in a browser. Don’t expect a fully populated dashboard immediately. Cost allocation needs at least one reconciliation cycle to run before the numbers settle, so if a namespace shows “N/A” or a chart looks sparse right after install, that’s expected, not broken.
Step 6: Connect Real Cloud Billing Data From AWS, Azure, or GCP
Out of the box, Kubecost and OpenCost both estimate cost using public list pricing for your node types. That’s useful for relative comparisons between namespaces, but it won’t match your actual invoice if you’re running committed-use discounts, reserved instances, or negotiated enterprise pricing. Connecting your real billing export fixes that.
For AWS, that means pointing Kubecost at a Cost and Usage Report (CUR) exported to an S3 bucket. AWS’s own EKS documentation walks through setting this up alongside the managed Kubecost bundle. A simplified version of the integration lives in your Helm values:
# values-aws-billing.yaml
kubecostProductConfigs:
athenaProjectID: "123456789012"
athenaBucketName: "s3://your-cur-report-bucket"
athenaRegion: "us-east-1"
athenaDatabase: "athenacurcfn_your_report"
athenaTable: "your_cur_table"
masterPayerARN: ""
serviceKeyName: ""
serviceKeySecret: ""helm upgrade kubecost kubecost/kubecost \
--namespace kubecost \
-f values-aws-billing.yamlAzure and GCP follow the same pattern with different source data: an Azure Cost Management export for AKS clusters, or a BigQuery billing export for GKE clusters, each configured through their own block in the same kubecostProductConfigs section. The exact field names differ by cloud, so check the current values schema for your chart version before copying an old blog post’s field names verbatim, since these have changed across Kubecost’s major versions.
On AKS, that means enabling a Cost Management export scoped to the subscription or resource group your cluster lives in, then pointing Kubecost’s configuration at the storage account the export lands in. On GKE, Google’s billing export writes daily usage and cost detail directly into a BigQuery dataset, and Kubecost queries that dataset instead of an object-storage export. In both cases the integration is a one-time setup: once the export exists and Kubecost can read it, every subsequent number in the dashboard reflects your negotiated rates automatically, with no manual re-entry needed as pricing changes.
Skipping this step is the single biggest reason teams lose trust in a cost dashboard within the first month. List-price estimates can be off by a wide margin once committed-use discounts or reserved capacity are in play, and a finance stakeholder who catches that mismatch once tends to stop trusting every other number on the page too, even the ones that were accurate.
Step 7: Read Your First Cost Allocation Report
Open the Allocation view in the dashboard and filter by namespace first. This is usually the fastest way to spot an obvious problem, like a forgotten staging namespace running at production scale, or a batch job namespace with no idle time at all.
Three numbers matter more than the headline total. Idle cost is capacity you’re paying for but not scheduling anything onto, usually a sign of oversized nodes or overly conservative autoscaling floors. Shared cost is cluster overhead, things like the ingress controller or a shared logging stack, that Kubecost splits proportionally across every namespace using it. And efficiency, sometimes shown as a percentage, compares what a workload actually used against what it requested, which is the number that feeds directly into right-sizing later in this tutorial.
If you’re running GPU node pools for AI or ML workloads, check the GPU insights view too. Kubecost’s product updates through 2025 specifically added GPU efficiency and savings tracking, since GPU and high-memory nodes are disproportionately expensive relative to standard compute, and they’re also disproportionately easy to leave idle after a training job finishes.
Step 8: Set Up Namespace Chargeback and Showback Reports
Showback and chargeback solve two different problems, and it’s worth being precise about which one you’re building. Showback means a team can see what their namespace costs, with no money actually moving between budgets. Chargeback means that cost gets formally billed back to a team’s or product’s budget line. Most organizations start with showback, since it changes behavior without requiring finance to rebuild internal billing processes.
Kubecost’s “Collections” feature, expanded in recent releases, groups namespaces, labels, or clusters into a single reporting unit, which matters once you have more than a handful of teams sharing a cluster. Rather than reading ten separate namespace rows, a platform team can define a Collection per business unit and hand each one a single number.
To make either report accurate, make sure every workload is labeled consistently first, typically with a team or cost-center label applied at the namespace or deployment level. Kubecost allocates by whatever labels actually exist on your resources, so an unlabeled namespace shows up as an unattributed cost, which is usually the first thing a report reviewer will ask about.
kubectl label namespace checkout-service team=payments cost-center=CC-4021
kubectl label namespace search-service team=platform cost-center=CC-1090Step 9: Turn On Right-Sizing and Request Recommendations
This is where cost monitoring turns into cost reduction. Kubernetes schedules pods based on what they request, not what they actually use, so a workload requesting 2 CPU cores while consistently using 300 millicores forces the scheduler to reserve capacity that never gets touched. Multiply that gap across dozens of deployments and it becomes the single biggest lever most teams have.
Kubecost’s recommendation view compares actual historical usage against configured resource requests and limits and suggests tighter values per container. Treat the first set of recommendations as a starting point, not a mandate. Apply them to non-critical workloads first, watch for a week, then move to anything customer-facing once you trust the pattern.
resources:
requests:
cpu: "300m"
memory: "256Mi"
limits:
cpu: "750m"
memory: "512Mi"This is also where combining Kubecost with an autoscaler like Karpenter pays off, since right-sized requests only save money if the cluster can actually shrink node count in response. If you haven’t compared autoscaler options yet, see our Karpenter vs. Cluster Autoscaler vs. KEDA comparison for how the major options behave under real scale-down pressure.
Why Spot Capacity and Autoscaling Alone Don’t Fix the Bill
Spot and preemptible instances remain one of the most searched cost-saving tactics for Kubernetes, and for good reason: fault-tolerant workloads can run on that capacity at a steep discount to on-demand pricing. But moving workloads to spot capacity without cost visibility just changes where the waste hides. An overprovisioned pod running on a spot node still wastes the same proportion of its reserved capacity, it’s just wasting a cheaper number.
Kubecost’s allocation view separates on-demand spend from spot or preemptible spend by node type, so you can see both the discount you’re capturing and the efficiency of what’s actually running there. That combination matters more than either number alone. A namespace running entirely on spot capacity but at 20% efficiency is still leaving money on the table, and a dashboard that only reports the discount would miss it entirely.
The practical order of operations most platform teams settle on: get cost visibility first, right-size requests second, migrate eligible workloads to spot or preemptible capacity third, and only then lean on autoscaling to translate the smaller footprint into fewer nodes. Doing it in the reverse order, autoscaling and spot migration before visibility, tends to produce a lower bill with no clear explanation of why, which makes the next optimization pass a guessing game instead of a data-driven one.
Step 10: Configure Budget Alerts and Governance Policies
Dashboards only help if someone looks at them. Alerts close that gap by pushing a notification the moment spend crosses a threshold, rather than waiting for someone to open the UI at the end of the month. Kubecost supports budget alerts scoped to a cluster, namespace, or Collection, delivered through Slack, email, or a generic webhook.
kubecostProductConfigs:
alertConfigs:
- type: "budget"
threshold: 5000
window: "monthly"
aggregation: "namespace"
filter: "namespace:\"checkout-service\""
slackWebhookUrl: "https://hooks.slack.com/services/YOUR/WEBHOOK/URL"Governance goes a step further than alerting: it’s policy that blocks or flags spend before it happens, rather than reporting on it after the invoice lands. The FinOps Foundation’s framework treats this as an operational discipline rather than a one-time cleanup, and that framing matters here too. A budget alert that fires every month without anyone changing behavior isn’t governance, it’s just noise with a Slack integration attached.
Step 11: Installing OpenCost Standalone as a Lighter-Weight Alternative
If you already run a Prometheus and Grafana stack and just want raw cost allocation metrics to query yourself, skipping straight to OpenCost avoids installing a UI you won’t use. It’s the same underlying engine, free, and maintained as a CNCF Incubating project. The official OpenCost GitHub repository documents it as installable on any Kubernetes 1.20 or newer cluster.
helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm repo update
helm install opencost opencost/opencost \
--namespace opencost --create-namespaceOpenCost’s UI listens on port 9090, matching Kubecost’s own dashboard port, and its documentation examples forward the cost-model API on port 9003. Unlike Kubecost’s current v3 line, standalone OpenCost still requires Prometheus for scraping and storing the underlying metrics, so install or point it at an existing Prometheus deployment before expecting data to show up.
kubectl port-forward --namespace opencost service/opencost 9090:9090 9003:9003Query the raw allocation API directly once it’s running, which is the whole point of choosing OpenCost over the full Kubecost dashboard:
curl "http://localhost:9003/allocation/compute?window=1d&aggregate=namespace"Step 12: Hardening the Install for Production
A quick-start install is fine for evaluation. Before this runs against a production cluster long-term, tighten three things. First, replace cluster-admin access with a scoped ClusterRole that only grants the read permissions Kubecost actually needs to inspect pods, nodes, and metrics, rather than the broad access a default install often requests. Second, attach persistent storage to whichever component holds historical data, since losing that on a pod restart means losing your cost history along with it. Third, if you’re running more than one cluster, look at Kubecost’s multi-cluster federation rather than checking dashboards separately for each cluster, since a per-cluster view makes it easy to miss that the real waste is duplicated environments across clusters rather than waste inside any single one.
It’s also worth revisiting resource requests for Kubecost’s own components once real usage data exists. The same right-sizing discipline you’re applying to everything else should apply to the tool itself.
helm upgrade kubecost kubecost/kubecost \
--namespace kubecost \
--set kubecostModel.resources.requests.cpu=200m \
--set kubecostModel.resources.requests.memory=512MiCommon Pitfalls When Rolling Out Kubernetes Cost Monitoring
Most failed rollouts trace back to one of these, and all of them show up after the install technically “worked,” which is what makes them easy to miss during a quick evaluation.
- Skipping the billing integration. Without a connected CUR, Cost Management export, or BigQuery export, every dollar figure is a list-price estimate. Fine for relative comparisons between namespaces, misleading if you report it to finance as an actual figure.
- Forgetting the free-tier spend cap. Kubecost’s v3 free tier introduced a $100,000 monthly spend limit. Clusters that grow past that threshold need to move to a paid tier, and finding that out mid-incident is worse than planning for it.
- Leaving workloads unlabeled. Chargeback and showback are only as good as your labels. An unlabeled namespace becomes an “unattributed” line item that undermines trust in the whole report.
- Installing on underprovisioned clusters. Kubecost’s own components need dedicated headroom. Installing it onto a cluster already scheduled to the edge just adds another workload competing for the same scarce resources you’re trying to optimize.
- Confusing OpenCost’s raw numbers with Kubecost’s reconciled ones. OpenCost exposes near-real-time allocation data, while Kubecost applies additional reconciliation and shared-cost logic on top. Comparing the two directly without accounting for that difference produces numbers that look like they disagree when they’re actually measuring slightly different things.
- Granting cluster-admin by default. It’s the fastest path through a quick-start guide, and the wrong default for anything running longer than a demo.
- Treating right-sizing as a one-time task. Usage patterns shift as traffic and code change. A request value that was correct three months ago is a guess today unless recommendations get revisited on a schedule.
None of these are exotic failure modes. They’re the same handful of oversights that show up in most infrastructure rollouts: skipping the integration step that doesn’t feel urgent on day one, granting broad access because it’s faster, and treating a new dashboard as a finished project instead of the start of an ongoing process. Catching them early is mostly a matter of knowing to look, which is the point of listing them here before you hit them yourself.
Troubleshooting Kubecost and OpenCost: Common Errors and Fixes
Reference this table before opening a support ticket. Most installation problems fall into a handful of repeatable categories, and working through them in order, capacity issues first, then configuration, then data-accuracy questions, resolves the majority of first-week support requests without needing to file anything at all.
| Symptom | Likely cause | Fix |
|---|---|---|
| Dashboard loads but shows blank or “N/A” cost graphs | Cost data hasn’t reconciled yet | Wait for at least one full reconciliation cycle before assuming the install failed |
Pods stuck in Pending | Insufficient cluster capacity for Kubecost’s own components | Free up node capacity or scale the node group before retrying |
| Costs show as $0 or “N/A” for cloud resources | No cloud billing integration configured | Connect a CUR (AWS), Cost Management export (Azure), or BigQuery billing export (GCP) |
| Can’t reach the dashboard after port-forwarding | Wrong deployment name or namespace in the command | Confirm with kubectl get deploy -n kubecost before retrying the port-forward |
| Helm install hangs or times out | A conflicting webhook or admission controller from a previous partial install | Run helm uninstall fully, confirm no leftover webhook configs remain, then reinstall |
| Duplicate or inflated cost entries after a reinstall | Old PVCs or secrets weren’t removed before reinstalling | Manually delete leftover PVCs in the namespace, then reinstall clean |
| Namespace showback totals don’t match finance’s cloud invoice | Shared or idle costs aren’t allocated to the right owner | Configure shared-cost allocation rules so overhead splits across the namespaces using it |
| OpenCost API returns empty results | Prometheus isn’t scraping OpenCost’s metrics endpoint | Verify the Prometheus scrape config includes the OpenCost service before querying the API |
| Right-sizing recommendations look extreme (near-zero requests) | Recommendation window is too short or covers an atypical low-traffic period | Extend the lookback window before trusting a recommendation for customer-facing workloads |
| Kubecost pods themselves show a high resource cost | Default resource requests are oversized for a small cluster | Right-size Kubecost’s own requests values the same way you would any other workload |
Advanced Tips for Scaling Cost Visibility Across Multiple Clusters
Once a single cluster is under control, the same questions repeat at fleet scale: which cluster, which team, which environment. Kubecost’s multi-cluster federation aggregates allocation data from every connected cluster into one view, which matters more than it sounds like it should, since teams that only check dashboards per-cluster routinely miss that their real waste is three near-identical staging environments rather than any inefficiency inside a single one.
For long-term retention beyond what any single cluster’s storage can hold, export allocation data on a schedule to S3 or BigQuery and treat it as a queryable historical archive rather than something you only view live in a dashboard. That also makes it possible to feed the same numbers into whatever BI or spend-reporting tool finance already uses, instead of asking them to learn a new dashboard.
If your workloads include GPU node pools, revisit the GPU efficiency views regularly rather than only at setup time. GPU capacity is disproportionately expensive and disproportionately easy to leave idle after a training run finishes, which makes it one of the highest-value places to apply the same right-sizing discipline used elsewhere in this tutorial. And if you’re running OpenCost standalone alongside Grafana, build a dedicated cost dashboard rather than mixing cost panels into an existing performance-monitoring board. The two audiences, engineers debugging latency and finance reviewing spend, rarely want the same view.
OpenCost also exposes its allocation data as Prometheus-compatible metrics, so a Grafana panel can query it the same way it queries any other exporter. That’s worth setting up even if most of your team lives in the full Kubecost dashboard day to day, since it lets on-call engineers glance at cost alongside latency and error rate during an incident, instead of treating cost as a separate system they only check once a month.
Measuring Success: What to Track After Rollout
Installing the tool is the easy part. The harder, more valuable work is building a habit around it, and that means picking a small number of numbers to revisit on a schedule rather than treating the dashboard as something you open only when a bill looks unusually high.
- Efficiency percentage, per namespace, week over week. A flat or declining trend means right-sizing recommendations aren’t being applied, not that the workload’s usage pattern changed.
- Idle cost as a share of total spend. This is usually the fastest-moving number after a rollout, since it responds directly to right-sizing and autoscaler tuning.
- Number of budget alerts fired versus number actually acted on. An alert nobody responds to is a sign the threshold, the owner, or the delivery channel needs to change, not that the alert was pointless.
- Unattributed or unlabeled spend. This should trend toward zero as labeling discipline improves. If it’s flat, new workloads are still shipping without cost-center labels.
The FinOps Foundation’s own framing is useful here: cost management is an operational discipline that repeats on a cadence, not a one-time cleanup project with a defined end date. Treating a Kubecost rollout as “done” after the first successful install is the most common way teams end up back at square one a year later, wondering why the bill crept back up despite having the tooling in place the whole time.
A Complete Working Example: Full values.yaml Configuration
This combines everything above (cluster identification, AWS billing integration, a budget alert, and right-sized resource requests for Kubecost’s own components) into a single working values.yaml file you can adapt directly.
# values.yaml — working Kubecost production example
global:
clusterId: production-cluster-01
kubecostModel:
resources:
requests:
cpu: 200m
memory: 512Mi
limits:
cpu: 500m
memory: 1Gi
persistentVolume:
enabled: true
size: 32Gi
kubecostProductConfigs:
athenaProjectID: "123456789012"
athenaBucketName: "s3://your-cur-report-bucket"
athenaRegion: "us-east-1"
athenaDatabase: "athenacurcfn_your_report"
athenaTable: "your_cur_table"
alertConfigs:
- type: "budget"
threshold: 5000
window: "monthly"
aggregation: "namespace"
filter: "namespace:\"checkout-service\""
slackWebhookUrl: "https://hooks.slack.com/services/YOUR/WEBHOOK/URL"helm upgrade --install kubecost kubecost/kubecost \
--namespace kubecost --create-namespace \
-f values.yamlApply namespace labels for chargeback, confirm the dashboard is reachable on port 9090, and give it a full reconciliation cycle before pulling numbers for a report. From here, the remaining work is process, not tooling: deciding who reviews the budget alerts, how often right-sizing recommendations get applied, and which team owns the response when a Collection crosses its threshold.
Frequently Asked Questions
Is Kubecost free to use?
Yes, there’s a free tier, though Kubecost’s v3 line introduced a $100,000 monthly spend cap on it, according to AWS’s own EKS documentation. The Amazon EKS-optimized Kubecost bundle is explicitly exempted from that cap. OpenCost, the underlying open-source engine, has no spend limit since it’s a fully free CNCF Incubating project.
What’s the real difference between Kubecost and OpenCost?
OpenCost is the free, open-source cost allocation engine. Kubecost is the commercial product, now owned by IBM, that wraps OpenCost with a full dashboard, multi-cluster views, governance features, and enterprise support.
Do I need Prometheus to run Kubecost?
It depends on the version. Kubecost’s current v3 line replaces the Prometheus dependency with a unified agent and a ClickHouse-backed storage layer, per AWS’s documentation. Standalone OpenCost, and Kubecost’s older v1/v2 lines, still require Prometheus for scraping and storing metrics.
Does Kubecost only work on AWS EKS?
No. It runs on EKS, AKS, GKE, and self-managed clusters. AWS happens to publish its own EKS-optimized bundle at no additional cost, which is why EKS shows up so often in Kubecost documentation, but the tool itself is not AWS-specific.
How long before the cost data is accurate?
Give it at least one full reconciliation cycle. A dashboard that looks sparse or shows “N/A” immediately after installation is normal, not a sign the install failed.
Is Kubecost owned by IBM now?
Yes. Kubecost operates under IBM, as part of IBM’s Apptio FinOps line, and its current documentation is published on IBM’s own docs site under the “IBM Kubecost” name.
How do I uninstall Kubecost cleanly?
Run helm uninstall kubecost -n kubecost, then check for and remove any leftover persistent volume claims in the namespace before deleting the namespace itself. Skipping the PVC cleanup is the most common cause of a messy reinstall later.
Will Kubecost replace my cloud provider’s billing console?
No, it complements it. Kubecost maps the same underlying spend down to namespace, pod, and label level for internal accountability, but your cloud provider’s console remains the source of truth for the actual invoice.
Can I start with OpenCost and move to Kubecost later without losing data?
You can add Kubecost’s dashboard on top of an existing OpenCost or Prometheus setup, since both use the same underlying allocation model. How much historical data carries over depends on how long your Prometheus deployment retained metrics before the switch, so check your retention window before assuming years of history will be waiting for you on day one.
Related Coverage
- Karpenter vs Cluster Autoscaler vs KEDA: 3x Faster [2026]
- What Is Amazon RDS?
- SQS vs Kafka 2026: 1M vs 700K msg/sec, $460 Floor
- Bedrock vs Azure AI Foundry vs Vertex AI: 17x Gap [2026]
- Google Cloud Hits 82% Growth Ahead of AWS Earnings [2026]
- What a Service Mesh Actually Does (and Why Fewer Teams Want One)
- Wazuh SIEM Setup With Docker: 14 Steps, 60 Min [2026]
For more cloud infrastructure tutorials and cost-management coverage, visit our Cloud Computing section.
