We often talk about "Green Software" in the abstract. Today, let's implement it in YAML. Using KEDA (Kubernetes Event-driven Autoscaling), we can configure our clusters to listen to the electrical grid. This allows us to implement a "Pause on Dirty" policy for heavy, delay-tolerant workloads like video rendering, AI model re-training, or log compaction.

The Architecture

1. Source: The grid's carbon intensity (gCO2/kWh) is fetched via the Carbon Aware SDK (connecting to WattTime or ElectricityMaps).

2. Trigger: KEDA polls this metric every minute.

3. Action: If intensity > Threshold, scale to 0. If intensity < Threshold, scale to N.

The Configuration

Below is a production-ready ScaledObject configuration. We use the carbon-intensity trigger introduced in KEDA 2.15.

YAML

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: carbon-aware-etl-worker
  namespace: data-engineering
spec:
  scaleTargetRef:
    name: etl-processor
  # Polling interval (seconds)
  pollingInterval: 300
  # Cooling period: Don't flap up/down too quickly
  cooldownPeriod: 600
  minReplicaCount: 0
  maxReplicaCount: 50
  triggers:
    - type: carbon-intensity
      metadata:
        # The region where the cluster resides
        region: "us-east-1"
        # The "Dirty" Threshold: 400 gCO2/kWh
        emissionThreshold: "400"
        # Strategy: Pause the workload entirely if above threshold
        handler: "pause"
  # Fallback: If the carbon API fails, default to 5 replicas
  fallback:
    failureThreshold: 3
    replicas: 5

Key Implementation Details

1. The handler Strategy: We chose pause. This means if the grid is dirty, minReplicaCount becomes 0. Alternatively, you could use scaleDown to reduce capacity linearly as intensity rises, but for batch jobs, binary on/off is usually more efficient.

2. The Fallback Mechanism: External APIs fail. The fallback section is critical. If KEDA cannot reach the carbon data provider, we default to replicas: 5 to ensure business continuity, rather than staying stuck at 0.

3. Multi-Trigger Scaling: You can combine this with other triggers. For example, you can scale based on carbon-intensity AND rabbitmq-queue-depth. This ensures you only process the queue when both the queue is full AND energy is clean.

Conclusion: Carbon-aware scaling is the ultimate "set it and forget it" GreenOps win. It requires zero code changes to your application—only a change to your deployment manifest.