kubmin
by ksctl
The kubmin dispatch Vol. 02 · The Missing Test Unit tests pass. Chaos drills survive. Nobody measures what the release costs to run. Kubmin is that missing check.
Kubmin measures every release in your environment, on your configuration — cost, energy, and SCI/SEE carbon, divided by your application's own measurement unit: the requests it served, the jobs it ran. Then it points at the fix — idle time, a better region, a better instance type.
But which release made the bill worse? You can't answer that.
Unit tests, integration suites, even chaos drills — every release clears the pipeline. But no stage measures what that release consumes: CPU, memory, energy, money. Efficiency regressions ship behind green checkmarks, and the waste compounds with every deploy.
Cloud calculators and vendor benchmarks price an idealized app. Your bill comes from your environment — your configuration, your instance types, your region, your traffic. A cost model that wasn't measured there is a guess.
40% CPU says nothing about work done. Cost per request does. Without a functional unit, dashboards are trivia — you can't compare two releases honestly, justify an optimization, or report carbon the way SCI intends.
We ran redis-benchmark across versions 8.6.1, 8.4.0, and 8.2.1. Here's what kubmin found — no other tool surfaces this.
8.4.0 uses 87.8% CPU but isn't the most expensive. 8.2.1 uses 51.2% CPU but costs more. No single metric tells the full story — you need cost, energy, and efficiency together. That's what kubmin gives you.
This is one workload. Imagine what kubmin finds across your entire cluster.
Try It On Your Workloads reproduce this demo yourselfFive capabilities, one ledger — cost, energy, and carbon per image version, measured in your environment. Read them in order, or jump straight to the one you came for.
Point kubmin at an image tag and get that version's full running story: hourly SCI and SEE, energy, CPU, memory — and the lifetime cost of running it as a container, from first deploy to today. Not generic pod metrics. Version-scoped truth about what each build costs and consumes in production.
Compare image versions across CPU, memory, energy, SCI, SEE, and runtime cost — per measurement unit of work. Ship a new release and know within hours whether it regressed 30% on efficiency, before the regression compounds into your bill.
For every workload, kubmin ranks alternative instance types and regions — similar or better performance at lower cost, on a cleaner grid. Recommendations are grounded in real cloud-provider data: per-region grid carbon intensity, percent renewable energy, and per-instance embodied carbon. Side-by-side tradeoffs, not guesswork.
Kubmin turns every finding — idle replicas, overprovisioned limits, cheaper instance types, greener regions — into a ranked action list with estimated monthly savings attached. Each win ships with a copy-paste kubectl command. Open the dashboard, act on the top three.
Keep your existing Prometheus, Tempo, Loki, and Grafana stack, or let kubmin deploy the missing pieces during create or import. Kubmin wires an OpenTelemetry Collector bridge for metrics, logs, and traces — plus Kepler for energy attribution — so every signal feeds the same cost and energy ledger.
A workload can show 40% CPU utilization and still be wasting energy. How? Polling loops, idle connections, inefficient memory access patterns — they all consume power without producing value. Traditional monitoring tools see 40% busy and move on. Kubmin sees the full picture — CPU usage alongside actual energy consumption over time — so you can spot the workloads where high utilization doesn't mean productive utilization.
Kubmin uses Kepler — a CNCF project — to estimate energy consumption at the container level. Kepler uses kernel-level instrumentation and ML-based models to attribute power usage per container, even in cloud environments where hardware counters aren't directly accessible.
In cloud environments, energy measurements are estimates based on ML models trained on real hardware data. They're highly reliable for relative comparison and trend analysis — which is exactly what kubmin needs. The patterns matter more than the absolute numbers.
Every application does one thing that matters — serves a request, processes a job, settles a transaction. Kubmin lets you declare that as your measurement unit with a single annotation, then divides everything by it: energy, carbon, cost.
The SCI standard (ISO/IEC 21031:2024) calls this the functional unit — the R in the formula. Kubmin calls it your measurement unit, computed next to your application from your cluster's real energy data. Not an industry average pasted into a slide.
kubmin.ksctl.com/measure: | version: 1 containers: webserver: unit: container-hour api: unit: request scope: pod metric: http_requests_total match: container: $KUBMIN_CONTAINER_NAMER is whatever your application calls work: requests served, jobs processed, transactions settled. You declare it once — kubmin divides by it forever.
Start with a new ksctl-managed cluster or import an existing EKS, AKS, GKE Standard, or self-managed Kubernetes cluster. Managed imports discover clusters by cloud and region; self-managed imports use kubeconfig.
Connect existing Prometheus, Tempo, Loki, and Grafana endpoints, or let Kubmin deploy the missing pieces. Kubmin always installs the agent, Kepler, Gateway API, and an OpenTelemetry Collector bridge.
Point your apps at Kubmin's in-cluster OTLP gRPC or HTTP endpoint. Kubmin turns metrics, logs, traces, and Kepler energy data into workload cost, efficiency, SCI/SEE, and Quick Wins.
Imported clusters must have cert-manager installed and healthy. Kubmin installs Gateway API CRDs during import and configures the Kubmin agent, Kepler, and OpenTelemetry Collector automatically.
Kubmin doesn't replace your monitoring stack. It connects cluster onboarding, OpenTelemetry, energy, and workload cost intelligence around it.
| AWS Cost Explorer | Kubecost | Prometheus + Grafana | kubmin | |
|---|---|---|---|---|
| 01 Cost & energy profile per image version | Manual | Hourly + lifetime | ||
| 02 Image version comparison (efficiency diff) | Yes | |||
| 03 SCI + SEE per measurement unit (ISO/IEC 21031) | Yes | |||
| 04 Energy consumption per workload | Manual | Kepler built-in | ||
| 05 Region & instance-type recommendations | Partial | Cost + grid carbon | ||
| 06 Idle workload detection | Basic | Manual | Auto | |
| 07 Ready-to-use kubectl fixes | Ranked by $/mo | |||
| 08 Per-container cost tracking | EC2 only | Est. | Manual | Yes |
| 09 Existing cluster import | Manual | Manual | EKS/AKS/GKE + kubeconfig | |
| 10 Guided observability setup | Manual | Bring yours or deploy | ||
| 11 OpenTelemetry logs/traces/metrics bridge | Manual | OTEL Collector | ||
| 12 Setup time | N/A | ~30 min | Hours/Days | Minutes to create/import |
Kubmin doesn't replace your monitoring stack. It sees what your monitoring stack can't — the energy layer that drives real waste, plus the release context that turns metrics into action.
Fixed monthly pricing. No per-node fees. No surprise bills. All plans include the Kubmin agent, Kepler energy insights, and Guided Observability with OpenTelemetry Collector.
No hidden fees · Cancel anytime · Bring your stack or let Kubmin deploy one
Energy measurement powered by Kepler — kernel-level container energy attribution
Kubmin installs an OpenTelemetry Collector bridge for OTLP metrics, logs, and traces while keeping Prometheus, Tempo, Loki, and Grafana optional.
SCI-aligned sustainability scoring built on the GSF specification
Cluster management powered by ksctl — fully open source on GitHub
Sign up free. Connect a cluster. See your waste in minutes.
Join us on this journey — the future of software is measured.
Honest answers, no marketing fluff. If we don't have the answer here, ask in Discord.