GreenOps on Kubernetes: Measuring and Optimizing CO2 Emissions per Microservice

In the IT world of 2026, sustainability is no longer just a marketing buzzword. With the expansion of EU reporting obligations (CSRD), IT decision-makers face a new challenge: they must not only estimate but accurately document the carbon footprint of their digital infrastructure.

The cloud was long considered “clean,” but the reality is more complex. An inefficiently scaling Kubernetes cluster is not only expensive but also wastes valuable energy. This is where GreenOps comes in—the discipline of integrating energy efficiency as a primary metric in the DevOps lifecycle.

From Estimation to Measurement: The eBPF Approach

Until now, it was almost impossible to determine the power consumption of a single pod in a shared cluster. You could only see the total bill of the data center. With projects like Kepler (Kubernetes-based Efficient Power Level Exporter), this has changed.

Kepler uses eBPF to read performance data directly from the kernel and hardware counters (RAPL - Running Average Power Limit).

• How it works: Kepler correlates CPU cycles, cache misses, and instructions per second with the actual energy consumption of the hardware.
• The twist: These data are exported as standard Prometheus metrics. Suddenly, a new metric appears alongside the columns for “CPU” and “RAM”: watt-hours per namespace.

Strategies for a “Greener” Cluster

Once observability is established, we can actively manage it. In the Kubernetes environment, GreenOps means three specific optimization paths:

1. Carbon-Aware Scheduling

The energy mix is not equally green at all times of the day. At noon, photovoltaics provide low CO2 values, while at night, fossil sources often prevail.

• Implementation: We use controllers that feed the cluster scheduler with real-time grid data. Non-critical batch jobs or AI training pipelines are automatically shifted to time windows when the share of renewable energy is highest.

2. Eliminating “Ghost Load” through Precise Scaling

A poorly configured cluster holds nodes that are barely used but still consume base load power.

• The solution: More aggressive downscaling using Karpenter. Instead of maintaining rigid node groups, Karpenter provisions exactly the instance types needed for the current load and actively consolidates workloads to immediately shut down unnecessary nodes.

3. Efficient Runtimes: Wasm and ARM

The choice of architecture has a massive impact on the energy balance.

• ARM Migration: Switching from x86 instances to ARM-based cloud instances (e.g., AWS Graviton) often offers up to 40% better performance per watt.
• WebAssembly (Wasm): For lightweight microservices, we are increasingly evaluating Wasm runtimes in Kubernetes. These start faster and consume almost no resources when idle compared to full-fledged Linux containers.

GreenOps is the New FinOps

The biggest advantage of GreenOps: There are no conflicts with the budget. Every watt-hour saved is a cent saved on the cloud bill. By reducing the “carbon intensity” of a microservice, we automatically optimize its code efficiency and resource allocation. GreenOps is thus the logical evolution of FinOps—with the positive side effect of a clean CO2 balance.

Conclusion: Sustainability as a Competitive Advantage

Medium-sized companies that embrace GreenOps early achieve three goals at once: They reduce their operating costs, meet future regulatory requirements, and position themselves as modern, responsible employers in the talent war.

Technical FAQ: GreenOps & K8s

Do I need to rewrite my application to use GreenOps? No. GreenOps starts at the infrastructure level. By better scheduling and choosing more efficient instance types, you save CO2 without changing a line of code. Only in the advanced phase do we look at the efficiency of the code itself (e.g., reducing unnecessary database queries).

Are managed Kubernetes offerings from providers automatically “green”? Providers often only compensate on paper (RECs). True GreenOps means reducing the actual consumption rather than just offsetting it later. Only local measurements (like with Kepler) give you true control.

What is the overhead for green monitoring? Thanks to eBPF, the overhead of tools like Kepler is extremely low (usually < 1% CPU load). The insights gained far outweigh the costs of monitoring.