In 2020 data centers and networks accounted for approximately 1 – 1.5% of global electricity use according to the International Energy Agency (IEA). While advancements in data center efficiency and the use of renewable energy have helped slow greenhouse gas emissions, the IEA believes emissions from data centers needs to halve by 2030. This future reduction is needed while demand for these services is only expected to grow.
Members of the Cloud Native Computing Foundation (CNCF)’s Environmental Sustainability Technical Advisory Group (TAG) addressed this issue on stage in the Kubecon Chicago keynote. The TAG’s mission is to “advocate for, develop, support, and help evaluate environmental sustainability initiatives in cloud native technologies.”
I enjoyed the topic on stage enough that I invited Niki Manoledaki, Software Engineer at Grafana Labs and member of the Environmental Sustainability TAG to join me for a deeper dive.
The entire conversation was enlightening, but in particular I left my time with Manoledaki curious to know more about the Kepler project.
Kepler stands for Kubernetes-based Efficient Power Level Exporter. It’s a sandbox project in the CNCF, donated in 2023 after being “founded by Red Hat’s emerging technologies group with early contributions from IBM Research and Intel.”
Understanding the carbon intensity of cloud workloads is particularly challenging because most cloud providers do not expose power usage metrics through the hypervisor in their virtual machines. The Kepler project is designed to help end users to better “estimate power consumption at the process, container, and Kubernetes pod levels.”
Because there is no direct way to measure the power that a VM consumes in a cloud environment, Kepler uses ePBF to probe for CPU performance counters and Linux kernel tracepoints. These metrics are correlated the appropriate pod using cGroup stats. These data points are fed into machine learning models to estimate data about workload power usage where concrete information is not available. This information can then be exported as Prometheus metrics.
Kepler utilizes a BPF program integrated into the kernel’s pathway to extract process-related resource utilization metrics. Kepler also collects real-time power consumption metrics from the node components using various APIs … Once all the data that is related to energy consumption and resource utilization is collected, Kepler can calculate the energy consumed by each process. This is done by dividing the power used by a given resource based on the ratio of the process and system resource utilization.1
Is Kepler Enough?
In short, no.
While it’s good to start to build some transparency into cloud compute power usage, we still have a long way to go on the path to sustainable cloud computing.
Per my conversation with Manoledaki, runtime energy accounts for only a small component of total energy use.
With carbon monitoring, the issue is we have scope one, scope two and scope three emissions. Scope one are direct emissions, scope two are indirect emissions, and scope three are everything else in the supply chain in the manufacturing process. And we know that in the cloud, it’s estimated that 70 to 90% of the carbon emissions are scope three. So they are from the supply chain of software from the manufacturing. And this is data that we as cloud users are lacking to a certain extent. So yes, runtime energy consumption is a small part of the equation.
In addition to checking out the Kepler project, there are many potential starting points for those interested in better understanding their energy use in the cloud.
- Cloud providers provide some carbon footprint details in their consoles and APIs (AWS, Google Cloud, Azure)
- The Green Software Foundation is building a Software Carbon Intensity Index and trying to make it an ISO standard
- The FinOps Foundation is targeting the overlap of where cost saving are complementary to carbon reduction.
- Those who were inspired by Manoledaki’s message can join her in the CNCF slack community in the #tag-environmental-sustainability channel.
Related: Read more about why RedMonk thinks eBPF is interesting
Disclaimer: AWS, Google Cloud, IBM, Intel, Microsoft, and Red Hat are RedMonk clients. Grafana Labs and the CNCF are not, though CNCF paid my travel expenses to their conference.
Neither the video nor this accompanying piece were sponsored, and as always this work reflects RedMonk’s own opinions.
- Exploring Kepler’s potentials: unveiling cloud application power consumption, Marcelo Amaral, Sunyanan Choochotkaew, Eun Kyung Lee, Huamin Chen, and Tamar Eilam ↩