kubectl-view-allocations turns cluster capacity into a tree you can group

A plugin for the question kubectl top cannot answer

kubectl-view-allocations is a kubectl plugin for visualizing resource allocations across your cluster, and the README names three differentiators that define what it does.

The first is coverage of all resources: cpu, memory, gpu and any custom resource, and the README is explicit that it is not limited to cpu and memory like most tools. In a cluster running GPU workloads or an operator with custom extended resources, that difference is the whole reason to use a separate tool.

The second is a tree view, where you group and aggregate by resource, node, namespace or pod in any combination through the -g flag. A capacity question usually has more than one axis in it. Who is using the GPU, which node is it on, which namespace does it belong to, and how much is left over.

The third is the full picture: requested, limit, allocatable, free, and optionally live utilization with -u, which requires metrics-server on the cluster.

kubectl view-allocations -u

The tool is written in Rust, published on crates.io as kubectl-view-allocations with documentation on docs.rs, and it is a plugin in the kubectl sense, so it becomes kubectl view-allocations once it is on your path. The README states that all examples use the binary name directly and that if you installed it through krew you substitute kubectl view-allocations.

The audience is cluster operators and platform engineers, and the license is CC0-1.0, which is a public domain dedication rather than the usual permissive software licence.

Four install paths, and krew is the recommended one

The README lists four ways to install the plugin and recommends krew, because it is the easiest way to install it and keep it up to date.

kubectl krew install view-allocations

The krew route is the one to take if you already use krew for other plugins, since the update path is the same as for everything else on your machine.

mise is the second option, using the GitHub releases backend:

mise use -g github:davidB/kubectl-view-allocations

A binary can be downloaded from the GitHub releases page, or fetched with the project's script:

curl https://raw.githubusercontent.com/davidB/kubectl-view-allocations/master/scripts/getLatest.sh | bash

And cargo is the option if you build from source:

cargo install kubectl-view-allocations

That last one requires a Rust toolchain and compiles the project locally, and the Cargo.toml shows how heavy that is: the kube client at version 4 with rustls-tls, oidc, oauth and socks5 features, clap for the command line, tokio for the async runtime, and an optional prettytable feature for the table output. The crate targets edition 2024.

One detail in the manifest is worth noting for anyone embedding it. The binary is declared with a required-features list of cli, and the default feature set is cli, with prettytable as a separate optional feature. So the crate is deliberately structured as a library with a thin binary on top, which is what makes the examples directory and the pod_api.rs example possible.

The repository also carries a .krew.yaml manifest, since krew requires one for a plugin to be installable that way.

What the five columns actually compute

The README documents each column, and the definitions are worth reading closely because two of them are computed in ways that surprise people.

Requested is the resources requested by containers in pod manifests, summed by pod, namespace or node, and it includes the percentage of the group's allocatable total. Limit is the maximum resources set in pod manifests, summed the same way, also with a percentage.

Allocatable is what the nodes define or what was detected on them. Free is the interesting one: by default it is Allocatable minus max(Limit, Requested), and the README points at the --used-mode flag to change that. The default is deliberately conservative, because a pod with a limit reserves that much room even if it is idle, so counting the limit as used is the safe reading for scheduling purposes. Switching to --used-mode changes which side of the max is used.

Utilization is the one column that is not computed from manifests. It is actual cpu and memory usage from the Metrics API, it is disabled by default, and it requires metrics-server on the cluster.

Two consequences follow. Utilization only reports cpu and memory, because that is what the Metrics API exposes, so a GPU node shows its GPU allocation but no GPU usage unless something else reports it. And because utilization comes from a separate API, the same command can return a full picture in one run and a partially empty picture in another depending on whether metrics-server is installed.

The output format for the overview groups by resource:

> kubectl-view-allocations -g resource

 Resource              Requested          Limit  Allocatable     Free
  cpu                 (21%) 56.7    (65%) 176.1        272.0     95.9
  ephemeral-storage     (0%)  __       (0%)  __        38.4T    38.4T
  memory             (8%) 52.7Gi  (15%) 101.3Gi      675.6Gi  574.3Gi
  nvidia.com/gpu      (71%) 10.0     (71%) 10.0         14.0      4.0
  pods                (9%) 147.0     (9%) 147.0         1.6k     1.5k

Note that a custom resource such as nvidia.com/gpu sits in the same table as cpu and memory, and that rows with nothing to report are shown with a blank marker rather than zero.

Grouping is what turns numbers into an answer

The -g flag accepts resource, node, namespace or pod, and the README says any combination of them. The examples show how quickly the shape of the output changes.

Filtering to a single resource gives the node breakdown of that resource:

> kubectl-view-allocations -r gpu

 Resource                   Requested       Limit  Allocatable  Free
  nvidia.com/gpu           (71%) 10.0  (71%) 10.0         14.0   4.0
  ├─ node-gpu1               (0%)  __    (0%)  __          2.0   2.0
  ├─ node-gpu2               (0%)  __    (0%)  __          2.0   2.0
  ├─ node-gpu3             (100%) 2.0  (100%) 2.0          2.0    __
  │  └─ fah-gpu-cpu-d29sc         2.0         2.0           __    __

The tree characters are doing the work. A node at full GPU allocation with the pod named underneath it answers the question that a flat table cannot, which is who is holding the capacity.

The same nesting works for namespaces and pods, and because the grouping is combinable, you can ask for the GPU allocation of one namespace inside one node. That is the difference between a report and a tool.

There is a second axis in the tool that is not a grouping: -r selects a resource, so a cluster with many resource types does not have to be read all at once. The README's table of contents lists separate sections for overview only, showing GPU allocation, showing utilization, grouping by namespaces, showing as CSV and showing as JSON, which tells you that the same data can be rendered as a table or exported for scripting.

For a capacity report that feeds a spreadsheet or a dashboard, the CSV and JSON output is the reason to use a plugin like this rather than parsing the table by eye.

Tainted nodes are hidden unless you ask for them

There is one behaviour in this plugin that will waste an afternoon if you do not know about it, and the README puts it in a callout right under the example.

By default only nodes without taints are shown. If results look empty or incomplete, use --ignore-taints to include control-plane or tainted nodes, and the README points at its own filter-by-node-taints section for the detail.

That default is defensible, since most capacity questions are about the worker pool, and a control-plane node with a NoSchedule taint is not available capacity in any meaningful sense. But it also means that on a cluster where the workloads you care about are pinned to tainted nodes, the plugin will show you a picture of nothing.

The general lesson for anyone adopting it is that this is a policy baked into the default output, not a bug. The first run on an unfamiliar cluster should therefore include --ignore-taints, and the difference between the two outputs tells you how much of your cluster the default view was excluding.

The README also documents a filter section for node taints more generally, so the behaviour is meant to be adjusted rather than worked around, and the CHANGELOG.md at the repository root will tell you when the default changed if you are comparing behaviour across versions.

A library as well as a plugin, and an unusual licence

Two structural details make this project more than a shell script.

The first is that the crate is usable as a library. The Cargo.toml defines the binary with a required-features list of cli, the default feature set is cli, and the feature list includes an optional prettytable feature. There is an examples directory with pod_api.rs, which is the shape of a Rust example that exercises the API directly rather than the command line. The dependencies confirm the intent: kube at version 4 with default-features disabled and a specific feature set including client, gzip, http-proxy, oauth, oidc, ring, rustls-tls, socks5 and webpki-roots, plus clap, chrono, itertools, serde, thiserror and tracing.

That feature list tells you what the tool can talk to: an OIDC or OAuth authenticated cluster, through a proxy, over SOCKS5, with gzip, and with either aws-lc-rs or ring for TLS. If your cluster is behind an authenticating proxy, this plugin can still reach it.

The second is the licence. The Cargo.toml declares license = CC0-1.0, and the README badge links the Creative Commons public domain dedication. That is the public domain equivalent of the Unlicense, and it is unusual for a tool of this kind, where most Kubernetes plugins are Apache-2.0 or MIT.

For a company that prefers to avoid license review for an internal tool, CC0 is about as permissive as it gets. For a company whose legal process has templates for Apache-2.0 and nothing else, an unusual licence is an unusual amount of paperwork, and it is worth checking before you standardise on it. The LICENSE.txt file at the repository root is the text that governs.

The project also carries a MIGRATION_CARGO_MAKE_TO_MISE.md at the root, which tells you the maintainer is steering people from cargo and make installs toward mise, and that is a signal about where the install path is heading.

Where this plugin is the wrong tool

The limits are specific and mostly about scope.

It is a capacity view, not a monitoring system. The utilization column is a snapshot pulled from the Metrics API at the moment you run the command, it covers only cpu and memory, and it is off by default. If you want history, alerting or a record of how a cluster looked last Tuesday, this is the wrong tool, and the absence of a Prometheus or OpenTelemetry export in the feature list reflects that.

It is a plugin, so it needs kubectl and a working kubeconfig with permission to list nodes, namespaces and pods across the cluster. In a locked-down production cluster where developers get namespace-scoped read access, the tree view across all nodes may simply be refused, and the README does not describe a namespace-scoped mode as a separate feature.

The table output is for humans. If you need machine-readable numbers, the CSV and JSON outputs exist, but then you are writing the aggregation logic yourself, and a Prometheus query or a simple kubectl get with a JSON path will often be shorter than parsing either.

There is also a plain question of whether you need a plugin at all. The README's own framing is that most tools are limited to cpu and memory, which is the gap this fills, and the README has an Alternatives section for the cases where another tool is the better answer. The differentiator that survives scrutiny is the combination of arbitrary resources, including GPU and custom resources, with combinable grouping in one view.

On maintenance, the record is solid. The repository is not archived, the last push was on 2026-10-01, and the releases 3.0.1, 3.0.2 and 3.1.0 between June and September 2026 show regular versioned work on a 3.x line. The repository also carries release-plz.toml and cliff.toml for release notes and a changelog, plus a skills directory and a mise.toml, so the project is set up for a long life rather than a single release.

Editorial conclusion

Cluster operators who need to answer where the capacity went should adopt kubectl-view-allocations, because the tree view aggregates the same numbers across several axes and covers GPU and custom resources instead of stopping at CPU and memory. It is the wrong tool if you need live utilization without installing metrics-server, and it will surprise you on a cluster with tainted control-plane nodes because those nodes are hidden unless you pass --ignore-taints. Before adopting, run it with the taint flag once and compare, decide between the tree view and the CSV and JSON output for scripting, and note that the plugin reaches the cluster read-only through the kube client and can be used as a library as well as a binary.

Frequently asked questions

Official sources

1. davidB/kubectl-view-allocations on GitHub
2. License: CC0-1.0
3. Project website
4. README
5. Releases