Kubernetes bills keep climbing even when traffic doesn’t. Idle pods, over-provisioned nodes, and forgotten dev clusters quietly eat budgets, and most teams only find out when finance forwards an invoice with a red circle around it. Kubecost is the tool most platform teams reach for first: a Helm-installable dashboard that maps every dollar of cloud spend down to the namespace, deployment, or label that generated it. This tutorial walks through a full install, from a bare cluster to automated FinOps reporting, using the same free “Foundations” tier anyone can run today.

By the end you’ll have Kubecost reading real Prometheus metrics, reconciled against your actual cloud invoice, paired with Karpenter for autoscaling savings, and exporting a weekly cost report automatically. Search interest in “kubecost” sits around 1,000 monthly searches in the US with low competition, according to keyword data pulled in August 2026, and it’s easy to see why: cost visibility is now a top-three ask on every platform team’s roadmap.

This isn’t a theoretical exercise, either. Every command in this guide runs against the free Kubecost tier, so you can follow along on a personal EKS, AKS, or GKE cluster (or even a local kind or minikube cluster for the install steps) without a procurement conversation first. We’ll build the stack in the order a platform team actually rolls it out: metrics first, then cost visibility, then the autoscaling tools that turn that visibility into a smaller invoice.

A quick note on scope before diving in: this guide focuses on self-hosted Kubecost running inside your own cluster, not the hosted Enterprise Cloud option. The commands, values files, and troubleshooting steps below apply directly to the free Foundations tier and translate with minor adjustments to Enterprise Self-Hosted. If your organization is already evaluating the hosted Enterprise Cloud product, the install mechanics differ, but the underlying cost model, allocation logic, and labeling advice are identical.

Why Kubernetes Cost Visibility Became Urgent in 2026

Kubernetes clusters are famously bad at reporting their own cost. A single node runs dozens of workloads, cloud bills arrive at the account level, and nobody’s invoice itemizes “namespace: checkout-service.” That gap between spend and attribution is why FinOps tooling exploded through 2025 and into 2026. In June 2026, AWS pushed the problem further into the spotlight by launching AWS FinOps Agent in public preview, an agentic AI tool that investigates cost anomalies automatically and answers plain-language questions like “why did my EKS cluster cost double last week.” That single feature tells you where the industry’s attention is: engineers want answers, not spreadsheets.

At FinOps X 2026 in June, AWS also rolled a new Cost Efficiency Score (0 to 100%) into Cost Optimization Hub, aggregating rightsizing, idle cleanup, and Savings Plans coverage into one number teams can track over time, according to the FinOps X 2026 recap published by Flexera. Kubernetes-specific tooling followed the same pattern: Karpenter adoption cut node bin-packing waste from a historical range of roughly 40-60% down to 15-25% in teams that migrated off the legacy Cluster Autoscaler, per 2026 FinOps trend reporting. None of that happens without a cost layer sitting underneath it, and that’s the gap Kubecost fills.

The other reason this matters now: FOCUS-formatted billing data (a vendor-neutral schema for cloud cost and usage records) picked up broad adoption across FinOps tooling through 2026, according to the same FinOps X recap, and vendors used the conference to announce integrations tracking AI workload spend specifically, including tie-ins with AWS Bedrock and GCP Vertex AI. Teams running LLM inference or fine-tuning jobs inside Kubernetes now need a cost tool that can separate “the model serving pod” from “the checkout service” in the same report, and that’s precisely the label-based allocation Kubecost was built around long before AI workloads made it urgent.

What Kubecost Does (and Where OpenCost Fits)

Kubecost is a Kubernetes cost monitoring platform built on top of Prometheus. It scrapes cluster metrics, joins them against your actual cloud invoice (including reserved instances, Savings Plans, and spot discounts), and renders per-namespace, per-deployment, and per-label cost breakdowns in a web dashboard. IBM acquired Kubecost in 2024 and now ships it under the Apptio umbrella, but the core product is still deployed the same way most teams have always installed it: a single Helm chart into your own cluster.

Kubecost ships in three tiers, and this tutorial only needs the first one:

TierCostCluster LimitRetention
FoundationsFreeUnlimited clusters, up to 250 cores total15 days
Enterprise Self-HostedCustom quoteNo hard core limitConfigurable, typically 1+ year
Enterprise CloudCustom quoteNo hard core limitConfigurable, typically 1+ year

Underneath Kubecost sits OpenCost, the CNCF-governed open-source allocation engine that Kubecost’s own team donated to the foundation in 2022. OpenCost handles the raw cost-allocation math under an Apache 2.0 license with no fees attached, which is why it now shows up as the default engine inside several competing commercial tools. The practical difference: OpenCost reports on-demand rates and drifts from your real invoice once discounts and spot pricing enter the picture, while Kubecost reconciles against the actual bill. We’ll cover that trade-off in more detail later, but for now, know that installing Kubecost gives you OpenCost’s allocation logic plus invoice reconciliation, dashboards, and alerting on top.

How the Cost Model Actually Calculates a Dollar Figure

Kubecost’s cost-model pod does three things on a loop: it pulls resource usage (CPU, memory, storage, network) from Prometheus, it pulls list pricing or actual invoice line items for the underlying node, and it splits each node’s cost across the pods scheduled on it in proportion to what they requested and used. That’s why the labeling step later in this tutorial matters so much. Without labels, Kubecost can still tell you “this node cost $40 yesterday,” but it can’t tell you which of the fifteen pods running on that node is responsible for $30 of it. Add cloud billing integration on top and the same math swaps list pricing for your negotiated rate, reserved instance coverage, and spot discounts, which is usually where the biggest gap between “estimated” and “actual” cost shows up.

This is also why shared cluster resources (the control plane overhead, a shared load balancer, a cluster-wide logging DaemonSet) end up in their own bucket rather than vanishing into a single team’s total. Kubecost calls this “idle and shared cost,” and how you choose to split it, evenly across teams, proportionally by usage, or left as its own line item, is a policy decision your organization has to make once, not something the tool decides for you.

Prerequisites

Before starting, make sure you have the following in place. This tutorial uses the free Foundations tier, which supports unlimited clusters up to 250 cores with 15-day metric retention, so you don’t need a license key to follow along. None of these steps require paid add-ons, but a couple of them (cloud billing integration in particular) do require account-level permissions that a platform or DevOps engineer, rather than an individual application developer, typically holds.

  • A running Kubernetes cluster on version 1.28 or newer (self-managed, Amazon EKS, Azure AKS, or Google GKE all work)
  • cluster-admin RBAC permissions, needed to create namespaces and install Helm charts
  • Helm 3.12 or newer installed locally
  • kubectl configured and pointed at the target cluster
  • At least 0.5 vCPU and 2GB of free memory on a node for the Kubecost and Prometheus pods
  • Cloud billing export enabled if you want invoice reconciliation (AWS Cost and Usage Report, Azure Cost Management export, or GCP Billing export to BigQuery)
  • Karpenter and KEDA are optional but recommended for the autoscaling steps later in this guide
  • A Slack workspace (or another webhook-compatible chat tool) if you want budget alerts routed somewhere besides the dashboard
  • 15 to 30 minutes for the base install, plus another day if you’re waiting on a cloud billing export to backfill

One clarification worth making up front: none of this requires a fresh cluster. Kubecost is read-only with respect to your workloads (it never modifies deployments, only reads metrics and applies its own resource requests), so it’s safe to install directly into an existing production or staging cluster rather than standing up a throwaway environment first.

Step 1: Prepare Your Kubernetes Cluster

Start by confirming cluster access and creating a dedicated namespace. Keeping Kubecost isolated in its own namespace makes RBAC, resource quotas, and future upgrades far easier to manage.

kubectl cluster-info
kubectl get nodes -o wide
kubectl create namespace kubecost

If kubectl cluster-info times out, fix your kubeconfig context before continuing. Everything downstream depends on this connection working. It’s also worth checking kubectl auth can-i create namespaces at this point; on managed clusters shared across teams, it’s common to have read access but not the cluster-admin scope Kubecost’s install actually needs, and finding that out now is far less frustrating than finding it out mid-install.

Step 2: Install Prometheus, Kubecost’s Metrics Backbone

Kubecost needs a Prometheus instance scraping cluster and node metrics. If your cluster doesn’t already run one, the community kube-prometheus-stack chart is the fastest path to a working setup.

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace kubecost \
  --set prometheus.prometheusSpec.retention=15d

The 15-day retention flag matches Kubecost’s Foundations tier retention window, so you’re not paying for metrics history the free tier can’t use anyway. If your organization already runs Prometheus centrally, skip this step and point Kubecost at that existing endpoint in the next step instead of installing a second copy. This install typically takes two to three minutes; give the operator pod time to reconcile its CRDs before assuming something has failed if kubectl get pods -n kubecost doesn’t show everything as Running immediately.

Step 3: Add the Kubecost Helm Repository

With metrics flowing, add Kubecost’s own Helm repository. This is a one-line step, but it’s worth confirming the repo actually resolves before moving on, since a stale mirror is a common source of install failures.

helm repo add kubecost https://kubecost.github.io/cost-analyzer/
helm repo update
helm search repo kubecost/cost-analyzer

You should see kubecost/cost-analyzer listed with a chart version and app version. If the search returns nothing, re-run helm repo update and check outbound HTTPS access from your workstation or CI runner.

Step 4: Install Kubecost via Helm

Now install the chart itself. This deploys the cost-model pod, the frontend dashboard, and a small set of supporting services into the kubecost namespace, wired to the Prometheus instance from Step 2.

helm install kubecost kubecost/cost-analyzer \
  --namespace kubecost \
  --set global.prometheus.fqdn=http://prometheus-kube-prometheus-prometheus.kubecost.svc:9090 \
  --set global.prometheus.enabled=false \
  --set kubecostProductConfigs.clusterName="production-cluster"

Setting global.prometheus.enabled=false tells Kubecost to use the Prometheus you already installed instead of bundling its own. Give the pods a couple of minutes to come up, then verify:

kubectl get pods -n kubecost

Expected output once everything is healthy:

NAME                                   READY   STATUS    RESTARTS   AGE
kubecost-cost-analyzer-7f8b9c-2xk4p    2/2     Running   0          2m
kubecost-grafana-6d5f7d-9jql2          2/2     Running   0          2m
prometheus-kube-prometheus-op-0        1/1     Running   0          6m

Step 5: Access and Tour the Kubecost Dashboard

Port-forward the frontend service to reach the dashboard locally without exposing it publicly yet.

kubectl port-forward -n kubecost deployment/kubecost-cost-analyzer 9090:9090

Open http://localhost:9090 and you’ll land on the Overview page. It takes 10 to 15 minutes for the first cost data points to populate because Kubecost needs at least one full Prometheus scrape interval to compute allocation. The three tabs worth learning first are Allocation (cost by namespace, pod, or label), Assets (cost by underlying cloud resource, like EBS volumes or load balancers), and Savings (rightsizing and idle-resource recommendations).

Resist the urge to skip straight to Savings on day one. The recommendations there are only as good as the usage history Kubecost has collected, and on a brand-new install that history is minutes old. Give it 48 to 72 hours of real traffic before treating any rightsizing suggestion as something to act on; a recommendation based on Tuesday afternoon’s traffic pattern can look very different from one based on a full week that includes your weekend low.

Step 6: Connect Your Cloud Billing Data

Without this step, Kubecost estimates cost from public on-demand pricing, which is exactly the gap that makes OpenCost drift from your real bill. Connecting the actual invoice is what turns Kubecost’s numbers into figures finance will trust.

For AWS, this means pointing Kubecost at your Cost and Usage Report (CUR) in S3 with an IAM role scoped to read that bucket:

helm upgrade kubecost kubecost/cost-analyzer \
  --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"

Azure and GCP follow the same pattern through the Settings page in the dashboard: Azure uses a Cost Management export SAS token, and GCP uses a BigQuery billing export dataset. Reconciliation typically takes 24 hours to fully backfill once connected, since it depends on your cloud provider’s billing export schedule rather than anything Kubecost controls.

Scope the IAM role as tightly as you can, read-only access to the CUR bucket is all Kubecost needs, and there’s no reason to grant anything broader. This is also the step where multi-account setups get complicated: if your Kubernetes clusters run in a different AWS account than the one generating the consolidated bill, you’ll need a cross-account role with an explicit trust policy rather than a same-account IAM role, so budget extra time here if your organization uses AWS Organizations with per-team accounts.

Step 7: Configure Namespace and Label-Based Allocation

Cost data is only useful if it maps to something a human owns. Before your report means anything to a team lead, enforce a labeling standard across deployments. A minimal but effective set:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout-service
  labels:
    team: payments
    env: production
    cost-center: eng-platform
spec:
  template:
    metadata:
      labels:
        team: payments
        env: production
        cost-center: eng-platform

Once labels exist, tell Kubecost which ones to treat as allocation dimensions under Settings > Allocation. Teams that skip this step end up with accurate totals but no way to answer “which team should fix this,” which defeats the point of installing a cost tool in the first place. If you’re retrofitting labels onto an existing cluster rather than starting fresh, prioritize your five or six highest-cost namespaces first; chasing 100% label coverage on day one usually stalls the whole rollout, while covering the namespaces that account for most of the spend gets you 80% of the value in a fraction of the time.

It also helps to pick a small, fixed vocabulary for the team label rather than letting it grow organically. If five different services end up labeled payments, payments-team, Payments, and pay, Kubecost will treat those as four separate cost centers instead of one, and your first report will look far more fragmented than your org chart actually is. A short naming convention document, even a five-line one, saves a painful cleanup pass a month later.

Step 8: Read Your First Cost Allocation Report

Head to the Allocation tab, group by label:team, and set the window to “Last 7 days.” A healthy first report looks something like this:

TeamCPU CostMemory CostTotal (7d)Efficiency
payments$142.30$88.10$230.4061%
search$310.90$195.40$506.3034%
platform$95.60$61.20$156.8078%
data-pipeline$412.00$298.70$710.7029%
unlabeled$58.40$41.10$99.50N/A

The efficiency column (requested resources actually used) is where the money usually is. A team sitting at 29% efficiency, like data-pipeline above, is requesting roughly three times the CPU and memory it consumes, an easy conversation to start with a screenshot in hand rather than a vague complaint about the AWS bill.

Step 9: Set Efficiency Scores, Budgets, and Alerts

Static dashboards get ignored after the second week. Alerts don’t. Configure a budget threshold and a Slack webhook so anomalies surface automatically instead of waiting for someone to remember to check.

helm upgrade kubecost kubecost/cost-analyzer \
  --namespace kubecost \
  --reuse-values \
  --set kubecostProductConfigs.alertConfigs.frontendEnabled=true \
  --set kubecostProductConfigs.alertConfigs.globalSlackWebhookUrl="https://hooks.slack.com/services/XXX/YYY/ZZZ"

In the dashboard, add a Budget Alert per namespace (for example, “alert if payments exceeds $50/day”) and a Recurring Update alert set to weekly so a summary lands in Slack without anyone opening the dashboard manually. Set thresholds slightly above current spend rather than at it; a budget alert that fires every single day within the first week gets muted in Slack within the second, which defeats the purpose of having it at all.

Step 10: Pair Kubecost With Karpenter for Autoscaling Savings

Visibility tells you where money is going. Karpenter is what actually reduces the bill by improving node bin-packing and provisioning right-sized instances instead of relying on fixed node groups. If Karpenter isn’t already running, install it and define a NodePool that Kubecost can then measure against:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
      nodeClassRef:
        name: default
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized

See Karpenter’s official documentation for the full NodeClass setup specific to your cloud provider. After a week running, compare the Assets tab in Kubecost before and after: teams migrating from the legacy Cluster Autoscaler to Karpenter have reported node waste dropping from the 40-60% range down to 15-25%, and Kubecost’s per-node cost view is exactly what makes that comparison visible instead of anecdotal.

Step 11: Add VPA and KEDA for Workload Right-Sizing

Karpenter fixes the node layer; the Vertical Pod Autoscaler and KEDA fix the pod layer. Start VPA in recommendation-only mode so it doesn’t restart pods automatically while you’re still validating numbers against Kubecost’s efficiency scores.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: data-pipeline-vpa
  namespace: data-pipeline
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: data-pipeline
  updatePolicy:
    updateMode: "Off"

Combine that with KEDA for event-driven workloads that don’t need to run at a fixed replica count around the clock, and check out the Kubernetes project’s own in-place pod resize documentation if you’re on a cluster version that supports it, since it lets VPA apply CPU and memory changes without evicting the pod first.

Step 12: Automate Recurring FinOps Reports

Close the loop with a scheduled export so cost data reaches stakeholders who will never open the dashboard themselves. Kubecost exposes a REST API that a simple CronJob can hit weekly:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: kubecost-weekly-export
  namespace: kubecost
spec:
  schedule: "0 8 * * MON"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: export
              image: curlimages/curl:latest
              command:
                - sh
                - -c
                - >
                  curl -s "http://kubecost-cost-analyzer.kubecost:9090/model/allocation?window=7d&aggregate=label:team"
                  -o /tmp/report.json
          restartPolicy: OnFailure

Pipe that JSON into whatever your team already uses for reporting, whether that’s a Slack bot, a Grafana panel, or a shared spreadsheet. The point is removing the manual step; a report nobody has to remember to generate is a report that actually gets read.

Your Complete Working Project

At this point you have a full FinOps stack running: Prometheus feeding Kubecost, Kubecost reconciled against real cloud billing, labeling enforced at the deployment level, Karpenter handling node-level efficiency, VPA and KEDA handling pod-level efficiency, and a weekly automated export closing the loop. That’s the same layered architecture described in 2026 Kubernetes FinOps guidance: inform with cost visibility, then optimize with autoscaling, rather than trying to guess at rightsizing before you can measure it.

A minimal repo structure for keeping this reproducible across clusters:

finops-stack/
├── helm-values/
│   ├── prometheus-values.yaml
│   └── kubecost-values.yaml
├── karpenter/
│   └── nodepool.yaml
├── autoscaling/
│   ├── vpa-data-pipeline.yaml
│   └── keda-scaledobject.yaml
├── cronjobs/
│   └── weekly-export.yaml
└── README.md

Check this into version control and every new cluster becomes a helm upgrade --install and kubectl apply -f away from full cost visibility, instead of a fresh round of manual configuration. If you’re managing multiple clusters, wrap the Helm calls in a small Makefile or a GitHub Actions workflow that takes a cluster name as input; the values files above rarely need to change between clusters beyond the clusterName field and the billing bucket reference, so most of this genuinely is copy-and-apply once the first cluster is working.

One thing worth testing before calling the project done: kill the Kubecost pod on purpose (kubectl delete pod -n kubecost -l app=cost-analyzer) and confirm it comes back with its configuration intact. Because everything here is defined in Helm values and Kubernetes manifests rather than clicked together in the UI, a pod restart, a node drain, or even a full cluster rebuild from the same manifests should reproduce the exact same setup without anyone needing to remember which checkboxes they ticked six months ago.

Kubecost vs OpenCost vs Commercial Alternatives

Kubecost isn’t the only option, and it isn’t always the right one. Here’s how it stacks up against the free engine underneath it and the commercial platforms it competes with:

ToolLicenseInvoice ReconciliationBest For
OpenCostApache 2.0, freeNo (on-demand rates only)Teams wanting raw allocation data with no vendor lock-in
Kubecost (Foundations)Free up to 250 coresYesSmall to mid-size clusters needing dashboards and alerts
Kubecost EnterpriseCustom quoteYes, multi-clusterLarge orgs needing SSO, governance, and support SLAs
CAST AICommercialYesAutomated bin-packing and Spot orchestration
FinoutCommercialYesCross-cloud FinOps beyond just Kubernetes
ScaleOpsCommercialPartialAutonomous pod rightsizing with in-place resize

Vendors like Finout have published customer averages showing roughly 30% year-over-year savings after adopting a cost-optimization layer, though that figure comes from the vendor’s own case studies rather than an independent audit, so treat it as a directional benchmark rather than a guarantee. The realistic takeaway: OpenCost is the right starting point if all you need is raw numbers, Kubecost’s free tier is the right next step once you need dashboards and invoice reconciliation, and the commercial platforms only start paying for themselves once a cluster is large enough that manual rightsizing stops scaling.

When to Skip Kubecost Entirely

Kubecost isn’t the right call for every team. If your entire footprint is a single small cluster running a handful of services, the overhead of running a dedicated Prometheus stack and a cost-analyzer pod just to watch a bill that’s already small enough to eyeball in the AWS console probably isn’t worth it. In that case, OpenCost alone (or even just AWS Cost Explorer with tag-based filtering) gets you most of the answer with a lot less to maintain. Kubecost earns its keep once a cluster crosses roughly a few dozen services and multiple teams start sharing it, which is exactly the point where “who owns this cost” stops being answerable by memory.

Common Pitfalls When Rolling Out Kubecost

Most Kubecost rollouts don’t fail at the Helm install, they fail in the weeks after, when the tool is running but nobody trusts the numbers it produces or acts on what it finds. The issues below cover the majority of complaints we’ve seen from teams six months into using it, and every one of them is fixable in under an hour once you know where to look.

  • Installing without existing labels. Kubecost can’t allocate cost to a team that never labeled its deployments. Fix labeling before you expect a useful report, not after.
  • Skipping cloud billing integration. On-demand pricing estimates can be off by 40% or more once Savings Plans and spot instances are in the mix. Connect the real invoice in Step 6 before trusting any dollar figure.
  • Running a second Prometheus by accident. Teams that already run Prometheus centrally sometimes let Kubecost install its own bundled copy too, doubling scrape load and confusing which instance owns which metrics.
  • Ignoring the 250-core free tier cap. Clusters that grow past 250 cores on the Foundations tier will see features silently degrade rather than a clear error, so track core count as you scale.
  • Never revisiting VPA recommendations. Leaving VPA in recommendation-only mode indefinitely means the tool just adds another dashboard nobody acts on. Set a recurring calendar reminder to apply the changes it suggests.
  • Treating the first week’s numbers as final. Cost and efficiency figures stabilize over roughly two full traffic cycles (a week is the minimum, a full business cycle including month-end batch jobs is better). Acting on day-three data tends to produce rightsizing decisions that break the first time a weekly batch job runs.

Troubleshooting Guide

Most of the issues below show up in the first 24 hours after install, and almost all of them trace back to one of two root causes: Prometheus isn’t scraping the right targets yet, or a cloud billing integration hasn’t finished its first backfill. Work through them in order before assuming something is fundamentally broken; the vast majority resolve with a config fix rather than a reinstall.

  • Dashboard shows “No data available.” Wait a full 15 minutes after install; Kubecost needs at least one Prometheus scrape interval before the Allocation tab populates.
  • Pods stuck in Pending. Check node resource availability with kubectl describe pod; Kubecost and Prometheus together need roughly 0.5 vCPU and 2GB free.
  • Cost numbers don’t match your AWS invoice. Confirm the CUR bucket integration from Step 6 actually completed; without it, Kubecost falls back to on-demand list pricing.
  • Helm install hangs on “waiting for condition.” Usually a missing StorageClass for the persistent volume; run kubectl get storageclass and set one explicitly with --set persistentVolume.storageClass=.
  • Prometheus targets show “down” in the targets page. Check that global.prometheus.fqdn in your Helm values exactly matches the Prometheus service name and namespace.
  • Slack alerts never arrive. Test the webhook URL directly with curl outside of Kubecost first; a malformed or revoked webhook is the most common cause.
  • Efficiency percentage shows “N/A.” This means resource requests were never set on the deployment; Kubecost can’t calculate efficiency without a request value to compare usage against.
  • Multi-cluster view is empty. The Foundations tier reports per-cluster by default; federated multi-cluster views require the Enterprise tier’s aggregator component.
  • Helm upgrade wipes out previous custom settings. This almost always means the --reuse-values flag was left off an upgrade command. Every Helm upgrade in this tutorial that follows the initial install includes it deliberately, so if you’re scripting your own variations, make sure it’s there too.

Advanced Tips for Production FinOps Workflows

Once the basic install is stable, a few refinements make Kubecost far more useful in a real organization rather than a side project one engineer checks occasionally. First, adopt FOCUS-formatted billing data if your finance team already consumes it elsewhere; FOCUS adoption broadened significantly across FinOps tooling through 2026, and standardizing on it means Kubecost’s exports slot directly into existing cost dashboards instead of requiring a translation layer.

Second, treat the Cost Efficiency Score pattern AWS introduced at FinOps X 2026 as a template you can replicate internally: instead of reporting raw dollars per team, report a 0-100 efficiency score per namespace. It travels better in a leadership review than a dollar figure that fluctuates with traffic. Third, if you’re running AI or LLM workloads on the cluster, tag them distinctly; AI cost tracking (integrations with model providers like AWS Bedrock and GCP Vertex AI) became one of the fastest-growing categories in FinOps tooling this year, and those workloads often carry cost profiles wildly different from standard web services. Finally, revisit your Karpenter consolidation policy quarterly rather than once, since workload patterns shift enough over two or three months that a policy tuned in January is rarely still optimal by summer.

A fifth tip worth stealing from larger platform teams: turn the weekly export from Step 12 into a trend, not just a snapshot. A single week’s cost report tells you what happened; twelve weeks of the same report, charted, tells you whether last week’s efficiency gain actually held or quietly regressed once the team that fixed it moved on to something else. Storing that JSON export in even a simple spreadsheet or a lightweight time-series database turns Kubecost from a dashboard people check into a record people can be held accountable to, which is usually the point where a FinOps program stops being a side project and starts showing up in quarterly planning.

Frequently Asked Questions

Is Kubecost free to use?
Yes. The Foundations tier is free for unlimited clusters up to 250 cores total, with 15-day metric retention and unlimited users. Enterprise tiers require a custom quote for larger clusters or multi-cluster aggregation.

What’s the difference between Kubecost and OpenCost?
OpenCost is the free, CNCF-governed allocation engine that Kubecost’s team open-sourced in 2022. Kubecost builds dashboards, invoice reconciliation, alerting, and enterprise features on top of that same core logic.

Does Kubecost need Prometheus?
Yes, by default. Kubecost scrapes metrics through Prometheus, either a bundled instance or one you already run. OpenCost, by contrast, can now run without Prometheus at all using its beta Collector Datasource.

How long until Kubecost shows accurate data?
Basic allocation data appears within 10 to 15 minutes of install. Full invoice reconciliation with your cloud provider’s billing export typically takes up to 24 hours to backfill.

Can Kubecost work across AWS, Azure, and GCP at once?
Yes, Kubecost supports billing integrations for all three providers, and Enterprise tiers add cross-cluster and cross-cloud aggregation for organizations running a hybrid footprint.

Do I need Karpenter for Kubecost to work?
No, Karpenter is optional. Kubecost works standalone as a visibility tool. Karpenter, VPA, and KEDA are the pieces that actually act on what Kubecost reports.

Why does my efficiency score show N/A for some workloads?
Kubecost calculates efficiency by comparing actual usage to requested resources. Deployments without CPU or memory requests set have nothing to compare against, so the score can’t be computed.

Is it safe to run Kubecost in production without testing it first?
Yes, since Kubecost only reads metrics and billing data, it doesn’t modify existing workloads. The install itself adds new pods (the cost-analyzer and, if you use the bundled option, Prometheus), so the only real risk is resource contention on a tightly packed cluster, which is why the prerequisites above call for a small buffer of spare CPU and memory before installing.

For more on cloud cost, security, and infrastructure tooling, visit our Cloud Computing section.