WEBVTT 00:00.630 --> 00:03.270 Hello and welcome to this lecture. 00:03.270 --> 00:04.540 My name is Mumshad 00:04.560 --> 00:14.180 Mannambath. Let us look at a 3 Node Kubernetes cluster. Each node has a set of CPU, Memory and Disk 00:14.180 --> 00:15.890 resources available. 00:16.310 --> 00:19.190 Every POD consumes a set of resources. 00:19.190 --> 00:27.470 In this case 2 CPUs , one Memory and some disk space. Whenever a POD is placed on a Node, it consumes resources 00:27.620 --> 00:35.330 available to that node. As we have discussed before, it is the kubernetes scheduler that decides which 00:35.330 --> 00:43.380 Node a POD goes to. The scheduler takes into consideration, the amount of resources required by a POD 00:43.760 --> 00:51.170 and those available on the Nodes. In this case, the scheduler schedules a new POD on Node 2. If the node 00:51.170 --> 00:58.370 has no sufficient resources, the scheduler avoids placing the POD on that node Instead places the POD 00:58.460 --> 01:05.060 on one where sufficient resources are available if there is no sufficient resources available on any 01:05.060 --> 01:10.970 of the nodes, Kubernetes holds back scheduling the POD, and you will see the POD in a pending state. 01:11.450 --> 01:19.550 If you look at the events, you will see the reason – insufficient cpu. Let us now focus on the resource 01:19.550 --> 01:25.740 resource requirements for each POD. What are these blocks and what are their values? 01:25.740 --> 01:33.750 By default, kubernetes assumes that a POD or a container within a POD requires .5 CPU & 01:33.750 --> 01:37.310 256 Mebibyte of memory. 01:37.410 --> 01:44.790 This is known as the resource request for a container the minimum amount of CPU or memory requested 01:44.790 --> 01:49.630 by the container when the scheduler tries to place the pod on a node. 01:49.650 --> 01:55.740 It uses these numbers to identify a node which has sufficient amount of resources available. 01:56.160 --> 02:02.760 Now if you know that your application will need more than these you can modify these values by specifying 02:02.760 --> 02:09.370 them in your pod or deployment definition files in the simple pod definition file. 02:09.480 --> 02:18.260 add a section called resources, under which add requests and specify the new values for memory and cpu usage. 02:18.480 --> 02:24.600 In this case I set it to 1GB of memory and 1 count of vCPU. 02:24.660 --> 02:28.060 So what does 1 count of CPU really mean? 02:28.200 --> 02:33.010 Remember these blocks are used for illustration purposes only. 02:33.030 --> 02:36.440 It doesn't have to be in the increment of point five. 02:36.570 --> 02:42.570 You can specify any value as low as 0.1. 0.1 02:42.600 --> 02:49.720 CPU can also be expressed as 100m were m stands for milli. 02:49.920 --> 02:59.400 You can go as low as 1m, but not lower than that. 1 count of CPU is equivalent to 1 vCPU. 02:59.400 --> 03:09.510 That’s 1 vCPU in AWS, or 1 Core in GCP or Azure or 1 Hyperthread. You could request a higher number 03:09.510 --> 03:16.800 of CPUs for the container, provided your Nodes are sufficiently funded. Similarly, with memory you could 03:16.800 --> 03:26.470 specify 256 Mebibyte using the Mi suffix. Or specify the same value in Memory like this. Or use the 03:26.470 --> 03:29.130 suffix G for a gigabyte. 03:29.140 --> 03:37.450 Note the difference between G and Gi. G is Gigabyte and it refers to a 1000 Megabytes, whereas Gi 03:37.450 --> 03:44.540 Gi refers to Gibibyte and refers to 1024 Mebibyte. 03:44.590 --> 03:47.970 The same applies to megabyte and kilobytes. 03:48.580 --> 03:55.000 Let's now look at a container running on a node in the docker world a docker container has no limit 03:55.090 --> 04:02.680 to the resources it can consume on a Node. Say a container starts with 1 vCPU on a Node, it can go up 04:02.860 --> 04:10.060 and consume as much resource as it requires, suffocating the native processes on the node or other containers 04:10.210 --> 04:11.740 of resources. 04:11.770 --> 04:17.800 However you can set a limit for the resource usage on these pods by default. 04:17.980 --> 04:26.830 Kubernetes sets a limit of 1vCPU to containers. So if you do not specify explicitly, a container will be limited 04:26.920 --> 04:30.520 to consume only 1 vCPU from the Node. 04:30.520 --> 04:37.810 The same goes with memory. By default, kubernetes sets a limit of 512 Mebibyte on containers. 04:38.260 --> 04:44.200 if you don't like the default limit you can change them by adding a limit section under the resources 04:44.200 --> 04:51.460 section in your pod definition file. Specify new limits for memory and cpu you like this when the 04:51.460 --> 04:55.960 pod is created, kubernetes sets new limits for the container. 04:55.960 --> 05:02.580 Remember that the limits and requests are set for each container within the pod. 05:02.650 --> 05:08.470 So what happens when a pod tries to exceed resources beyond its specified limit. 05:08.470 --> 05:16.080 In case of the CPU, kubernetes throttles the CPU so that it does not go beyond the specified limit. 05:16.420 --> 05:20.910 A container cannot use more CPU resources than its limit. 05:20.950 --> 05:28.720 However, this is not the case with memory. A container CAN use more memory resources that its limit. 05:28.720 --> 05:35.800 So if a pod tries to consume more memory than its limit constantly, the POD will be terminated. 05:35.890 --> 05:39.340 Well that's it for this lecture on resource requirements in kubernetes. 05:39.340 --> 05:45.880 Head over to the coding exercises section and practice viewing configuring and troubleshooting 05:46.300 --> 05:49.310 resource requirements in kubernetes. 05:49.330 --> 05:51.520 Thank you and I will see you in the next lecture.