WEBVTT 00:05.280 --> 00:08.550 Hello and welcome to this lecture on cooperative controllers. 00:08.580 --> 00:14.070 My name is Swampscott Manabat, but in this lecture we will discuss about Kubernetes controllers. 00:14.910 --> 00:17.610 Controllers are the brains behind Kubernetes. 00:17.850 --> 00:23.100 They are the processes that monitor Kubernetes objects and respond accordingly. 00:23.820 --> 00:30.660 In this lecture, we will discuss about one controller in particular, and that is the replication controller. 00:33.110 --> 00:37.700 So what is a replica and why do we need a replication controller? 00:38.300 --> 00:43.370 Let's go back to our first scenario where we had a single pod running our application. 00:44.090 --> 00:50.360 What if, for some reason our application crashes and the pod fails, users will no longer be able to 00:50.360 --> 00:55.700 access our application to prevent users from losing access to our application? 00:56.000 --> 01:00.830 We would like to have more than one instance or pod running at the same time. 01:01.400 --> 01:08.330 That way, if one feels we still have our application running on the other one, the replication controller 01:08.330 --> 01:16.760 helps us run multiple instances of a single pod in the covenant is cluster, thus providing high availability. 01:17.690 --> 01:23.450 So does that mean you can't use a replication controller if you plan to have a single pod? 01:24.290 --> 01:24.680 No. 01:25.130 --> 01:32.600 Even if you have a single pod, the replication controller can help by automatically bringing up a new 01:32.600 --> 01:34.790 pod when the existing one fails. 01:35.450 --> 01:42.440 Does the replication controller ensures that the specified number of pods are running at all times, 01:42.440 --> 01:44.350 even if it's just one or? 01:46.540 --> 01:52.630 Another reason we need a replication controller is to create multiple pods to share the load across 01:52.630 --> 01:52.870 them. 01:53.350 --> 02:00.340 For example, in this simple scenario, we have a single pod serving a set of users when the number 02:00.340 --> 02:01.820 of users increase. 02:01.840 --> 02:06.280 We deploy additional pod to balance the load across the two pods. 02:07.250 --> 02:13.670 If the demand further increases and if we were to run out of resources on the first node, we could 02:13.730 --> 02:17.690 deploy additional parts across the other nodes in the cluster. 02:18.230 --> 02:24.500 As you can see, the replication controller spans across multiple nodes in the cluster. 02:24.890 --> 02:31.640 It helps us balance the load across multiple paths on different nodes, as well as scale our application 02:31.970 --> 02:33.650 when the demand increases. 02:35.350 --> 02:42.310 It's important to note that there are two similar terms replication controller and replicas set. 02:43.120 --> 02:46.390 Both have the same purpose, but they are not the same. 02:47.230 --> 02:53.650 Replication controller is the older technology that is being replaced by replicas set properly. 02:53.650 --> 02:57.580 How set is the new recommended way to set up replication? 02:58.300 --> 03:04.960 However, whatever we discussed in the previous few slides remain applicable to both these technologies. 03:05.590 --> 03:10.390 There are minor differences in the way it works, and we will look at that in a bit. 03:11.110 --> 03:18.100 As such, we will try to stick to replica sets in all of our demos and implementations going forward. 03:19.330 --> 03:22.840 Let us know look at how we create a replication controller. 03:23.680 --> 03:29.260 As with the previous lecture, we start by creating a replication controller definition file. 03:29.920 --> 03:33.520 We will name it Dash to finish definition, thought Yamal. 03:34.520 --> 03:43.250 As with any Kubernetes definition file, we have four sections the API version, kind metadata and spec. 03:44.150 --> 03:51.170 The API version is specific to what we are creating in this case, replication controller is supported 03:51.170 --> 03:56.840 in Kubernetes API version V1, so we will set it as V1. 03:57.650 --> 04:01.010 The kind, as we know is a replication controller. 04:01.980 --> 04:04.410 Under metadata, we will add a name. 04:04.590 --> 04:07.650 And we will call it my app, Dash RC. 04:08.040 --> 04:12.840 And we will also add a few labels, app and type and assign values to them. 04:13.770 --> 04:18.690 So far, it has been very similar to how we created a pod in the previous section. 04:19.410 --> 04:26.520 The next is the most crucial part of the definition file, and that is the specification written aspect. 04:27.400 --> 04:33.550 For any Kubernetes, this definition file, the spec section defines what's inside the object we are 04:33.550 --> 04:34.120 creating. 04:34.630 --> 04:41.140 In this case, we know that the replication controller creates multiple instances of a pod. 04:41.980 --> 04:50.620 But what part we create a template section under spec to provide a pod template to be used by the application 04:50.620 --> 04:52.690 controller to create replicas. 04:53.850 --> 04:56.940 Now, how do we define the template? 04:57.390 --> 05:02.430 It's not that hard because we have already done that in the previous exercise. 05:03.240 --> 05:07.980 Remember, we created a pod definition file in the previous exercise. 05:08.490 --> 05:13.380 We could reuse the contents of the file to populate the template section. 05:14.440 --> 05:20.900 Move all the contents of the pod definition file into the template section of the replication controller. 05:21.250 --> 05:25.000 Except for the first few lines which are API version and kind. 05:26.060 --> 05:32.600 Remember, whatever we move must be under the template section, meaning this should be intended to 05:32.600 --> 05:37.790 the right and have more spaces before them than the template line itself. 05:38.570 --> 05:41.780 They should be children of the template section. 05:42.890 --> 05:47.480 Looking at our file now, we now have two metadata sections. 05:47.810 --> 05:57.320 One is for the replication controller and another for the pod, and we have to inspect sections one 05:57.320 --> 05:57.920 for each. 06:02.320 --> 06:08.980 We have nested to definition files together, the replication controller being the parent and the pod 06:08.980 --> 06:10.660 definition being the child. 06:11.790 --> 06:13.830 Now there is something still missing. 06:14.220 --> 06:20.040 We haven't mentioned how many replicas we need in the replication controller for that. 06:20.250 --> 06:26.820 Add another property to the spec called replicas and input the number of replicas you need under it. 06:27.330 --> 06:34.710 Remember that the template and replicas are direct children of spec sections, so they are siblings 06:34.710 --> 06:40.740 and must be on the same vertical line, which means having equal number of spaces before them. 06:41.800 --> 06:48.480 Once the file is ready, run the CubeSat, he'll create command and input the file using the Dash F 06:48.490 --> 06:49.240 parameter. 06:49.900 --> 06:54.670 The replication controller is created when the replication controller is created. 06:54.970 --> 07:01.090 It first creates the part using the part definition template as many as required, which is three in 07:01.090 --> 07:05.990 this case to view the list of created replication controllers. 07:06.010 --> 07:12.010 Run the cube set to get replication controller command and you will see the replication controller listed. 07:12.670 --> 07:18.460 We can also see the desired number of replicas or parts, the current number of replicas, and how many 07:18.460 --> 07:20.260 of them are ready in the output. 07:21.040 --> 07:26.580 If you would like to see the pods that were created by the replication controller run the cubes, it'll 07:26.680 --> 07:29.920 get pods command and you will see three parts running. 07:30.700 --> 07:36.910 Note that all of them are starting with the name of the replication controller, which is my app that 07:36.910 --> 07:42.760 rc indicating that they are all created automatically by the replication controller. 07:44.320 --> 07:47.410 What we just saw was the replication controller. 07:47.650 --> 07:49.660 Let us now look at replica set. 07:50.170 --> 07:53.800 It is very similar to a replication controller as usual. 07:54.340 --> 07:58.300 First, we have ARPA version kind metadata and spec. 07:58.480 --> 08:00.910 The APA version, though, is a bit different. 08:01.090 --> 08:08.290 It is APS V1, which is different from what we had before for application controller, which was just 08:08.290 --> 08:08.860 V1. 08:09.400 --> 08:13.570 If you get this wrong, you are likely to get an error that looks like this. 08:14.080 --> 08:21.220 It would say no match for kind replica set because the specified Kubernetes API version has no support 08:21.220 --> 08:22.210 for replica set. 08:23.860 --> 08:25.660 The kind would be a replica set. 08:26.200 --> 08:29.740 And we add name and labels in the metadata. 08:33.190 --> 08:37.120 The specifications section looks very similar to the application controller. 08:37.330 --> 08:41.890 It has a template section where we provide pod definition as before. 08:42.460 --> 08:47.770 So I'm going to copy contents over from our definition file and we have a number of replicas, which 08:47.770 --> 08:48.670 is set to three. 08:49.360 --> 08:54.490 However, there is one major difference between a replication controller and replica set. 08:54.940 --> 08:58.330 Replica set requires a selector definition. 08:58.960 --> 09:05.020 The selector section helps the replica set identify what parts fall under it. 09:06.410 --> 09:10.400 But why would you have to specify what parts fall under it? 09:10.520 --> 09:15.380 If you have provided the contents of the definition, file itself in the template? 09:16.650 --> 09:24.270 It's because replica set can also manage parts that were not created as part of the replicas had creation. 09:24.870 --> 09:31.680 Say, for example, there were parts created before the creation of the replicas said that matched labels 09:31.680 --> 09:33.240 specified in the selector. 09:33.660 --> 09:38.940 The replica set will also take those parts into consideration when creating the replicas. 09:39.880 --> 09:46.060 I will elaborate this in the next slide, but before we get into that, I would like to mention that 09:46.060 --> 09:52.780 the selector is one of the major differences between Réplication controller and Replicas said the selector 09:52.780 --> 09:59.110 is not a required field in case of a replication controller, but it is still available when you skip 09:59.110 --> 10:01.360 it, as we did in the previous slide. 10:01.540 --> 10:06.670 It assumes it to be the same as the labels provided in the pod definition file. 10:07.450 --> 10:14.080 In case of Replica said, a user input is required for this property and it has to be written in the 10:14.080 --> 10:17.260 form of match labels, as shown here. 10:17.950 --> 10:24.430 The match labels selectors simply matches the labels specified under it to the labels on the part. 10:24.910 --> 10:32.110 The Replicas said selector also provides many other options for matching labels that were not available 10:32.110 --> 10:33.760 in the replication controller. 10:35.570 --> 10:41.270 And as always, to create a replica set, run the Cube CTL create command, providing the definition 10:41.270 --> 10:48.320 file as input and to see the created replicas run the cubes that'll get replicas it command. 10:48.980 --> 10:52.460 To get list of pods, simply run the cube control. 10:52.790 --> 10:54.020 Get Parts Command. 10:56.120 --> 10:59.030 So what is the deal with labels and selectors? 10:59.540 --> 11:02.660 Why do we label our parts and objects in Kubernetes? 11:03.170 --> 11:10.840 Let us look at a simple scenario say we deployed three instances of our front end web application as 11:10.850 --> 11:11.720 three parts. 11:12.700 --> 11:18.610 We would like to create a replication controller or replica set to ensure that we have three active 11:18.610 --> 11:19.960 parts at any time. 11:20.710 --> 11:24.160 And yes, that is one of the use case of replica sets. 11:24.310 --> 11:31.360 You can use it to monitor existing pods if you have them already created, as is in this example. 11:32.290 --> 11:36.370 In case they were not created, the replica set will create them for you. 11:37.270 --> 11:43.330 The role of the replica set is to monitor the pods and if any of them were to fail, deploy new ones. 11:43.930 --> 11:48.670 The replica set is, in fact a process that monitors the pods. 11:49.570 --> 11:51.870 Now, how does the replica said no? 11:51.910 --> 11:53.440 What parts to monitor? 11:53.920 --> 11:58.450 There could be hundreds of other parts in the cluster running different applications. 11:59.400 --> 12:04.160 This is where labelling our parts during creation comes in handy. 12:05.950 --> 12:13.120 We could now provide these labels as a filter for replicas set under the selector section, we used 12:13.120 --> 12:18.250 to match labels filter and provide the same label that we used while creating the pods. 12:19.120 --> 12:23.200 This way, the replicas set knows which pods to monitor. 12:24.210 --> 12:31.290 The same concept of labels and selectors is used in many other places throughout Kubernetes. 12:33.280 --> 12:39.550 Now, let me ask you a question along the same lines in the replica set specifications section, we 12:39.550 --> 12:44.530 learned that there are three sections template replicas and the selector. 12:45.250 --> 12:51.010 We need three replicas and we have updated our selector based on our discussion in the previous slide. 12:52.020 --> 12:57.780 Say, for instance, we have the same scenario as in the previous slide, where we have three existing 12:57.780 --> 13:04.380 parts that were created already, and we need to create a replica set to monitor the parts to ensure 13:04.680 --> 13:10.780 there are a minimum of three running at all times when the replication controller is created. 13:10.800 --> 13:17.700 It is not going to deploy a new instance of Pod, as three of them with matching labels are already 13:17.700 --> 13:18.300 created. 13:19.400 --> 13:26.570 In that case, do we really need to provide a template section in the replica sets specification since 13:26.570 --> 13:30.920 we are not expecting the replicas to create a new port on deployment? 13:31.910 --> 13:39.170 Yes, we do, because in case one of the parts were to fail in the future, the replica set needs to 13:39.170 --> 13:46.330 create a new one to maintain the desired number of pods and for the replica set to create a new port. 13:46.580 --> 13:49.880 The template definition section is required. 13:52.150 --> 13:58.420 Let's now look at how we scale the replica set, say we started with three replicas and the future we 13:58.420 --> 13:59.950 decided to scale to six. 14:00.580 --> 14:04.450 How do we update our replica said just kill to six replicas. 14:05.230 --> 14:07.030 Well, there are multiple ways to do it. 14:07.390 --> 14:12.610 The first is to update the number of replicas in the definition file to six. 14:15.290 --> 14:22.910 Then run the Cube CTL replace command to specify the same file using the Dash F parameter, and that 14:22.910 --> 14:26.090 will update the replica set to have six replicas. 14:27.250 --> 14:31.360 The second way to do it is to run the cube control scale command. 14:31.960 --> 14:38.260 Use the replicas parameter to provide the new number of replicas and specify the same file as input. 14:39.530 --> 14:45.980 You may either input the definition file or provide the replica said name in the type name format. 14:47.230 --> 14:54.130 However, remember that using the file name as input will not result in the number of replicas being 14:54.130 --> 14:56.290 updated automatically in the file. 14:56.890 --> 15:03.400 In other words, the number of replicas in the replica set definition file will still be three, even 15:03.400 --> 15:09.250 though you scaled your replica set to have six replicas using the cube control scale command and the 15:09.250 --> 15:10.510 file as input. 15:11.540 --> 15:18.260 There are also options available for automatically scaling the replica set based on load, but that 15:18.260 --> 15:21.860 is an advanced topic and we will discuss it at a later time. 15:23.220 --> 15:25.320 That is now review the command's real quick. 15:26.310 --> 15:32.610 The cube control create command, as we know, is used to create a replica set or basically any object 15:32.610 --> 15:38.880 in Kubernetes, depending on the file we are providing as input, you must provide the input file using 15:38.880 --> 15:40.320 the Dash F parameter. 15:41.560 --> 15:46.990 Use the cube control, get command to see a list of replicas that's created, used to cube control, 15:46.990 --> 15:52.360 delete replicas at command followed by the name of the Republic are set to delete the replicas set. 15:53.020 --> 15:59.470 And then we have the control replace command to replace or update the replica set and also the cube 15:59.470 --> 16:00.910 control scale command. 16:01.090 --> 16:06.100 Scale replica set simply from the command line without having to modify the file. 16:07.750 --> 16:09.010 That's it for this lecture.