DEV Community

Cover image for kpm — Kubernetes rightsizing without Prometheus, history on your laptop
Hermes Rodríguez
Hermes Rodríguez

Posted on AI-assisted

kpm — Kubernetes rightsizing without Prometheus, history on your laptop

#kubernetes #devops #go #finops

AI disclosure: This article was drafted with AI assistance. I directed the outline, checked claims against the shipped v0.6.0 binary / SPEC / roadmap, and edited the final text. Any mistakes are mine.

You know the pattern. CPU and memory requests dwarf real utilization. Finance asks why the bill is fat. Ops opens kubectl top or kube-capacity, sees a snapshot, and still cannot answer “was this always oversized, or only this morning?”

Prometheus plus VPA or Goldilocks can answer that — if you already run the stack. On a bastion or laptop, that weight is often the wrong first move.

kpm (Kubernetes Pods Metrics) is a single-binary Go CLI that samples control-plane pod metrics into local SQLite, then surfaces rightsizing recommendations and charts from that history. It talks to the cluster with client-go (no kubectl subprocess). Recommendations are advisory — kpm never mutates workloads.

From kubectl top to local charts — 0.6 is what you can run today; the path to 1.0 is already sketched below.

The idea — history first

kpm flow — sample to SQLite to recommend, serve, MCP
History first: kpm sample persists Metrics into local SQLite; recommend / serve / MCP read that store. capacity and tui stay live one-shots.

Daemon ticks always persist samples when interval_seconds > 0. Notify, MCP, and HTTP charts are optional facades on top of that store — Core stays lean.

Copy the .db to a laptop, run kpm serve, and you get analyze-local charts with no sample loop required. If kubeconfig still works, you can enrich with live Metrics; if not, history alone is enough.

What ships today (through v0.6.0)

Surface What you get
Core kpm sample → SQLite; backup; export; retention
Insights Offline recommend (p95 vs requests/limits); live capacity; TUI with Δ vs last recommend
Notify Multi-sink alerts on daemon ticks
MCP Read-only tools over stdio or HTTP/SSE
Server kpm serve — workload cards, time windows, oversized / undersized badges, JSON API, GitOps patch copy/download (never applied)

What’s new in 0.6 — analyze-local charts

  • Workload cards + summary strip (oversized / undersized / ok / no-req)
  • Mode chip live / analyze-local
  • Advisory footer — you own production resource changes

kpm serve — dark UI, oversized / undersized badges
kpm serve (dark): summary strip (6 oversized · 6 undersized) and per-card CPU/Mem verdicts. Advisory only — never applied to the cluster.

Contract and band notes live in-repo: SPECIFICATIONS.md · plan-0.6.0 · CHANGELOG.

Quick taste 

# after installing a release binary (or make build)
kpm --print-sample-config > kpm.yml
# point kube + store.path, then:
kpm sample --config ./kpm.yml          # one-shot or daemon via interval_seconds
# later, on a laptop with a copied store:
kpm serve --config ./kpm.yml           # open charts — analyze-local
Enter fullscreen mode Exit fullscreen mode

Same binary works as a kubectl plugin (kubectl kpm …) when installed with the kubectl- prefix.

kpm tui — 13 pods, cpu vs request spectrum
Live TUI (kpm tui): graded workloads in a demo namespace — idle/oversized (green) through hot/undersized (red). Same story kpm sample writes into SQLite.

Glimpse of v1.x (roadmap — not shipped yet)

Toward 1.0 the next harden band focuses on operator scale and docs, not a rewrite:

  • Node snapshots under-demand into SQLite (offline panel; not scraped every sample tick)
  • UI search / filter when you have hundreds of workload cards
  • Docs freeze + an honest compare guide (kpm vs kubectl top / kube-capacity / Prom+VPA / Goldilocks)
  • Packaging extras (Homebrew / Krew) when that band lands

Not on the v1 tease — remote Postgres / MariaDB store adapters. Core stays a SQLite file on purpose (copy the DB, analyze offline). Heavier multi-writer stores are icebox / post-1.0 if ever.

Roadmap: docs/ROADMAP.md.

Honest limits

  • Pre-1.0 — active development; use at your own risk (MIT “AS IS”)
  • Recommendations are advice; you own GitOps / cluster changes
  • History depth follows retention — not an infinite Prom TSDB
  • One process ↔ one cluster (N clusters ⇒ N configs / processes)
  • kpm is not a Prometheus replacement — it is a bastion-first rightsizing loop

Same maintainer, same rigor

kpm sits with other Hermes Projects CLIs — release-check, GHCR, cosign, SBOM — tools that already show up on awesome lists:

  • kwd — Kubernetes workload readiness watchdog
  • pgwd — PostgreSQL connection watchdog
  • kzero — bastion-first workload reset
  • groot — Kubernetes diagnostics archive
  • gghstats — GitHub traffic beyond 14 days

Young repo, not a young pipeline.

Run the bastion loop

  1. Download v0.6.0
  2. Sample into SQLite on the bastion (kpm sample)
  3. Copy the store → kpm serve on the laptop (analyze-local charts)

→ Star and try it: github.com/hrodrig/kpm

Want nodes, search, or the compare guide sooner? Open an issue or PR — that feedback steers the path to 1.0.

AI-assisted draft; human-reviewed for product accuracy (see disclosure at the top).

Top comments (0)