kubectl-cost turns Kubecost's cost model into a kubectl subcommand

The plugin is a client, and the cost model lives on the server

kubectl-cost is a kubectl plugin that provides easy CLI access to Kubernetes cost information, like historical cost and predicted future cost, via Kubecost's APIs. It allows developers, devops and others to quickly determine the cost and efficiency of any Kubernetes workload.

The important structural fact is in that sentence: the data comes from Kubecost's APIs. The plugin is a client for a cost backend that is running somewhere else, and it is not a calculator. That determines everything about how it is installed and what it can tell you.

There is also an OpenCost path. The README notes that if you use OpenCost, most of kubectl cost works, and points at the OpenCost documentation for examples, with an invitation to open an issue if problems come up. The dependency list in go.mod confirms it: github.com/opencost/opencost/core is a direct dependency, and the Kubernetes client libraries are k8s.io/api, k8s.io/apimachinery, k8s.io/cli-runtime and k8s.io/client-go, all at 0.32.0.

The audience is therefore a cluster that already has a cost backend. If you have no Kubecost and no OpenCost, this plugin has nothing to talk to, and installing it produces a tool that cannot answer a single question. The other audience is a team that already looks at cost in a web UI and wants the same numbers in a terminal, in a script, or in a pull request check.

The project is Apache-2.0 licensed, the last push was on 2026-09-28, and the release history shows v0.6.6 from 2024-09-26.

Installing means two things: a cost backend and then a binary

The installation section has two numbered steps, and the first one is the one people skip.

Step one is installing Kubecost, because the software requires a running deployment of Kubecost in your cluster. The recommended path is Helm, with alternative install options documented. The Helm 3 command given is:

helm repo add kubecost https://kubecost.github.io/cost-analyzer/
helm upgrade -i --create-namespace kubecost kubecost/cost-analyzer --namespace kubecost --set kubecostToken="a3ViZWN0bEBrdWJlY29zdC5jb20=xm343yadf98"

Step two is installing the plugin itself. With Krew, the kubectl plugin manager, it is one command:

kubectl krew install cost

The Krew manifest is in the krew-index repository. On Linux and macOS the README gives a manual download that detects your platform:

os=$(uname | tr '[:upper:]' '[:lower:]') && \
arch=$(uname -m | tr '[:upper:]' '[:lower:]' | sed -e s/x86_64/amd64/) && \
curl -s -L https://github.com/kubecost/kubectl-cost/releases/latest/download/kubectl-cost-$os-$arch.tar.gz | tar xz -C /tmp && \
chmod +x /tmp/kubectl-cost && \
sudo mv /tmp/kubectl-cost /usr/local/bin/kubectl-cost

If you prefer GitHub releases or you are on Windows, you download the appropriate binary and rename it to kubectl-cost and put it in your PATH. The README explains why that is enough: as long as the binary is still named kubectl-cost and is somewhere in your PATH, it will be usable, because kubectl automatically finds plugins by looking for executables prefixed with kubectl- in your PATH.

That last point is the whole plugin convention, and it is worth understanding because it also tells you how a name collision would look. If some other kubectl- prefixed executable is earlier in your PATH, it shadows this one.

There is a DEVELOPMENT.md for building from source, and the Makefile builds with CGO_ENABLED=0 for darwin-amd64, darwin-arm64, linux-amd64 and windows-amd64, packaging each as a tarball alongside the LICENSE file.

Aggregation subcommands share a rate and historical mode

The subcommands are focused on aggregation-based cost monitoring: namespace, deployment, controller, label, pod and node. Each one displays cost information aggregated by the name of the subcommand.

Each aggregation subcommand has two modes. Rate, which is the default, displays the projected monthly cost based on the activity during the window. Non-rate, with the --historical flag, displays the total cost for the duration of the window.

That distinction is the one to be careful with, because the two numbers answer different questions and are easy to quote interchangeably. A rate is a projection, and a projection at a cluster level says nothing about a single workload's share of it. A historical total is what was actually charged over a period, and it is the number that should go into a retrospective.

The example output shows how the cost is broken down. The namespace table has columns for CPU, CPU EFF., MEMORY, MEMORY EFF., GPU, PV, NETWORK, SHARED COST and MONTHLY RATE (ALL), and the efficiency columns are the interesting ones, because a workload using far less than its requests shows a high efficiency number. The shared cost column is the part of the bill that is not attributable to any one namespace, and it is spread across the rows, which is a model choice rather than a measurement.

The bottom row, SUMMED, is where the double counting question gets answered. In the sample, the shared cost column sums to 960 while the individual rows each show the same 137.142857, and the summed monthly rate is 1023.000194, which is the sum of the row rates including the shared cost. So the shared cost share is attributed to every row and then summed in the total, which means each per-namespace figure already includes part of it and is not a billing amount.

The built-in usage info with --help documents the flags for each subcommand.

predict reads a manifest and prices it against history

Starting with Kubecost v1.100, kubectl cost predict is available, and it uses historical resource cost information in your cluster to predict the cost implications of undeployed changes. It currently supports Pod, Deployment and StatefulSet workloads, with more support on the way. It accepts YAML-formatted data either in a file with -f your-file.yaml or from STDIN with -f -.

The example output shows what it returns, and the shape of the answer is the point. The table has OBJECT, Δ QTY, RESOURCE UNIT, COST PER UNIT, Δ COST/MO and % CHANGE columns, and the rows are per resource rather than per object, so a deployment shows a row for CPU in millicores and a row for RAM in MiB, each with its own unit cost and its own monthly delta and percentage change.

That is a materially different question from what the aggregation subcommands answer. A namespace table tells you what a namespace costs. A predict table tells you what the difference is between the manifest you have and the one you are about to apply, priced with the cluster's own historical rates for that resource. It is a review tool for a pull request rather than a dashboard for a namespace.

The documented example feeds a Deployment manifest in through STDIN:

read -r -d '' DEF << EndOfMessage
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        resources:
          requests:
            cpu: "3"
            memory: "2Gi"
EndOfMessage
echo "$DEF" | kubectl cost predict -f -

The version requirement is the thing to check before you rely on this. It needs a v1.100 or later Kubecost installation, which is a much newer backend than the plugin's own 0.6.x version line, and the plugin talks to the API rather than to a stored dataset.

The terminal UI is experimental and rate-only

There is also a kubectl cost tui, which displays a TUI and is currently limited to monthly rate projections. It supports most of the above subcommands while in an experimental status.

The two qualifiers in that sentence are the two facts worth carrying. It is limited to monthly rate projections, so there is no historical view in the TUI, and it is experimental, so the interface may change. The README ships a GIF of it alongside the standard CLI usage animation, which is the clearest documentation it gets.

The dependencies explain the shape. The TUI is built on tcell/v2 for terminal handling, with rivo/tview for the widgets and jedib0t/go-pretty/v6 for the tables. The CLI itself is built on spf13/cobra for the command tree, spf13/pflag for flags and spf13/viper for configuration.

The command structure follows cobra's conventions, which is why the subcommand names read the way they do. The mode flag is what distinguishes a rate from a historical total, the entity type is the subcommand name, and the specific flags for each are documented in the built-in help rather than in the README, so --help is part of the normal workflow rather than a fallback.

Where kubectl-cost is the wrong tool

The first wrong-tool case is a cluster with no cost backend. This is a client, and it queries Kubecost's APIs, so a cluster without Kubecost or OpenCost has nothing for it to talk to. The installation steps put the backend first for that reason. A team that wants cost visibility without running a cost-analyzer in the cluster needs a different approach, and this plugin is not it.

The second is real chargeback. The numbers in the table come from a shared cost model, with a shared cost column that is distributed rather than measured, and with the aggregation semantics described in the README. That is a model for understanding relative cost and efficiency across a cluster, not an invoice reconciliation. Anyone who needs per-team billing that sums to what the cloud provider charged will find that the tool answers a nearby question.

The third is the coupling to a specific backend's version. The predict subcommand needs Kubecost v1.100 or later, and the plugin's own release line is 0.6.x with the newest tagged release from September 2024. The two version lines move at different speeds, so a cluster on a recent Kubecost and a workstation running an older plugin binary can be a mismatch, and the README's advice to follow the OpenCost documentation for examples and to open an issue when something does not work is the practical response.

The fourth is that this is a single-purpose plugin. It is a cost viewer with a predict mode, and it is not a general Kubernetes query tool, a rightsizing recommendation engine, or a policy enforcement mechanism. A team that wants automated enforcement, for instance failing a deployment that would exceed a budget, needs a different tool, because this one reports rather than gates.

The licence is Apache-2.0, which is permissive with an explicit patent grant, and it does not oblige you to open-source anything you build with it.

Editorial conclusion

kubectl-cost fits a team with Kubecost or OpenCost already deployed who wants cost answers in the terminal rather than in a dashboard, and it does not fit a cluster without a cost backend or a team that needs per-workload chargeback rather than a shared cost model. Before installing, check the subcommand you need against the cost backend version you run, since the predict subcommand requires Kubecost v1.100 or later, and note that the plugin is a thin client: the numbers it prints come from the cost-analyzer, not from the plugin.

Frequently asked questions

Official sources

1. Issues
2. kubecost/kubectl-cost on GitHub
3. License: Apache-2.0
4. README
5. Releases