 Resource Requests and Limits Kubernetes provides a shared computing environment. This means that your application will be sharing resources like CPU, memory, storage and network along with other applications deployed by you or other developers. Wouldn't it be bad if your application became unresponsive because another application in your node consumes too much CPU? That's why Kubernetes provides resource requests and limits. But what's the difference between them? Resource requests are used by Kubernetes to determine which node in your cluster your application will be scheduled to run. This means that if your application requests two CPUs, then only those nodes with at least two CPUs available can be used by your application. The Kubernetes scheduler uses the resource request to balance the workload within your cluster and they represent the minimum requirement for your application. Resource limits, on the other hand, represent the maximum amount of resources that your application can use in a given node. Suppose you specify that the memory limit for your application is one gigabyte of memory and your application tries to consume more than that. In that case, your pod will be terminated so that it doesn't impact other applications. If you specify a CPU limit, Kubernetes will throttle your application only to consume their part of the total CPU time. Let's take a look at how resource requests and limits work. First, let's check this YAML file. You can see that this YAML file contains this new section called resource requests and I'm requesting 300 megabytes and 10 cores of total CPU. So what happens when I try to apply this file? You can see in the bottom of my screen that Kubernetes already tried to schedule my pod execution, but the status is pending. And why is that pending? Let's take a look at the status of or the events of this particular pod. You can see that this pod can't be scheduled because I have a warning and say, well, zero of one nodes are available because I have insufficient CPU. So when the amount of resource request is higher than the number of available resources, Kubernetes won't be able to schedule my container or my pods. Let's take a look at how resource requests and limits work. First, let's check this YAML file. You can see that this YAML file contains this new section called resource requests and I'm requesting 300 megabytes and 10 cores of total CPU. So what happens when I try to apply this file? You can see in the bottom of my screen that Kubernetes already tried to schedule my pod execution, but the status is pending. And why is that pending? Let's take a look at the status of or the events of this particular pod. You can see that this pod can't be scheduled because I have a warning and say, well, zero of one nodes are available because I have insufficient CPU. So when the amount of resource request is higher than the number of available resources, Kubernetes won't be able to schedule my container or my pods. Now let's try to add more reasonable amount of resource requests and also try to specify a limits. Let's take a look at this new YAML file. You can see here that now I'm requesting only a quarter of a core, which is much more reasonable. And I'm also specifying the limits of 400 megabytes of total memory and one total CPU core. So what happens when I try to apply this YAML file? Because I'm requesting a much more sane amount of resource requests, now my pod is already running and it's successful. And because I specified the limits on the amount of memory that my pod can consume, what happens when my pod tries to consume more than 400 megabytes of memory? Luckily, my app has an endpoint that tries to blow up the memory inside the container, so let's see if it works. See my pod was terminated and very quickly in the bottom screen you were able to see that my pod was OOM killed. Thanks for watching. Don't forget to like this video and subscribe to our channel.