Your release passed the pipeline. Now find what got worse.
Which image version raised estimated workload cost, used more energy per request, or wasted more resources? Kubmin shows you after it runs.
Within hours, Kubmin compares estimated workload cost, CPU, and memory by image version, alongside energy, SCI, and SEI per request, job, or transaction. Then it ranks fixes by estimated impact.
Kepler (CNCF)/SCI-aligned · SEI provisional/EKS/AKS/GKE/K3s/Kubeadm/OpenTelemetry
kubmin.ksctl.com
estimated workload cost·runtime evidence by image version·SCI carbon + SEI energy·ranked fixes by estimated impact
The Problem · ch. 01
A green pipeline can hide runtime regressions .
Which image version raised estimated workload cost, energy per unit of work, or idle waste? Billing totals don't isolate it.
Three gaps Kubmin closes after deployment.
01
blind spot
Green Tests, Costlier Runtime
Tests check behavior before deploy. Kubmin compares CPU, memory, energy, and estimated workload cost after each version runs.
02
blind spot
Your Workload, Your Numbers
Generic calculators start with assumptions. Kubmin uses your cluster, region, instance types, and workload telemetry to build a runtime cost estimate.
03
blind spot
Every Metric, Per Unit of Work
CPU alone cannot show efficiency. Kubmin normalizes energy and carbon by requests, jobs, transactions, or your own functional unit, with estimated workload cost alongside.
See It In Action · field test
Three Redis versions. Same workload. Wildly different efficiency.
Same benchmark, three image versions. Kubmin exposes the tradeoffs across CPU, memory, energy, SCI, SEI, and estimated workload cost.
kubmin.ksctl.com/workloads/compareall
fig. 01
63%
more CPU — 8.4.0 vs 8.2.1
(243m vs 149m)
fig. 02
33%
more energy — 8.4.0 vs 8.6.1
(0.0085 vs 0.0064 kWh)
fig. 03
$81
annualized runtime cost estimate gap — 8.6.1 vs 8.4.0
($0.0389 vs $0.0297/hr median)
fig. 04
29%
lower energy intensity — 8.2.1 vs 8.4.0
on SEI (0.007197 vs 0.010104 kWh/container-hour)
CPU alone misses the tradeoff. Redis 8.4.0 recorded the highest P95 CPU at 243m yet the lowest median cost estimate at $0.0297/hr. Redis 8.2.1 recorded 149m CPU but $0.0389/hr. Kubmin puts cost estimates, energy, and efficiency side by side.
One reproducible workload. The same release-level view for every version you track.
Compare instance types and regions by estimated workload cost, grid carbon intensity, renewable-energy share, and embodied carbon.
estimated −$52.71/mo on one workload
kubmin.ksctl.com/workloads/analyse
ch. 02d · estimated savings, not just alerts
Quick Wins, Ranked by Impact
Turn idle replicas, overprovisioned limits, and placement options into a ranked list of estimated monthly savings.
ranked by estimated $/mo
kubmin.ksctl.com/workloads/analyse
ch. 02e · bring your stack or create one
Guided Observability
Keep Prometheus, Tempo, Loki, and Grafana, or let Kubmin deploy what is missing. OpenTelemetry and Kepler feed one release-level view of estimated workload cost and energy.
prometheus · tempo · loki · grafana · otel
kubmin.ksctl.com/clusters/import/observability
why energy · ch. 03
CPU tracks activity. Energy reveals consumption.
CPU tells you how busy a workload was, not how much useful work it completed. Put CPU, energy, and requests on the same timeline and idle loops, polling, and zero-work periods stand out.
fig. 03 · one node, 24 hoursutilization vs energy vs work
energy — demand over time cpu — resource activity requests served — useful work
CPU and energy move together, but energy does not fall to zero when requests stop. Nodes still power memory, system services, and the platform. Divide that baseline by work completed and idle waste becomes visible.
Kubmin uses Kepler — a CNCF project — for container-level energy attribution. Kepler reads hardware counters when available and uses hardware-trained models when they are not, which is common in cloud environments.
a note on accuracy
Energy is observed from hardware counters where available and modeled elsewhere. Compare like-for-like workloads, infrastructure, sampling windows, and model versions; treat modeled values as estimates, not meter-grade measurements.
An hourly cost estimate is generic. Per request, it's yours.
Define the work your app does — request, job, transaction, or custom metric — with one annotation. Kubmin returns energy, SCI, and SEI per unit, with its workload cost estimate alongside.
declare work in your own vocabulary
request transaction job container-hour custom
ISO/IEC 21031:2024 calls this the functional unit — R in the SCI formula. Kubmin calls it your measurement unit and computes each result beside the workload from cluster energy, carbon, and pricing inputs.
Same workload, same moment; only the grid changes. SCI moves. SEI doesn't. Here's why.
SCI · carbon per requestgCO₂e / request
grid carbon intensity — where you run SCI — follows the grid
The grid gets cleaner, so SCI falls. SCI includes where you run: carbon per request within the declared software boundary.
what it tells you How carbon-efficient is this release? A cleaner grid or a more efficient image can both improve SCI.
SEI · energy per requestkWh / request
grid carbon intensity — excluded from SEI SEI — energy per functional unit
SEI stays flat because grid carbon is not part of the metric. It tracks facility energy per request.
what it tells you Did this release use more energy for the same work? SEI isolates energy efficiency from the grid.
Get Started · ch. 04
Three steps to release intelligence
01
step
Import a Kubernetes Cluster
Import EKS, AKS, GKE Standard, or self-managed Kubernetes.
02
step
Choose Your Observability Path
Connect Prometheus, Tempo, Loki, and Grafana, or let Kubmin deploy what is missing. Kubmin adds its agent, Kepler, Gateway API, and OpenTelemetry Collector.
03
step
Run a Release. See What Changed.
Point your apps at Kubmin's in-cluster OTLP gRPC or HTTP endpoint. Kubmin compares image versions and ranks changes in estimated workload cost, energy, and resource efficiency.
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.
The Fit · ch. 05
How Kubmin fits after deployment
Kubmin complements billing, Kubernetes cost, and observability tools with a release-level runtime view.
Kubmin feature comparison
Cloud billing tools
Kubernetes cost tools
Metrics dashboards
kubmin
01 Primary operating view
Account/service spend
Cluster/workload allocation
Configured telemetry
Image-version runtime evidence
02 Source of cost figures
Provider billing records
Pricing + allocation model
Configured data source
Runtime cost estimate
03 Release-level comparison
Map releases to billing
Label-driven
Build with labels + queries
Built around image versions
04 Energy evidence
Add energy data
Integration-dependent
Configure energy metrics
Kepler built in
05 Carbon & energy intensity
Varies by tool
Varies by tool
Build formulas
SCI carbon · SEI energy
06 Placement analysis
Provider options
Varies by tool
Build data + rules
Region/instance tradeoffs
07 Idle analysis
Billing/resource signals
Varies by tool
Build queries + rules
Workload-level detection
08 Remediation path
Provider actions
Varies by tool
Build automation
Ranked fix estimates
09 Functional-unit normalization
Custom allocation
Varies by tool
Build queries
Annotation + application metric
10 Observability approach
Separate integration
Cluster-metrics integration
Telemetry dashboard layer
Connect or deploy backends
11 Setup approach
Connect billing scope
Deploy/connect tooling
Configure sources + queries
Import; collect runtime data
Kubmin's edge is the combined release view: estimated workload cost by image version alongside energy, SCI, and SEI per unit of work — after the release runs.
Pricing · ch. 06
Start free. Scale when you need to.
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.
Join us on this journey — the future of software is measured.
kubmin.ksctl.com · runtime evidence by image version · after it runs
addendum
Frequently asked.
Honest answers, no marketing fluff. If we don't have the answer here, ask in Discord.
Kubmin is release intelligence for Kubernetes. After an image version runs, it shows estimated workload cost, CPU, and memory by version alongside energy, SCI, and SEI per unit of work — then ranks the next actions.
Kubmin finds savings opportunities in idle workloads, overprovisioning, and instance or region choices. Each finding includes an estimated monthly impact and the specific change that would realize it.
These are workload cost estimates, not invoice data or guaranteed savings. Your bill changes only when a recommendation lets you reduce or change paid infrastructure.
AWS Cost Explorer explains AWS billing. Kubernetes cost tools allocate cluster spend. Prometheus and Grafana collect and visualize telemetry.
Kubmin connects those views around the release: image-version comparisons, Kepler energy, estimated workload cost, SCI, SEI, functional units, and ranked fixes after the workload runs.
No. Kubmin is not a pre-deploy gate today. Label and annotate the workloads you want to track, then let the release run while Kubmin collects its runtime evidence. Keep your observability stack or let Kubmin deploy the missing pieces.
Kepler uses hardware counters where available and models trained on hardware measurements elsewhere. Cloud readings are often estimates. Compare like-for-like workloads and infrastructure with the same sampling window and model; do not treat modeled energy as a meter reading.
Kubmin supports clusters created through ksctl and imported existing clusters. Managed import supports EKS, AKS, and GKE Standard. Self-managed import supports Kubernetes clusters on AWS, Azure, or Google Cloud via kubeconfig. GKE Autopilot is not included in the current import path.
Imported clusters must already have cert-manager installed and healthy. During import, Kubmin installs Gateway API CRDs and configures the Kubmin agent, Kepler, and OpenTelemetry Collector. If you do not provide Prometheus, Tempo, Loki, or Grafana endpoints, Kubmin can deploy the missing observability backends for you.
kubmin
by ksctl
The kubmin dispatch Vol. 02 · Runtime Evidence 
