Create a model and mainfest for Kubernetes clusters

[srini1978]

Story

As a user, I want to calculate the environmental impact of Kubernetes Clusters

Rationale

Kubernetes computing is a cloud-based model where the cluster infrastructure manages pods/nodes being allocated, enabling developers to write and deploy code without worrying about the underlying infrastructure. This idea is to generate a manifest file and model that could be used to calculate the energy and carbon consumed by the cluster infrastructure.

Scope

This is a manifest file. See here for examples and here for a manifest writing tutorial.

Implementation guidelines

• The manifest MUST be a single .yaml file
• The manifest file MUST have all the required fields described here
• The manifest MUST define the necessary inputs required for the calculation
• The manifest MUST include all necessary models in a pipeline
• The manifest MUST define the expected outputs and their units
• The manifest SHOULD include comments showing which models are necessary but currently unavailable
• The manifest SHOULD include some documentation in a separate README explaining the execution flow, and any known problems or missing components.

Difficulty

5/5

Impact

5/5

Examples and resources

IMPL writing guide

[jawache]

Is this like an importer plugin for Kubernetes @ srini1978? We'd need something to grab observations from Kubernetes; I don't think Kubernetes has some built-in metrics monitoring capabilities, however.

There is another question about what you are measuring: the pods and clusters or the applications running on the pods?

This may be less of a plugin for IF and more of a Content prize. Figure out how to measure a Kubernetes cluster (in its many forms) and write a tutorial on it. I'm super confused re: kubernetes and if there was a tutorual on how to measure kubernetes using IF that would be very interesting.

This could also be expanded out into we need tutorials for how to measure X framework on Impact Framework.

What do you think?

[joachimvermeir]

We have a similar requirement, but we wanted to start by collecting/using the metrics that are available for the underlying Kubernetes nodes (VM scale set).
Given the azure importer already does this for a single VM, it should be possible to extend this to VM scale sets.

Could that be a first approach?

[jawache]

@joachimvermeir If you are asking if you can use the Azure Importer to grab observations about VMs, sure, that should be possible (I think, but I am not sure if the updates for that plugin to get multiple VM data will be ready in time for the hack, @srini1978?)

Suppose this is about building a Kubernetes plugin vs. writing documentation about using existing plugins to measure a Kubernetes cluster. What do we want this Kubernetes plugin to do?

My first gut instinct is to figure out how to compute Kubernetes using existing plugins (i.e., make this a content/documentation/tutorial project), then figure out where that is non-optimal, and then write plugins to streamline the parts of that flow that are not great. There is both a lot of interest and a lot of confusion about measuring Kubernetes using IF.

Some questions I have in my head from past conversations on this topic are:

• Measuring a Kubernetes cluster/pod can be easy, but does knowing the amount of emissions of a cluster/pod give you any helpful information?
• If the valuable information for a developer is at the process level, then does the fact it's running in a Kubernetes cluster even matter? Do you get the CPU utilization of the processes and ignore that it's being run in Kubernetes?

[joachimvermeir]

@jawache I understand what you mean.
We are using a kubernetes cluster to host multiple applications. While the underlying VMs will indeed give us the amount of emissions for the entire cluster (in Azure without control plane VMs), this will however not tell us the emission per application.
Using kubernetes metrics we could maybe split this for the different applications but it's much more complex as for example we always have a spare node in the cluster to avoid the delay of setting up a new node when required. This means the emissions of these spare nodes should also be distributed across the applications. Or do we just ignore the overhead (like the spare nodes, the kubernetes control plane VMs) but then you have a mismatch between the different ways of measuring.

So indeed it's very unclear what we actually want to measure: the full cluster (including the control plane, spare capacity) or individual deployments/applications + the overhead separately. Does it make sense to include the overhead if you are comparing/measuring on an application level?

In our case I think we will include the emissions based on the VMs (including control plane) if we want to have our global emission, but to compare applications we will have to look at the consumption in the cluster (but then indeed ignore that it is in Kubernetes, it's not relevant anymore at this point as you stated)

[jawache]

Does it make sense to include the overhead if you are comparing/measuring on an application level?

From an SCI calculation perspective, yes. Although I can't quite find the language in the text right now, the intention was to include idle capacity (hot backups) and things like that; it's in the software boundary section since those are things we'd expect people to optimize, esp. at the cloud level.

But how do you account for that in a k8 env? Since there is spare capacity, that capacity might be allocated to different applications.

IF does two things really: it helps measure the impact of individual components (vms/containers) but also allows you to group components together so that when the impacts are aggregated up, you can see how the impact is spread across different groupings of things and over time. It's just a big tree of data where the VMs/containers/processes are the roots, and then you can group things however you want to up the tree.

So maybe the k8 solution here is less about measuring the components and more about how to group things in ways that are useful with a k8 implementation, like perhaps like so:

• root
  • k8
    • control plane
    • spare capacity
    • other k8s stuff that crosses application boundaries.
  • application-1
  • application-2
  • application-3

Theoretically, you could, in another manifest file, show the same set of applications being run on raw VMs with no K8s, like so:

• root
  • application-1
  • application-2
  • application-3

What I would expect in this scenario is:

• The k8s manifest file should have fewer emissions than the no-k8s file (maybe!)
• In the no-k8s manifest file, each application has to handle its own scaling (or won't and will just have lots of idle capacity dedicated to just this application), so I'd then expect each application in the no-k8s manifest file to have larger emissions than the equivalent application in the k8s manifest file.

Something like that, perhaps?