Tare

Pressure, not just usage

A container capped at 100m that wants 400m shows the same usage graph as a correctly sized one. Linux pressure stall information records the time a container spent waiting for a CPU, and it exists for every container, with or without a limit. Pressure above zero blocks a shrink. Zero across the whole window is what makes one safe.

Runtime ceilings

tare reads -Xmx, GOMEMLIMIT, --max-old-space-size, gunicorn workers, vLLM and Ollama flags and more, and never recommends memory below them. A JVM with a 256Mi heap sized from usage OOMKills on its next restart; tare gives it 384Mi and says why.

CPU limits are never lowered or added

On Google's Online Boutique, limits sized from usage made p95 latency 18× worse at twice the load. Sizing only the requests cut 1.6 CPU and 1 GiB with latency at baseline. So tare holds CPU limits where they are and reports it as CPU_LIMIT_HELD.

Nodes, not millicores

Recommendations are replayed through bin packing against your real nodes and placements. The headline is nodes freed, split between what tighter packing frees today and what tare's changes add on top.

Says when it cannot see

A missing signal downgrades a finding to UNVERIFIED instead of reading as zero. OOMKilled memory prints ?, not a guess. tare keeps Guaranteed pods Guaranteed, warns on HPAs that scale on utilization, and skips workloads under VPA Auto.

Its claim is not that it is clever, but that it will not confidently tell you something false. That claim is only worth the evidence behind it, so every serious defect found so far is written down: what it looked like, what it was, and how it was caught.

Install

os=$(uname -s | tr '[:upper:]' '[:lower:]')
arch=$(uname -m | sed 's/x86_64/amd64/; s/aarch64/arm64/')
curl -fsSL "https://github.com/2listic/tare/releases/latest/download/kubectl-tare_${os}_${arch}.tar.gz" | tar xz kubectl-tare
sudo install kubectl-tare /usr/local/bin/

Or go install github.com/2listic/tare/cmd/kubectl-tare@latest. Windows builds are on the releases page.

Use

$ kubectl tare report
VERDICT    CONF    NAMESPACE  WORKLOAD     CONTAINER  PODS  CPU        MEM          WHY
SATURATED  medium  prod       checkout     api        6     50m→115m   16Mi→?       OOMKILLED,CPU_PRESSURE,+1
IDLE       high    prod       legacy-sync  worker     1     500m→10m   256Mi→16Mi   IDLE_NO_WORK,IDLE_NOT_RULED_OUT
WASTE      medium  prod       static       nginx      12    1000m→10m  1.0Gi→16Mi   -

35 containers over 2w: nodes freed >=2 of 12; requests lowered on 2 (-12640m CPU, -12.3Gi mem), ...
warning  SIGNAL_NOT_MEASURED  cfs-throttle: 3 of 35 containers

stdout is data, stderr is the summary and warnings, and evidence codes are a stable API, so the table pipes as well as it reads.

kubectl tare check

Can this cluster produce a report? What is missing?

kubectl tare report --explain

The sentence behind every evidence code

kubectl tare report -o patch

kubectl patch commands to review and run

kubectl tare report -o html

One self-contained file for whoever approves

kubectl tare report -o tui

Browse findings, with per-row CPU and memory plots

kubectl tare diff --repo ./manifests

Edit manifests in place, for a pull request

kubectl tare report --demo

Simulated workloads, real analyzer, no cluster

Permissions

tare reads as you. For a service account, the bundled RBAC grants only get and list plus services/proxy. A narrower token degrades the report and says what it lost; kubectl tare check tells you which. Nothing is ever applied automatically.