Kubernetes Kepler: Efficient Power Exporter

• Kubernetes Efficient Power Level Exporter (Kepler) is a cloud-native telemetry component that exports energy metrics at node and container levels to enable power-aware orchestration in Kubernetes.
• It leverages cgroup stats, eBPF tracepoints, and hardware interfaces like RAPL alongside model-training pipelines to accurately estimate power consumption across diverse workloads.
• Its metrics support various applications including custom schedulers, autoscalers, and research into power model accuracy in x86, ARM, and far-edge deployments.

Kubernetes Efficient Power Level Exporter (Kepler) is a node-level energy telemetry component for Kubernetes and a widely used Kubernetes energy exporter. It runs on every node, typically as a DaemonSet, uses cgroup/container stats from kubelet/cAdvisor, kernel instrumentation such as eBPF tracepoints and performance counters, and, when available, hardware power interfaces such as RAPL and BMC/IPMI, to estimate node and container power/energy and expose them as Prometheus metrics. In practice, Kepler occupies the observability layer between hardware energy sources and Kubernetes-native control systems: it exports per-node and per-pod energy, and these metrics can then be consumed by custom schedulers, autoscalers, policy engines, and higher-level experimentation frameworks (Huang et al., 10 Jun 2026, Thamm et al., 21 May 2026).

1. Definition and architectural role

Kepler is described both as a cloud-native exporter and as cluster-side infrastructure rather than workflow-specific tooling. Its basic deployment model is straightforward: Kepler runs on each node, Prometheus scrapes its /metrics endpoint, and the resulting time series become available for per-node and per-pod energy analysis and for downstream orchestration logic. This makes Kepler a Kubernetes-native bridge from low-level hardware and kernel signals to Prometheus-oriented control loops (Huang et al., 10 Jun 2026).

A second architectural role appears in work on robust power-model training. There, Kepler is not only an exporter but also part of a broader model-serving pipeline. On training nodes where RAPL or another power meter is available, Kepler exports resource metrics and measured power to a centralized model server. The modeler pipeline then trains system-level and container-level power models, stores them in a model database, and serves them back to production nodes that may not have power meters. The core pipeline is organized into three modules—Extractor, Isolator, and Trainer—and is explicitly integrated into Kepler’s model server component (Choochotkaew et al., 2024).

This dual role is central to Kepler’s research significance. At one level, it is an exporter for operational observability. At another, it is a platform for training, selecting, and applying power models in heterogeneous and opaque environments. This suggests that Kepler is best understood not as a single attribution formula, but as a measurement-and-modeling framework whose exported metrics can be consumed by external systems or refined by additional model-training logic.

2. Measurement sources, modes, and exported metrics

Kepler’s measurement path combines several telemetry classes. In the general description, the input sources are cgroup/container stats from kubelet/cAdvisor, kernel instrumentation through eBPF tracepoints and performance counters, and hardware power interfaces such as RAPL and BMC/IPMI when they are available. In a controlled container-level observability study, Kepler is described as operating in model-only mode, direct power mode, and hybrid configurations. In that study, platform power is read from Dell iDRAC9 through the Redfish interface, while CPU and DRAM component power is derived from RAPL (Pijnacker et al., 14 Apr 2025).

Kepler exports both node metrics and container metrics. The cited study enumerates component breakdowns for core, DRAM, package, platform, and uncore, and uses container_joules_total as a cumulative energy metric. The same study also uses container_cpu_instructions_total for timing comparison against power behavior (Pijnacker et al., 14 Apr 2025). In CODECO, the emphasis is node-level dynamic energy rather than per-pod energy. The specific Prometheus query is:

$$\text{Workload Power} = \left( \frac{\Delta\;\text{Workload CPU Time}} {\Delta\;\text{Node CPU Time}} \right)\cdot \text{Power}$$4

This query yields the increment in kepler_node_platform_joules_total over a 5-minute window for mode="dynamic", excluding idle/base power, and is interpreted as the dynamic joules consumed by that node over the last 5 minutes. The paper denotes this quantity as node energy, $N_e(i)$ (Huang et al., 10 Jun 2026).

A different perspective appears in the Nf-PEAK comparison, which focuses on the documented linear CPU-time attribution formula used for workload power:

$$\text{Workload Power} = \left( \frac{\Delta\;\text{Workload CPU Time}} {\Delta\;\text{Node CPU Time}} \right)\cdot \text{Power}$$

In that evaluation, this formula is treated as a purely linear share model: CPU-time fraction directly scales node power, without an explicit DRAM term, static/dynamic split, or non-linear utilization model (Thamm et al., 21 May 2026). By contrast, the robust-model work around Kepler’s model server uses learned system-level and container-level models and explicitly evaluates isolation goodness when generating container labels (Choochotkaew et al., 2024). The literature therefore portrays Kepler as supporting both direct sensor-driven export and model-based attribution pipelines, with different studies interrogating different layers of that stack.

3. Deployment patterns across x86, ARM, and far-edge systems

Kepler has been studied in both conventional x86 servers and far-edge ARM environments. In a CODECO far-edge deployment, the cluster is a k3s cluster with one laptop master and six Raspberry Pi 4 workers connected over Wi‑Fi (IEEE 802.11bg). Kepler is deployed as a Prometheus exporter on each node, following the standard DaemonSet pattern, and Prometheus scrapes Kepler during ACM-driven deployment (Huang et al., 10 Jun 2026).

That study is particularly important because Raspberry Pi 4 boards lack mainstream server power telemetry: no ACPI power interfaces, no IPMI/BMC sensors, and no RAPL. The operating system has eBPF support, but the BTF metadata does not expose hardware energy counters. As a result, Kepler cannot use direct hardware energy readings on those ARM boards. Instead, the authors use Kepler’s default x86-trained model, described as an Intel Xeon–based practical approximation on ARM. They explicitly state that the measurements are approximate but good enough to capture trends and compare schedulers, and that accurate ARM support would require retraining Kepler’s model for ARM (Huang et al., 10 Jun 2026).

A related requirement appears in GOXN, where the authors recommend bare metal rather than a VM or cloud provider path because of the needed low-level access to hardware information. GOXN deploys Kepler as a DaemonSet and treats its per-container energy data as the compute-energy input to a service-level model (Legler, 23 Jan 2026). CLUE likewise uses Kepler at the platform layer for pod energy consumption and notes that Kepler and Scaphandre still show some discrepancies to hardware sensors, particularly across heterogeneous hardware (Werner et al., 11 Mar 2025).

Taken together, these reports establish a recurring deployment pattern. Kepler is straightforward to deploy in Kubernetes terms, but the semantics of the exported energy depend strongly on hardware exposure, kernel hooks, and model calibration. This suggests that cross-platform deployment is operationally simple and metrologically non-trivial.

4. Orchestration, scheduling, and service-level aggregation

Kepler’s exported metrics are frequently used as first-class control inputs rather than passive dashboard signals. The clearest example is CODECO, where Kepler supplies the compute-energy side of the orchestration loop. CODECO computes a per-node greenness cost $g(i)$ from compute energy $N_e(i)$ and network energy $L_e(i)$, and passes that cost to an ILP-based scheduler. The paper defines three scheduling functions:

$g(i)=N_e(i)$

$g(i)=L_e(i)$

$g(i)=N_e(i)\cdot L_e(i)$

Here Kepler provides the $N_e(i)$ term, and the scheduler uses it for pod placement and migration under CPU stress, asymmetric network delay, and bandwidth contention (Huang et al., 10 Jun 2026).

At a different abstraction level, CLUE uses Kepler as the source of pod energy consumption at the platform layer and computes higher-level metrics such as Request Consumption and Resource Efficiency. In CLUE’s implementation, Request Consumption is calculated using the total wattage reported by Kepler for the system under test divided by the number of successful requests reported by Locust, while Resource Efficiency combines pod wattage from Kepler with pod CPU/memory utilization from the metrics server to estimate energy wasted by over-provisioned pods (Werner et al., 11 Mar 2025).

GOXN extends this aggregation logic from pods to services in microservice systems. It uses Kepler as the compute-energy source and cAdvisor as the source of network and storage bytes, then applies an additive service-level model:

$$E_{\text{service}} = E_{\text{compute}} + E_{\text{network}} + E_{\text{storage}}$$

The artifact states that excluding network and storage can underestimate auxiliary-service energy by up to $$\text{Workload Power} = \left( \frac{\Delta\;\text{Workload CPU Time}} {\Delta\;\text{Node CPU Time}} \right)\cdot \text{Power}$$0, and that high tracing loads shift energy dominance toward network and storage. In this formulation, Kepler’s contribution is the compute-energy term, aggregated from per-container or per-pod metrics to service level (Legler, 23 Jan 2026).

NeuroScaler points in the same direction from the autoscaling side. It aggregates telemetry from PDUs, bare-metal servers, VMs, and Kubernetes nodes and explicitly states that energy consumption information can be obtained from containers by using Kepler. A plausible implication is that Kepler functions as a reusable observability substrate for optimization loops that operate at scheduling, autoscaling, or service-modeling levels, provided that application-level performance metrics are supplied by other components (Chaves et al., 9 Feb 2026).

5. Model training, generalization, and federated extensions

Research around Kepler increasingly treats power estimation as a model-training problem. In the robust training framework, the Extractor converts accumulated energy to power and accumulated counters to per-second rates, the Isolator trains system power models and predicts background power for “all containers except target $$\text{Workload Power} = \left( \frac{\Delta\;\text{Workload CPU Time}} {\Delta\;\text{Node CPU Time}} \right)\cdot \text{Power}$$1,” and the Trainer fits container-level models using the isolated labels. The framework introduces isolation goodness,

$$\text{Workload Power} = \left( \frac{\Delta\;\text{Workload CPU Time}} {\Delta\;\text{Node CPU Time}} \right)\cdot \text{Power}$$2

as a model-selection criterion, and reports that the proposed model reduces average cross-validation error by about $$\text{Workload Power} = \left( \frac{\Delta\;\text{Workload CPU Time}} {\Delta\;\text{Node CPU Time}} \right)\cdot \text{Power}$$3 compared to other methods in cross-workload, cross-platform experiments (Choochotkaew et al., 2024).

A privacy-preserving extension appears in work on carbon-aware container orchestration. That paper extends Kepler with federated learning, uses Flower’s FedXgbBagging aggregation, keeps Kepler’s BPF-derived feature extraction on each client, and replaces centralized model training with local XGBoost training plus federated tree aggregation. In the reported SPECPower experiments, the final aggregated MAE is approximately 12.81, compared to a centralized XGBoost baseline MAE of 14.51, which the paper summarizes as 11.7 percent lower Mean Absolute Error than the centralized baseline (Saad et al., 4 Oct 2025).

These studies shift attention from Kepler as an exporter to Kepler as a model ecosystem. The recurring themes are background isolation, cross-platform robustness, absence of online power measurements on production nodes, and privacy-preserving collaboration across clusters. This suggests that future Kepler deployments may increasingly depend on how models are trained, selected, calibrated, and shared, rather than solely on which counter is scraped on a given node.

6. Accuracy debates, limitations, and competing approaches

Kepler’s status as a state-of-the-art tool has been accompanied by sustained scrutiny of its attribution accuracy. In Nf-PEAK, Kepler v0.8.0 is compared against a workflow-specific process-based method on Nextflow workloads. On four nodes without extra load, Nf-PEAK reports average MAPE of 6.6%, while Kepler reports 17.4%. Under co-located load with eight stressed threads, Nf-PEAK reports 10.9% and Kepler 22.5%. The same paper also reports a case where Kepler is competitive—Sarek without additional load, where Kepler’s 4.0% MAPE is close to Nf-PEAK’s 4.2%—but emphasizes that Kepler degrades more under co-located load for Sarek and Rangeland (Thamm et al., 21 May 2026).

A more direct challenge appears in “Container-level Energy Observability in Kubernetes Clusters,” which concludes that the reported energy usage metrics provided by Kepler are not at a satisfactory level for the authors’ container-level purpose. In that controlled single-node study, Kepler’s aggregated node power closely follows iDRAC PSU power and the integrated total-energy error is reported as less than 1%, but the RMSE between iDRAC and Kepler is 66.4 W because of latency and averaging effects. More significantly, the study reports persistent idle power for completed pods and dynamic power shifts to the system_processes pseudo-container when inactive pods are deleted, leading the authors to argue that container-level power attribution is not trustworthy in that scenario (Pijnacker et al., 14 Apr 2025).

These criticisms are technically specific rather than generic repudiations. They concern co-located load, short-task workflows, asynchronous sampling, idle-power distribution, and pseudo-container attribution. At the same time, other papers continue to use Kepler successfully for relative comparisons, cluster-level observability, platform-layer experimentation, and scheduling inputs, even when absolute values are approximate, as in the ARM far-edge CODECO setup (Huang et al., 10 Jun 2026).

The literature therefore supports a differentiated interpretation. Kepler is widely adopted and operationally useful for node-level and pod-level energy telemetry, and it has become a standard input to Prometheus-based experimentation and control stacks. However, container-level attribution accuracy remains an active research issue, particularly under multi-tenancy, short-lived workloads, heterogeneous hardware, and environments without direct hardware energy counters. A plausible implication is that Kepler’s long-term role will depend on how effectively its observability surface is paired with calibration, background-isolation methods, and workload-specific validation.