Carbon-Aware Kubernetes: Scheduling for a Greener Cloud

As software engineers, we have spent decades optimizing for latency, throughput, and cost. We have become experts at squeezing every millisecond out of a request and every penny out of a cloud bill. However, a new constraint has entered the architectural conversation: carbon intensity.

Data centers currently account for approximately 1-1.5% of global electricity use. While cloud providers like AWS, Azure, and GCP have made significant strides in purchasing renewable energy credits, the physical reality of the grid remains. At any given moment, the carbon intensity of the electricity powering your servers—the grams of CO2 emitted per kilowatt-hour—fluctuates based on the mix of wind, solar, gas, and coal feeding the local grid.

This article explores how to move beyond static efficiency and implement carbon-aware workload scheduling. By combining the Green Software Foundation’s Carbon-Aware SDK with Kubernetes, we can programmatically shift non-urgent tasks to periods when the grid is cleanest.

Understanding Carbon Intensity: Average vs. Marginal

Before we dive into the implementation, we must distinguish between two types of carbon data.

Average Carbon Intensity is the mean emission rate of all power sources on the grid. While useful for high-level reporting, it is a lagging indicator.

Marginal Carbon Intensity (MCI) is what senior engineers should focus on. MCI represents the emissions of the specific power plant that would be turned up (or down) to account for a change in load. When you spin up a massive ML training job, you aren't using the "average" grid mix; you are often forcing the grid operator to spin up a "peaker" plant, which is usually gas or coal-fired. Carbon-aware scheduling aims to align compute spikes with periods of high renewable penetration, effectively lowering the marginal demand during peak emission hours.

The Carbon-Aware SDK: A Unified Interface

The Carbon-Aware SDK, maintained by the Green Software Foundation, provides a standardized way to access carbon intensity data. Instead of writing custom integrations for various data providers like WattTime or Electricity Maps, the SDK offers a unified Web API and client library.

Core Capabilities of the SDK

1. Current Intensity: Get real-time data for a specific location.
2. Forecasted Intensity: Retrieve predicted carbon intensity for the next 24-72 hours.
3. Best Window: The most valuable feature for scheduling. You provide a duration (e.g., "I need 2 hours of compute") and a time window (e.g., "within the next 12 hours"), and the SDK returns the optimal start time.

In a Kubernetes environment, the SDK is typically deployed as a service within the cluster, acting as a middleware that your controllers or cron jobs query before executing heavy workloads.

Architectural Patterns for Carbon-Awareness

Implementing carbon-aware scheduling usually falls into two categories: Temporal Shifting (moving tasks in time) and Spatial Shifting (moving tasks in space).

1. Temporal Shifting with Kubernetes CronJobs

Temporal shifting is the lowest-hanging fruit. Many batch processes—database backups, report generation, image optimization, or model retraining—are not time-critical.

Instead of a standard CronJob that runs at 2:00 AM every night, we can use a "Carbon-Aware Wrapper."

The Workflow:

1. A lightweight 'Dispatcher' pod triggers at the start of a broad window.
2. The Dispatcher queries the Carbon-Aware SDK: "When is the lowest intensity 1-hour window between now and 8:00 AM?"
3. The SDK returns the optimal timestamp.
4. The Dispatcher schedules a one-off Kubernetes Job at that specific time.

2. Dynamic Scaling with KEDA

For workloads that are queue-based, we can use KEDA (Kubernetes Event-driven Autoscaling). KEDA allows us to scale deployments based on external metrics. By creating a custom scaler or using the Prometheus scaler to ingest carbon intensity data, we can adjust the scaling threshold.

For example, during high-carbon hours, we might only process messages if the queue depth exceeds 1,000. During low-carbon hours (when solar or wind is peaking), we lower the threshold to 10, allowing the cluster to clear the backlog using greener energy.

Practical Implementation: Building a Carbon-Aware Dispatcher

Let’s look at a conceptual implementation of a Carbon-Aware Dispatcher using Python and the SDK’s Web API.

import requests
import datetime
from kubernetes import client, config

# Configuration
SDK_ENDPOINT = "http://carbon-aware-sdk.carbon-aware.svc.cluster.local/emissions/bests"
LOCATION = "eastus"
DURATION_MINUTES = 60
WINDOW_HOURS = 12

def get_optimal_window():
    now = datetime.datetime.utcnow()
    until = now + datetime.timedelta(hours=WINDOW_HOURS)
    
    payload = {
        "location": LOCATION,
        "startTime": now.isoformat(),
        "endTime": until.isoformat(),
        "duration": DURATION_MINUTES
    }
    
    response = requests.get(SDK_ENDPOINT, params=payload)
    best_window = response.json()[0]
    return best_window['timestamp']

def schedule_k8s_job(start_time):
    config.load_incluster_config()
    batch_v1 = client.BatchV1Api()
    
    # Define your Job manifest here
    # Note: In a real scenario, you'd likely use a CronJob or a custom CRD
    # to handle the delayed execution.
    print(f"Scheduling workload for {start_time}")

if __name__ == "__main__":
    optimal_time = get_optimal_window()
    schedule_k8s_job(optimal_time)

While the script above is a simplified example, it illustrates the logic. In a production-grade system, you would use a Custom Resource Definition (CRD) and a Controller. You might define a CarbonAwareJob resource that includes a maxDelay parameter. The controller would then handle the communication with the SDK and the lifecycle of the underlying Kubernetes Job.

Spatial Shifting: The Multi-Region Approach

If your organization operates across multiple cloud regions, you have the option of Spatial Shifting. This involves moving the workload to a geography where the grid is currently cleaner.

Imagine you have clusters in us-east-1 (Virginia) and eu-central-1 (Frankfurt). At 4:00 PM EST, Virginia might be relying on natural gas as people return home and turn on appliances. Simultaneously, it’s 10:00 PM in Frankfurt, where demand is lower and wind energy might be abundant.

A carbon-aware global load balancer (or a CI/CD pipeline with regional awareness) can route non-latency-sensitive batch jobs to the Frankfurt cluster. The Carbon-Aware SDK supports this by allowing multi-location queries to compare intensity across regions.

Addressing the Challenges

Implementing these patterns is not without its trade-offs. Senior engineers must account for the following:

1. Data Accuracy and Latency

Carbon intensity data is often forecasted. Like weather forecasts, they aren't always 100% accurate. Your system must be resilient to API failures from the SDK. If the SDK is down, the default behavior should be to run the job immediately or on its original schedule to avoid breaking business SLAs.

2. Resource Contention

If every company starts shifting workloads to the same "low-carbon" hour, we risk creating a new artificial peak in demand. This is why we focus on the marginal intensity. As this practice matures, we will need more sophisticated coordination between grid operators and large-scale compute consumers.

3. The "Green-Only" Trap

Carbon-awareness should never be an excuse for inefficiency. A carbon-aware but bloated application is still worse than a highly optimized, carbon-blind one. The hierarchy of sustainable engineering should always be:

1. Eliminate (Do we need this job?)
2. Optimize (Can we make it use less CPU/RAM?)
3. Shift (Can we run it when/where it's cleaner?)

Measuring Success: The SCI Score

To prove the efficacy of your scheduling, you need a metric. The Green Software Foundation defines the Software Carbon Intensity (SCI) score. Unlike total carbon footprint, which is hard to calculate due to complex offsets, the SCI focuses on the rate of emissions:

SCI = ((E * I) + M) / R

• E: Energy consumed by the software.
• I: Carbon intensity of the grid.
• M: Embodied carbon of the hardware.
• R: Functional unit (e.g., per API call, per ML training run).

By implementing carbon-aware scheduling, you are directly reducing I (Intensity) for your workloads, which lowers your SCI score even if the energy consumption (E) remains constant.

Conclusion

Carbon-aware scheduling is a shift in mindset from "compute as a constant" to "compute as a variable." By integrating the Carbon-Aware SDK with Kubernetes, we can transform our infrastructure into a dynamic system that responds to the realities of the energy grid.

Actionable Next Steps:

1. Identify Candidates: Audit your existing CronJobs and background workers. Which ones can tolerate a 4-to-12-hour delay?
2. Deploy the SDK: Run the Carbon-Aware SDK as a service in a development cluster to explore the data for your regions.
3. Start Small: Implement a simple wrapper for a single non-critical batch job and measure the delta in carbon intensity between its original and shifted execution times.
4. Automate: Move toward a controller-based approach using KEDA or a custom operator to make carbon-awareness a first-class citizen of your platform.

Our code has a physical impact. It’s time our schedulers reflected that.