 Hello. My name is Sister Sabedra. I'm a technical marketing manager at GitLab. In this segment, I'm going to cover the capability introduced in GitLab 13.5 called View Cluster Cost Management Data in GitLab. So this capability allows you to see an overview of your cluster costs and resource usage in the GitLab user interface. Our integration builds on top of the Kube cost model open source project and gives you flexible insights into various levels of your clusters. Before this capability, many users had to create their own scripts to better understand their cluster costs. Why does it matter? For customers and prospects, now as they're part of their cluster cost management, customers can now get insights into their cluster resource usage. They can also identify unusual high peaks in cost. They can save money by identifying idle clusters and either decommissioning them or consolidating workloads into underutilized clusters. And finally, this insight can help them plan and forecast for future quarters in your cloud consumption budgets. Here are some resources to learn more about this new capability. There's the documentation link. So it's a link to the issue. There's a link to the open source Kube cost model project. There's also a link to our adaptation of that Kube cost model project. And a link to examples of cost queries that you can use when querying the data related to the cost, the cloud cost. Things to follow, check out our cluster cost optimization category direction page. The link is right there. And other notes, you, in order to be able to use this capability, you need to be a maintainer of the group or project. And also you need to have organization level billing permissions in your cloud provider account, whether using GCP or Amazon or Azure. Okay, now let's move on to the demo. I have created a group called Kube cost. And I'm going to go ahead and create two projects inside of that group. The first one is called Kube cost cost model. I'm going to make it public. I'm going to create it. Next thing I'm going to do is I'm going to clone our adaptation of the Kube cost model open source project onto my local directory so that I can then import it into the project, the empty project that I just created. I'm going to go into the clone project. I'm going to go ahead and get rid of the .git directory. And I'm going to go ahead and copy these instructions to push an existing folder into this project that I just created. Very good. So once I've pushed that project, I refresh the page and you can see the contents of the project now have been uploaded to GitLab. Now I'm going to go back to the group. I have the populated project already there, Kube cost cost model. I'm going to go ahead and create a group level Kubernetes GKE cluster. I'm going to give it the name sysavedra-kubecost. Provide the project, the zone and the number of nodes. I'm going to change the zone to US East 1D. I'm going to leave three number of nodes and the machine type is going to be n1-standard2. I actually know I'm going to change that to e2-standard2. I'm going to go ahead and create the cluster and once it's created, I'm going to go ahead and start, install some applications. There it is, the cluster's started on GKE. And I'm going to start to install, I'm sorry, Ingress Asset Manager on Prometheus. Prometheus is an open source monitoring system that is, we're going to be leveraging it for this Kube cost integration. Very good. Now they are all installed. Next I'm going to make sure that I am connected to the right context and the cluster. So I get the credentials and make sure that the context is right. I'm going to create a namespace called costModel in my GKE. And then when I run a kubectl command using the YAML files in that Kubernetes sub directory, which will basically instantiate the pod in the running clusters right there, costModel, and that's the name of the pod. And it's up and running already and also Prometheus is up and running on GKE. I'm going to go ahead now and create a second project under this group kube cost. And I'm going to call it Spring Java. Make sure it's public. It's going to be an empty project like before. I already have this project in my local directory. And I'm going to be pushing it to this empty project I just created in GitLab. So I'm going to change directory to that project on my local drive. I'm going to make sure that all the files are there. And then I'm going to copy and paste the commands to push the existing folder into this empty project. Let's refresh the screen. And now we should see that this project is no longer empty. There you go. So that's the Java sample project that we're going to be deploying to GKE. So we're going to turn on autodevops. Let's just click on the continuous deployment to production. And this will start a pipeline that will compile, that will build, run a bunch of tests and deploy the application to production. Very good. So now that the pipeline is finished, let's go to operations metrics. And we want to open now the dashboard for the cube cost, which is default cost YAML. And there you go. This is the chart showing us or a graph showing us the amount of the monthly node costs for GKE in this case. And as you can see, we made a, we pushed something to production where you see that rocket. We applied a change to that environment. And we can change the range to 30 minutes if you want. And that also gives you the monthly cost a minimum, a maximum and an average. Just to make sure, let's open the running environment, the application, I'm sorry. And it's up and running. And this is the YAML for the dashboard that you just saw for cube cost. So that's all I had for this segment. So thank you very much. Hope you enjoyed it. Bye.