GreenOps tools on Kubernetes
Kubernetes is a container orchestrator, which requires a compute. To power a compute unit, you need electricity. Creating electricity can result in carbon emissions, which is bad for the climate.
Normally a kubernetes operator would set up a monitoring stack to make sure everything is up and running smoothly. What they don't want to hear is a node went offline, because this means a service disruption, which is bad for business. This usually entails tracking cpu and memory usage, among other things, for each workload. This way, you know which workloads take up too much resources.
Turns out, cpu and memory consumption can be used to calculate your kubernetes cluster's carbon emissions. Generic formula is you translate the cpu and memory consumption into required power, then multiply it by your grid carbon intensity.
OpenCost now can display carbon costs, should work out of the box on most major cloud providers. On-prem setup should be possible, but requires extra configurations.
GreenKube also tracks cpu and memory consumption, but its main selling point is it can fetch real-time grid carbon intensity. In OpenCost the grid carbon intensity is static. The dashboard also recommends approaches to reduce kubernetes cluster carbon mission. The project is still very young, but it looks very promising.
As for reducing carbon emissions, if you can use less compute you're producing less carbon. Dynamic cluster scaling can be useful - you spend less on your cluster during non-peak hours, and scale up when you need to support more traffic. This approach is aimed at kubernetes running on cloud. Karpenter is a project you should check out if you need to implement node autoscaling.
If you're on-prem, while your compute is static (because they are physical and you only get what you have, unless you procure more hardware), you can use kube-green to shut down workloads at specific intervals to reduce cpu/memory usage. Once you set up kube-green on your cluster, apply annotation to your workloads and it's all set. This is useful if you don't need workloads to run after work hours or weekends. Especially if you have a lot of services running on runtimes that require a lot of memory up-front, scaling them down to zero can free up a lot of memory, which also means you pay less electricity bills.