Kepler Ditched eBPF for /proc — And That's a Bigger Deal Than It Sounds

Most Kubernetes operators can tell you how much CPU a Pod burns, how much memory it hoards, and how much network it chews through. Ask them how many watts it draws, and you’ll get a shrug. That gap is exactly what Kepler set out to close — and this month, the CNCF sandbox project quietly threw out its original eBPF-based architecture and rebuilt itself on plain old /proc and /sys. In sustainability tooling, that’s the equivalent of a fintech company ripping out Kafka and going back to Postgres. And they did it for a reason infra teams should care about.

Why Kepler Matters for Cloud Sustainability Right Now

According to the International Energy Agency’s Energy and AI report published in 2025, data centers accounted for 1.5% of global electricity demand in 2024, and that number is projected to roughly double to around 945 TWh by 2030 — driven in part by AI workloads. Kubernetes has no built-in way to allocate power per workload, which means most FinOps and GreenOps dashboards are guessing. Kepler fixes that by reading hardware power meters, mapping consumption to Linux processes, associating those processes to Pods, and exporting the whole thing as Prometheus metrics.

This matters because carbon accounting is quietly becoming a compliance requirement, not a nice-to-have. If you’re a platform team running a multi-tenant cluster for internal product groups, you’re about to be asked, “How much energy did the recommendations service use last quarter?” Without something like Kepler, the honest answer is a shrug wrapped in a spreadsheet. Teams building multi-tenant SaaS platforms will feel this first — usage-based billing that ignores energy is going to look increasingly primitive.

Our take: within 18 months, per-workload power attribution will be table stakes for any serious Kubernetes distribution, and Kepler is the obvious upstream candidate.

Why the Kepler Maintainers Killed eBPF

Here’s the interesting part. Kepler joined the CNCF sandbox in 2023 riding a wave of eBPF hype. eBPF was supposed to be the answer to observability — kernel-level granularity, no code changes, minimal overhead. The Kepler team used it to capture process utilization signals. And then they ripped it out.

The reasons, per the maintainers’ post, are worth quoting because they contradict a lot of the current eBPF marketing. First, eBPF required CAP_BPF and CAP_SYSADMIN privileges, which the team calls “a blocker for many production environments.” Second, they found eBPF “error-prone when it comes to tracking fine-grained, kernel-level processes at this level of accuracy” — specifically, it kept losing short-lived, terminated processes, leading to under-reported energy footprints. Third, it made the codebase harder to extend and maintain.

The rewrite uses read-only access to /proc and /sys instead. That’s it. Standard Linux, universally available, minimal privileges, boring as dirt. If you’re running a locked-down cluster where security policy forbids CAP_SYSADMIN DaemonSets — think regulated fintech, healthcare, or government workloads — you can now install Kepler via a single Helm chart without a three-week security review. Our take: this is a bellwether. Expect at least one other high-profile CNCF observability project to re-evaluate its eBPF dependency within the next year, especially as multi-tenant Kubernetes platforms tighten their capability policies.

How the New Architecture Handles Diverse Hardware

The old Kepler assumed a hardcoded RAPL power structure — core, DRAM, and “other.” The problem, as the team discovered, is that actual hardware topologies vary across CPUs, meaning Kepler was attributing energy to domains that didn’t exist on some hosts. That’s not a rounding error. That’s fabricating a ground truth.

The re-architected Kepler dynamically discovers each host’s power meter structure at runtime. It adapts to whatever RAPL domains the hardware actually exposes. For a hyperscaler or a research lab like CERN running mixed generations of Intel and AMD silicon in the same cluster, this is the difference between metrics you can trust and metrics you have to caveat in every meeting. Imagine you’re an SRE presenting energy cost per service to finance — “our numbers match what the BMC reports” is a very different conversation than “our numbers are directionally correct on some node types.”

Our take: dynamic hardware discovery is going to become the default pattern for any low-level infra tool that ships to heterogeneous fleets. Hardcoded assumptions were always a debt bomb; the arrival of custom accelerators and diverse ARM silicon just lit the fuse.

What the Accuracy Experiments Actually Prove

The post walks through two experiments. In the first, led by Laura Llinares at CERN, both Kepler versions ran simultaneously on the same bare-metal node alongside IPMI readings from the hardware BMC. Because IPMI captures the whole node — DRAM, fans, NICs, PSU losses — Kepler’s CPU-only numbers are expected to land at 40–70% of IPMI, and the shape of the curves should match under load. The new kepler_node_cpu_watts metric tracks IPMI patterns closely and eliminates the multi-kW spikes that the old counters produced, spikes that literally exceeded the ground-truth IPMI values.

The second experiment, led by Vimal Kumar at Red Hat, ran a progressive stress-ng workload and measured the gap between total node active energy and the sum of energy attributed to individual processes. The result: a Process Power Attribution Gap of essentially 0 watts, fluctuating by only a few milliwatts. The team also reports 90% test coverage on the new codebase.

Why this matters: energy metrics are only useful if you can defend them in an audit. A cost-attribution model that occasionally invents kilowatts is worse than no model at all — it erodes trust across every downstream dashboard. Our take: expect Kepler to become the reference implementation that cloud providers benchmark their own attribution models against, similar to how OpenTelemetry became the de facto spec for tracing.

Where the Community Call to Action Points

The maintainers are explicit about what they need help with. GPU power monitoring is behind an experimental flag and needs real AI/ML workloads to validate it. VM power modeling needs contributors with ML experience to retrain estimators for virtualized environments where hardware counters aren’t exposed. Bare-metal accuracy needs users with IPMI or external power meters to compare against. And idle power attribution — currently simplified out — needs to come back in a better form.

If you’re running heavy accelerator workloads or building production AI agent systems, the GPU monitoring track is where your feedback has the highest leverage right now. Same story for infrastructure operators running specialized fleets — teams building OCPP-native EV charging platforms, for example, care deeply about energy accounting across mixed hardware, and their bare-metal validation data would directly shape Kepler’s VM model.

Our take: the projects that win the sustainability tooling category won’t be the ones with the fanciest architecture — they’ll be the ones with the widest hardware validation dataset. Kepler is asking for exactly the right thing.

FAQ

Q: What is Kepler and what does it do in Kubernetes? A: Kepler is a CNCF sandbox project that reads hardware power meters, attributes energy consumption to Linux processes, maps that to Pods running in a Kubernetes cluster, and exports the results as Prometheus metrics. It gives platform teams a way to measure per-workload energy usage that Kubernetes doesn’t provide natively.

Q: Why did the Kepler team move away from eBPF? A: According to the maintainers, eBPF required elevated CAP_BPF and CAP_SYSADMIN privileges that blocked many production deployments, produced inaccurate data by missing short-lived processes, and added complex abstractions that made the codebase hard to extend. The rewrite uses read-only /proc and /sys access instead, which is universally available and needs far lower privileges.

Q: How accurate is the new Kepler compared to hardware power meters? A: In testing on a bare-metal node, the new Kepler’s kepler_node_cpu_watts metric tracked IPMI power draw patterns closely and eliminated the multi-kW spikes that the old counters produced. A separate experiment showed a Process Power Attribution Gap of essentially 0 watts, with variance measured in milliwatts.

Key Takeaways

• Platform teams should evaluate Kepler now if energy attribution is heading toward their compliance or FinOps roadmap — the /proc-based install removes the security-review blocker that stalled earlier adoption.
• The eBPF walk-back is a signal worth watching; expect other CNCF observability projects to revisit whether kernel-level tooling is worth its privilege footprint for their specific use case.
• Teams running heterogeneous hardware — mixed CPU vendors, custom accelerators, ARM alongside x86 — will benefit most from Kepler’s dynamic power topology discovery.
• If you run AI/ML workloads on GPUs, contributing validation data to the experimental GPU power monitoring feature is a high-leverage way to shape the tooling before it becomes a default.
• Usage-based billing and internal chargeback models that ignore energy will start looking outdated within a couple of release cycles; get ahead of it by wiring per-workload power metrics into cost dashboards this year.