1 00:00:00,490 --> 00:00:04,090 Hello and welcome to this lecture. In this lecture 2 00:00:04,090 --> 00:00:08,130 We will talk about known affinity feature in Kubernetes. 3 00:00:08,590 --> 00:00:15,920 The primary purpose of node affinity feature is to ensure that pods are hosted on particular notes. 4 00:00:15,940 --> 00:00:23,770 In this case to ensure the large data processing pod ends up on no one in the previous lecture we did 5 00:00:23,770 --> 00:00:31,950 this easily using notes selectors we discussed that you cannot provide advanced expressions like or 6 00:00:32,100 --> 00:00:40,370 or not with node selectors the node affinity feature provides us with advanced capabilities to limit 7 00:00:40,520 --> 00:00:47,000 pod placement on specific nodes with great power comes great complexity. 8 00:00:47,170 --> 00:00:55,060 So the simple node selector specification will now look like this with node affinity although both does 9 00:00:55,120 --> 00:01:04,350 exactly the same thing plays the pod on the large node let us look at it a bit closer under spec you 10 00:01:04,350 --> 00:01:12,060 have affinity and then node affinity under that and then you have a property that looks like a sentence 11 00:01:12,090 --> 00:01:19,230 called required during scheduling ignored during execution no description needed for that and then you 12 00:01:19,230 --> 00:01:25,950 have the node selector terms that is an array and that is where you will specify the key and value pairs 13 00:01:26,610 --> 00:01:36,050 the key value pairs are in the form key operator and value where the operator is in the operator ensures 14 00:01:36,110 --> 00:01:42,440 that the pod will be placed on a node whose label size has any value in the list of values specified 15 00:01:42,440 --> 00:01:46,610 here in this case it is just one called large. 16 00:01:46,910 --> 00:01:53,120 If you think your part could be placed on a large or a medium node you could simply add the value to 17 00:01:53,120 --> 00:02:02,780 the list of values like this you could use the not in operator to say something like size not in small 18 00:02:03,110 --> 00:02:08,630 where node affinity will match the node with a size not set to small. 19 00:02:08,750 --> 00:02:15,770 We know that we have only set the labels size too large and medium nodes the smaller nodes don't even 20 00:02:15,770 --> 00:02:17,270 have the labels set. 21 00:02:17,570 --> 00:02:23,810 So we don't really have to even check the value of the label as long as we are sure we don't set a label 22 00:02:23,810 --> 00:02:30,330 size to the smaller nodes using the exists operator will give us the same result. 23 00:02:30,500 --> 00:02:37,010 The exists the operator will simply check if the label size exists on the notes and you don't need the 24 00:02:37,010 --> 00:02:41,200 values section for that as it does not compare the values. 25 00:02:41,300 --> 00:02:44,570 There are a number of other operators as well. 26 00:02:44,570 --> 00:02:48,060 Check the documentation for specific details. 27 00:02:48,130 --> 00:02:55,000 Now we understand all of this and we're comfortable with creating a pod with specific affinity rules 28 00:02:55,960 --> 00:02:57,700 when the pods are created. 29 00:02:57,700 --> 00:03:02,980 These rules are considered and the pods are placed onto the right nodes. 30 00:03:02,980 --> 00:03:08,260 But what if node affinity could not match a node with a given expression. 31 00:03:08,260 --> 00:03:15,640 In this case what if there are no nodes with a label called size say we had the labels and the pods 32 00:03:15,730 --> 00:03:16,830 are scheduled. 33 00:03:16,840 --> 00:03:21,840 What if someone changes the label on the node at a future point in time. 34 00:03:21,910 --> 00:03:24,540 Will the pod continue to stay on the Node. 35 00:03:24,910 --> 00:03:31,780 All of this is answered by the long sentence like property under node affinity which happens to be the 36 00:03:31,780 --> 00:03:39,250 type of node affinity the type of node affinity defines the behaviour of the scheduler with respect to 37 00:03:39,250 --> 00:03:43,860 node affinity and the stages in the lifecycle of the pod. 38 00:03:43,940 --> 00:03:51,410 There are currently two types of node affinity available required during scheduling ignored during execution 39 00:03:51,890 --> 00:03:58,970 and preferred during scheduling ignored during execution and there are additional types of node affinity 40 00:03:59,060 --> 00:03:59,960 planed. 41 00:03:59,960 --> 00:04:07,190 As of this recording required during scheduling required during execution we will now break this down 42 00:04:07,190 --> 00:04:08,550 to understand further. 43 00:04:08,810 --> 00:04:13,090 We will start by looking at the two available affinity types. 44 00:04:13,160 --> 00:04:19,840 There are two states in the lifecycle of a pod when considering node affinity during scheduling and 45 00:04:19,850 --> 00:04:22,900 during execution during scheduling. 46 00:04:22,900 --> 00:04:28,240 Is the state where a pod does not exist and is created for the first time. 47 00:04:28,280 --> 00:04:34,730 We have no doubt that when a pod is first created the affinity rules specified are considered to place 48 00:04:34,730 --> 00:04:37,130 the pods on the right note. 49 00:04:37,130 --> 00:04:40,650 Now what if the nodes with matching labels are not available. 50 00:04:40,760 --> 00:04:44,930 For example we forgot to label the node as large. 51 00:04:44,930 --> 00:04:49,810 That is where the type of node affinity used comes into play. 52 00:04:49,970 --> 00:04:56,960 If you select the required type which is the first one the scheduler will mandate that the pod be placed 53 00:04:56,960 --> 00:04:58,980 on a node with a given affinity. 54 00:04:58,990 --> 00:05:04,520 Rules if it cannot find one the pod will not be scheduled. 55 00:05:04,530 --> 00:05:09,660 This type will be used in cases where the placement of the pod is crucial. 56 00:05:09,870 --> 00:05:13,620 If a matching node does not exist the pod will not be scheduled. 57 00:05:14,400 --> 00:05:19,180 But let's say the pod placement is less important than running the workload itself. 58 00:05:20,240 --> 00:05:26,830 In that case you could set it to preferred and in cases where a matching node is not found. 59 00:05:26,990 --> 00:05:34,150 The scheduler will simply ignore node affinity rules and place the card on any available note. 60 00:05:34,220 --> 00:05:40,640 This is a way of telling the scheduler hey try your best to place the pod on matching node but if you 61 00:05:40,640 --> 00:05:44,560 really cannot find one just plays it anywhere. 62 00:05:44,570 --> 00:05:51,410 The second part of the property or the other state is during execution during execution is the state 63 00:05:51,470 --> 00:05:58,220 where a part has been running and a change is made in the environment that affects node affinity such 64 00:05:58,220 --> 00:06:00,840 as a change in the label of a node. 65 00:06:00,920 --> 00:06:07,640 For example say an administrator removed the label we said earlier called size equals large from the 66 00:06:07,640 --> 00:06:08,980 node. 67 00:06:09,010 --> 00:06:12,910 Now what would happen to the pods that are running on the Node. 68 00:06:12,910 --> 00:06:20,230 As you can see the two types of node affinity available today has this value set too ignored which means 69 00:06:20,410 --> 00:06:29,890 pods will continue to run and any changes in node affinity will not impact them once they are scheduled. 70 00:06:29,950 --> 00:06:36,940 The new types expected in the future only have a difference in the during execution phase a new option 71 00:06:36,940 --> 00:06:43,570 called required during execution is introduced which will evict any pods that are running on notes 72 00:06:43,600 --> 00:06:46,220 that do not meet affinity rules. 73 00:06:46,480 --> 00:06:53,680 In the earlier example, a pod running on the large node will be evicted or terminated if the label large 74 00:06:53,740 --> 00:06:56,120 is removed from the node. 75 00:06:56,320 --> 00:06:58,480 Well that's it for this lecture. 76 00:06:58,480 --> 00:07:04,830 Head over to the coding exercises and practice working with node affinity rules in the next lecture. 77 00:07:04,830 --> 00:07:08,520 We will compare tables and toleration and node affinity.