 Kubernetes has a lot of great support for configuring the resources allocated to your deployments. In this video, we'll talk about how to identify when your deployments are over or under-provisioned, which can help you better configure their allocated resources. An over-provisioned deployment has too many resources allocated for the needs of the application. Resources here mean CPU, compute power, and memory. The downside of an over-provisioned deployment is that you may be paying for unused resources. An under-provisioned deployment has too few resources allocated for the needs of the application. An under-provisioned deployment risks performance or instability issues. Kubernetes doesn't provide default resource limits out of the box. However, most people explicitly define limits so that containers cannot consume unlimited CPU and memory. Here I'm looking at the configuration for the carts deployment. Requests define the minimum amount of resources that containers need. Limits define the max amount of resources that the container can consume. Setting limits is useful to stop over-committing resources and to protect other deployments from resource starvation. Let's look at two ways you can quickly check if your Kubernetes deployments are over or under-provisioned. Let's start with K9S, which is a great open-source project. K9S provides a terminal to interact with your Kubernetes cluster. K9S is continually watching Kubernetes for changes and offers subsequent commands to manage your observed resources. Let's use K9S to look at the CPU consumption of the pods in our cluster. Here we're on the pods page and we can see that there's one pod with really high CPU usage. For some applications, 300% CPU usage might be totally normal. You should check the resource budget that's given to this deployment in the event that you have a high number. If we press D for describe for this pod, we can scroll down and see the limits and requests, and we can see that this pod is operating at its maximum CPU budget. The most important thing to remember about CPU is that it needs to be considered with the amount that you're asking for and what the historical trends of that pod are. Let's pop over to our second tool, Pixi. Pixi is another open-source project and it's part of the CNCF. Pixi automatically collects application-level statistics using EVPF. We can use it to see things like HTTP events, SQL requests, and other types of application data without making any code changes. We've got a script here to look at memory consumption and CPU usage and request latency and throughput. Let's first look at memory consumption. We've used Pixi to compute two different values for memory consumption, resident set size and virtual memory size. Residents set size is the amount of memory currently used by your application, so we can sort that and see who's using the most. Virtual memory size is the amount of memory currently allocated to your application. So again, we can sort that. You need to look at both numbers together in order to identify memory-related provisioning problems. If the resident set size creeps up too close to the virtual memory size, that might indicate that your application needs more memory. So the exciting thing about Pixi is that it also automatically surfaces the request throughput and latency for HTTP and other protocols. So here we have HTTP request throughput and latency. If the request throughput is too low, that could indicate that our service is having trouble responding to requests in time. So you should look at throughput and conjunction with request latency in order to identify if there is a provisioning bottleneck in your application. If your request throughput is low and your latency is low, this might be an opportunity to deallocate resources from your allocation. As I mentioned before, Pixi is an open source project, so you can try it out on your own cluster, and we've included the link for the script that we've used in this video down in the description.