1 00:00:00,000 --> 00:00:10,000 Hi, let us understand about replica set, in the earlier lecture we discussed about 2 00:00:10,000 --> 00:00:16,200 the basics of pod, where it can have one or multiple containers and it can serve a 3 00:00:16,200 --> 00:00:20,666 particular purpose atomically, but in real life whenever I am going to deploy 4 00:00:20,666 --> 00:00:25,399 microservices or any applications one pod may not be sufficient enough for 5 00:00:25,400 --> 00:00:31,466 high availability or for scalability when it comes to scalability I may need to have 6 00:00:31,466 --> 00:00:35,932 n number of pods deployed one after the other and maintain x amount of capacity 7 00:00:35,933 --> 00:00:42,299 to maintain the load and even for high availability there maybe need to deploy 8 00:00:42,300 --> 00:00:46,200 the pods in different locations or in different machines in different 9 00:00:46,200 --> 00:00:50,333 availability zones and maintain the number. To maintain the x amount of 10 00:00:50,333 --> 00:00:55,833 capacity that is a desired number there is a controller called a replica set and 11 00:00:55,833 --> 00:01:00,999 replica set generally there is no need to use it directly there is an abstract layer 12 00:01:01,000 --> 00:01:06,133 called deployments thats what we will be using it, but we can go ahead and use the 13 00:01:06,133 --> 00:01:11,266 replica set as well. Basically a replica sets will maintain a stable set of replica 14 00:01:11,266 --> 00:01:16,432 pods running at the given time. So basically it's going to have a desired 15 00:01:16,433 --> 00:01:21,399 capacity or a desired number and replica sets will maintain that desired number at 16 00:01:21,400 --> 00:01:27,700 any point of time and it's going to use a template of pod that is provided and it's 17 00:01:27,700 --> 00:01:33,033 going to check whether that specific pod and with the tag is available within the 18 00:01:33,033 --> 00:01:40,199 cluster or not. Let's go ahead and do a small demo so I do have a yaml file, here 19 00:01:40,200 --> 00:01:46,966 I am going to use kind as replica set and api version is apps/v1 and 20 00:01:46,966 --> 00:01:50,666 within api version there are different type of api versions that we need to 21 00:01:50,666 --> 00:01:55,666 provide and that is available as a part of the api documentation. For example 22 00:01:55,666 --> 00:02:00,366 replica sets It's available as a part of the apps category, so it comes under 23 00:02:00,366 --> 00:02:07,999 apps/v1 and within metadata I'm going to provide the labels and for the spec of 24 00:02:08,000 --> 00:02:12,066 the replica set I'm going to provide how many number to be maintained, that we 25 00:02:12,066 --> 00:02:18,066 call it as 3 and the selector it is going to check for this particular label color as 26 00:02:18,066 --> 00:02:23,232 blue for all the pods basically this is what the selector it's going to use and 27 00:02:23,233 --> 00:02:27,433 select whether that many number of and select whether that type of pod is 28 00:02:27,433 --> 00:02:32,566 available within the cluster or not and this is what the matching criteria its 29 00:02:32,566 --> 00:02:37,732 going to identify what that pod type is and it is matching that specific criteria 30 00:02:37,733 --> 00:02:44,099 and meeting the replica condition or not and we do have the templates where we 31 00:02:44,100 --> 00:02:48,866 have the details on what is the image to be used, so this is the image to be used 32 00:02:48,866 --> 00:02:54,199 and what is the name of that specific pod and what label to be used when the pod 33 00:02:54,200 --> 00:02:59,800 is getting created. So this is the entire yaml file I'm going to apply this Yaml file 34 00:02:59,800 --> 00:03:07,066 and create the replica set, kubectl apply -f replicaset -phpcolor.yaml 35 00:03:07,066 --> 00:03:11,999 is the yaml file and the replica set would get created. I can check whether the 36 00:03:12,000 --> 00:03:20,000 replica set is available or not using the command kubectl get rs. So here I do 37 00:03:20,000 --> 00:03:24,800 have the replica set and the desired capacity is 3 and currently there are 38 00:03:24,800 --> 00:03:32,200 3 available and all 3 are ready. Now let me go ahead and get the pods I do have 39 00:03:32,200 --> 00:03:37,600 three pods up and running and all the pods will be having this particular label 40 00:03:37,600 --> 00:03:43,233 that we had marked it as selector. Let me go ahead and delete a pod and see what 41 00:03:43,233 --> 00:03:48,299 happens? So I'm going to use the command kubectl delete pod and let me 42 00:03:48,300 --> 00:03:53,966 select a pod from the replica set, so the pod is ending with the file is getting 43 00:03:53,966 --> 00:04:03,466 deleted. Now let me get the pods check dpwx5 got deleted and one another pod 44 00:04:03,466 --> 00:04:09,666 got started that is around 14 seconds ago and I can get the status of the 45 00:04:09,666 --> 00:04:15,366 replica set where it will maintain desired capacity. So what this means is whenever 46 00:04:15,366 --> 00:04:19,399 a pod is getting deleted or getting terminated for some reason 47 00:04:19,399 --> 00:04:24,100 automatically the replica set will take care of starting the pod and meeting the 48 00:04:24,100 --> 00:04:30,233 desired capacity. This is where the maintaining the load or the order scaling 49 00:04:30,233 --> 00:04:34,033 all going to work and this will be applicable in terms of blue-green 50 00:04:34,033 --> 00:04:38,433 deployment as well as auto scaling as well as high availability deployment of 51 00:04:38,433 --> 00:04:42,999 the applications this replica set will be internally used. That's why I mentioned 52 00:04:43,000 --> 00:04:47,933 initially replica set will not be used directly and that will be used as a subset 53 00:04:47,933 --> 00:04:54,199 within the deployments or in auto scaling and internally it is going to maintain the 54 00:04:54,200 --> 00:04:59,366 desired number of capacity say if the desired capacity is 3 it's going to start 55 00:04:59,366 --> 00:05:03,566 that many number of pods, even if anyone pod gets terminated for some 56 00:05:03,566 --> 00:05:09,399 reason automatically using the template the similar pod would get started and 57 00:05:09,400 --> 00:05:14,833 when it comes to replica set we can go ahead and start the pod manually and 58 00:05:14,833 --> 00:05:19,766 match the labels as per the selector that we have defined as a part of the 59 00:05:19,766 --> 00:05:24,999 replica set and automatically it will get inducted into the replica set and it will try 60 00:05:25,000 --> 00:05:29,600 to match the desired capacity, if it is not matching it will try to match the desired 61 00:05:29,600 --> 00:05:35,966 capacity by starting more pods or by deleting the pods. The same way we can 62 00:05:35,966 --> 00:05:40,232 do the scaling up of the replica set and lot other options available within the 63 00:05:40,233 --> 00:05:44,999 replica set I can go ahead and remove a specific pod from the replica set as well 64 00:05:45,000 --> 00:05:49,266 but as we discussed earlier internally working with the replica set may not be 65 00:05:49,266 --> 00:05:52,832 required most of the time we will be working against the deployment or the 66 00:05:52,833 --> 00:05:56,566 auto-scaling. Anyway as a part of advanced discussion we will have 67 00:05:56,566 --> 00:06:01,399 detailed discussion on how to update the replica set in runtime and change the 68 00:06:01,400 --> 00:06:06,133 replica values all such options we will be seeing it in future. So in a quick summary 69 00:06:06,133 --> 00:06:10,533 we have seen a quick introduction on replica set and did a demo on replica set 70 00:06:10,533 --> 00:06:14,966 how to start a replica set and what's going to happen to the pods with the 71 00:06:14,966 --> 00:06:19,132 desired capacity within the replica sets and what will happen to the replica set 72 00:06:19,133 --> 00:06:23,433 when a specific pod is deleted from the replica set and how it's 73 00:06:23,433 --> 00:06:26,733 going to match the desired capacity.