 So thank you for joining me today to talk about CICD and a sustainability journey with GitOps. So have you ever wondered what is the energy consumption of the cloud-native tools that you're using or building? Actually the International Energy Agency reported in September 2022, just last month, that data centers account for 1 to 1.5% of global electricity use. That's a lot. Today I will present tools and techniques using GitOps to measure the energy consumption, to measure energy consumption of cloud architectures, but also GitOps-based architectures. In this case we'll be looking at flux. And I'll also discuss how GitOps can help with optimizations for carbon and energy emissions and energy use. So our sustainability journey starts with traditional CI, where CI and CD are tightly coupled and where when tests pass we deploy a workload. It would be great to be able to gather energy metrics about CI so that we can compare the pre-GitOps architecture to a GitOps-based architecture. However, looking at, for example, GitHub Actions, it's extremely difficult, if not impossible right now, to gather metrics. Oh, yeah. Thank you. Yeah, I'll do that. So it's very difficult because GitHub Actions' runners are AC2 instances, which are VMs running on AWS infrastructure, and we don't have access to granular real-time energy data or carbon data. Without actual data, any attempt at making any optimization would be a shot in the dark. So Q Kepler, which is a new EBPF-based tool for gathering energy metrics about any Kubernetes resource using Prometheus. First, we ask ourselves, what data do we want to gather? And Flux, in this case, is essentially for controllers in the Flux system namespace. The four controllers are the source controller, the customized controller, the notifications controller, and the Helm controller. So with this Prometheus query that you see on the screen, we are getting the sum data of the namespace of the pods running in this namespace over 24 hours. And so we are able to get this result in MealyJewels, and we can then convert this to watts and kilowatts per hour and get data about pods, namespace, the whole namespace, a whole node. We can compare this, the pod utilization in the node, et cetera. And so you can scan this barcode where I've created a repo with some scripts, some instructions on how to set up your environment. That is eBPF base, it exposes kernel headers, and you can then run Kepler and Prometheus on it and Flux to reproduce this data. The really cool thing is we can take the MealyJewels and convert them to watts, get the idle kind of energy consumption of idle Flux controllers over 24 hours, and now we can see that this is nearly 200 watts, we can see it's nearly 200 watts over 24 hours, and that's the equivalent of nearly 10 smartphones being charged according to data from the U.S. Environmental Protection Agency, which has a calculator for converting watts to relatable metrics. And so now this might seem like a lot, right? We're not using smart phones in 24 hours, but that's actually just four pods. We're just not used to seeing energy metrics about Kubernetes resources. They're not something that we can easily relate to, because we didn't have the data until now. So it might seem like a lot, but they're just four pods. Imagine what else we can do with these metrics. If we have this number, and we can use API, such as what time API, or electricity maps, to get the marginal carbon emissions index of a specific grid, and we can convert this number to the carbon emissions, like kilos of carbon emissions produced in a region, like by the Kubernetes resources that we're running. So that's pretty amazing. And what else can we do with GitOps? We can leverage one of the greatest things about GitOps, which is the declarative aspect which was intended for disaster recovery, or turning IT off and on. Once we have monitoring in place, we have the data, we can move on to optimizations, we can use metrics and GitOps with scheduling and policies. And so with this stack, we can do a lot of things related to carbon and energy optimizations. GitOps also facilitates green tools. We have a lot of tools that we're discussing the environmental sustainability tag, which was just created. Please join our meetings if you're interested in continuing the conversation. So we have energy metrics and carbon metrics, and then we can do scheduling. We can do scheduling with Carpenter, we can do scheduling with Keda, Nomad, with the new Intel Kubernetes power manager. And the next steps is to use these metrics to compare and optimize architectures running on Kubernetes. And we also need to make Kepler available in more environments, because right now it's limited by an environment that has kernel headers. This can be read-only for anyone who has security considerations in mind, which should be everyone. So yes, that's something we really need to do to make this data available everywhere. And if this is of interest, we're also forming a subgroup in the GitOps working group, open GitOps, to talk about environmental sustainability. And we hope that this format, this kind of space, is going to be created all over the CNCF ecosystem. And you can join our first meeting on the 15th of November. That's all I had. Yeah. Thank you for this.