RFC: Environmental Sustainability Mode / Carbon-Aware Mode

[JacobValdemar]

Abstract ("TLDR")

This RFC proposes the addition of an "Environmental Sustainability Mode" to Karpenter. When Environmental Sustainability Mode is enabled, Karpenter optimize scaling decisions based on carbon emissions. This feature will help organizations make more environmentally responsible choices when it comes to provisioning and scaling their Kubernetes clusters.

Edit (22-04-2024): I finished my master's thesis where I have implemented this. Check it out here: https://github.com/JacobValdemar/carbon-efficient-karpenter-thesis

Motivation

Climate Change is important. As the global community continues to focus on reducing carbon emissions and environmental impact, it is crucial for technology projects to align with these objectives. Data centers, where Kubernetes clusters typically run, are significant contributors to carbon emissions. Optimizing node provisioning to minimize the carbon footprint of Kubernetes clusters is becoming increasingly important.

By implementing an Environmental Sustainability Mode in Karpenter, we can empower Kubernetes Administrators to make environmentally conscious decisions when managing their Kubernetes clusters.

Proposal

When this mode is enabled, Karpenter may minimize the following two metrics (independently):

• embodied carbon emissions: Manufacturing emissions (CO₂e) amortized over instance lifetime divided by how long we use the instance
• operational carbon emissions: Carbon emitted by electricity grid to produce electricity for the instance in the region where it is used, multiplied by PUE

Usage

It could be enabled like this:

kind: Provisioner
metadata:
  name: default
spec:
  ...
  environmentalSustainability:
    enabled: true

or like this:

helm upgrade --install karpenter ...
  --set environmentalSustainability.enabled=1

I don't know what is the best solution. Any input on this?

Default?

I have been made aware, that many seem to back Karpenter's move to CNCF (kubernetes/org#4258) based on opportunities within sustainability. That could be an argument for making Karpenter sustainability-first and enabling this feature by default. In that case, it could be possible that this feature is not developed as an "optional mode", but more as an evolution of Karpenter. We would of course need to discuss the implications of that before we pursue that path. However, for now, I will assume that the feature is developed as a non-default mode.

Implementation

I will be doing the implementation as part of my master's thesis.

Possible methods:

• Using coefficients from cloud-carbon-footprint
• Using coefficients from cloud-carbon-footprint, but using carbon intensity from a data provider like Electricity Maps or WattTime though grid-intensity-go
• other ideas?

Open question: Where exactly to integrate this into Karpenter?

Naming

I am unsure about what this mode should be called. Here are the options that are currently on the table:

• Environmental Sustainability Mode: It is easy to immediately understand the purpose.
• Carbon-Aware Mode: The term Carbon-Aware is used in many alike projects, e.g. carbon-aware-keda-operator, Introduce carbon aware scaler kedacore/keda#3467. However, I am not sure that the meaning is clear if one is unfamiliar with Green Software terminology.

Resources

• Learn about Green Software
• Cloud Carbon Footprint (Cloud Carbon Emissions Measurement and Analysis Tool)
• CNCF TAG Environmental Sustainability (website)
• Threads in Slack: September 5, 2023, June 8, 2023

[ellistarn]

Open question: Where exactly to integrate this into Karpenter?

Worth exploring: #693

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[tomkerkhove]

What was the outcome on this?