Kepler is the open-source power consumption monitoring tool for Kubernetes workloads — measuring per-pod energy consumption in real time using hardware performance counters and eBPF, enabling DevOps and platform engineering teams to understand, attribute, and reduce the energy footprint of cloud-native applications. As CSRD and GHG Protocol Scope 3 requirements push enterprises to measure cloud compute emissions accurately, Kepler provides the granular workload-level energy data that cloud provider billing tools cannot. This guide covers Kepler's architecture, deployment, and the GreenOps workflows it enables.
What Kepler Measures
Kepler — Measurement Architecture
Kepler (Kubernetes-based Efficient Power Level Exporter) is a CNCF sandbox project that deploys as a DaemonSet on every Kubernetes node. It uses eBPF to monitor hardware performance counters (CPU cycles, cache misses, DRAM accesses) per process, then applies ML energy models to estimate power consumption per pod and container. On nodes with RAPL (Running Average Power Limit) support (Intel/AMD servers), Kepler reads actual hardware power measurements — the highest accuracy method. On cloud VMs without RAPL access, Kepler uses its CPU utilisation model to estimate power. Metrics are exported as Prometheus time series and displayed in Grafana.
Deployment on Kubernetes
01
Step 1
Install Kepler via Helm
Add Helm repo: helm repo add kepler https://sustainable-computing-io.github.io/kepler-helm-chart && helm repo update. Install: helm install kepler kepler/kepler --namespace kepler --create-namespace. Verify DaemonSet on all nodes: kubectl get pods -n kepler. Kepler requires privileged access (eBPF and hardware counter access) — review your pod security policy before deployment in locked-down clusters. On bare metal or VMs with Intel RAPL support, confirm RAPL access: ls /sys/class/powercap/intel-rapl. Our DevOps team handles Kepler cluster deployments.
helm install keplerDaemonSet deploymentRAPL verification
02
Step 2
Connect Prometheus and Grafana
Kepler exposes metrics at :9102/metrics. Add to Prometheus scrape config: - job_name: kepler; static_configs: [{targets: ['kepler.kepler.svc.cluster.local:9102']}]. Key metrics: kepler_container_joules_total (cumulative energy per container), kepler_node_core_joules_total (CPU package energy per node). Import Kepler's official Grafana dashboard (dashboard ID 17166) for per-namespace, per-deployment energy visualisation. Carbon calculation: multiply joules × (grid carbon intensity in gCO2/Wh from Electricity Maps API) = grams CO2 per workload. Connect to your observability platform.
Prometheus scrape configkepler_container_joules_totalGrafana dashboard 17166
eBPF
Kepler's measurement mechanism — extended Berkeley Packet Filter hooks into the Linux kernel to read hardware performance counters per process with near-zero overhead. The same mechanism used by Datadog, Cilium, and other cloud-native observability tools
RAPL
Running Average Power Limit — Intel/AMD's hardware power measurement interface. On RAPL-capable hardware, Kepler reads actual power consumption values rather than estimates, providing accuracy within 3–5% of physical power meters
Per-pod
Kepler's key advantage over cloud provider carbon tools — attribution at pod/deployment level, not just account/region level. Enables "this machine learning training job consumed 2.4 kWh" rather than "this AWS account consumed 240 kWh this month"
🌱
Carbon Budget per Service
With Kepler energy data + Electricity Maps hourly grid intensity: calculate gCO2e per service per day. Set carbon budgets in your team's OKRs — "payment-service must not exceed 5 kgCO2e/month". Alert when budgets are exceeded. This creates developer accountability for energy efficiency at the workload level, the same way cost budgets create accountability for cloud spend. Add carbon metrics to your team's engineering dashboards alongside latency and error rate.
⚡
Identifying Energy-Intensive Workloads
Kepler energy data reveals which workloads consume disproportionate energy: ML training jobs with suboptimal GPU utilisation, batch jobs running longer than expected, memory-thrashing services with excessive DRAM energy consumption. Sort by kepler_container_joules_total in Grafana to identify the top 10 energy consumers. Typically, 20% of workloads account for 80% of energy consumption — focus optimisation effort on this 20% for maximum impact on both carbon footprint and infrastructure cost.
📊
CSRD Scope 3 Category 1 Attribution
For CSRD reporting: use Kepler data to accurately attribute cloud compute energy consumption by business unit or product line (vs cloud provider billing which only shows account-level data). Multiply per-workload energy × PUE × grid carbon intensity = per-workload emissions. Aggregate by namespace (each team's workloads) for organisational reporting. This granularity satisfies CSRD's requirement for reasonable accuracy in Scope 3 Category 1 reporting for cloud compute services.
🔧
Carbon-Aware Scheduling
Combine Kepler + carbon-aware-sdk + Kubernetes job scheduling to run batch workloads during low-carbon grid hours. Implement using Kubernetes CronJob triggers from a carbon-aware scheduler: the scheduler queries Electricity Maps API, determines the next 4-hour window with lowest grid carbon intensity, and triggers the batch job then. Typical carbon reduction: 20–40% for flexible batch workloads without any change to the computation. Connect to your
CI/CD pipeline for automated scheduling integration.