Hi, let us understand about replica set, in the earlier lecture we discussed about
the basics of pod, where it can have one or multiple containers and it can serve a
particular purpose atomically, but in real life whenever I am going to deploy
microservices or any applications one pod may not be sufficient enough for
high availability or for scalability when it comes to scalability I may need to have
n number of pods deployed one after the other and maintain x amount of capacity
to maintain the load and even for high availability there maybe need to deploy
the pods in different locations or in different machines in different
availability zones and maintain the number. To maintain the x amount of
capacity that is a desired number there is a controller called a replica set and
replica set generally there is no need to use it directly there is an abstract layer
called deployments thats what we will be using it, but we can go ahead and use the
replica set as well. Basically a replica sets will maintain a stable set of replica
pods running at the given time. So basically it's going to have a desired
capacity or a desired number and replica sets will maintain that desired number at
any point of time and it's going to use a template of pod that is provided and it's
going to check whether that specific pod and with the tag is available within the
cluster or not. Let's go ahead and do a small demo so I do have a yaml file, here
I am going to use kind as replica set and api version is apps/v1 and
within api version there are different type of api versions that we need to
provide and that is available as a part of the api documentation. For example
replica sets It's available as a part of the apps category, so it comes under
apps/v1 and within metadata I'm going to provide the labels and for the spec of
the replica set I'm going to provide how many number to be maintained, that we
call it as 3 and the selector it is going to check for this particular label color as
blue for all the pods basically this is what the selector it's going to use and
select whether that many number of and select whether that type of pod is
available within the cluster or not and this is what the matching criteria its
going to identify what that pod type is and it is matching that specific criteria
and meeting the replica condition or not and we do have the templates where we
have the details on what is the image to be used, so this is the image to be used
and what is the name of that specific pod and what label to be used when the pod
is getting created. So this is the entire yaml file I'm going to apply this Yaml file
and create the replica set, kubectl apply -f replicaset -phpcolor.yaml
is the yaml file and the replica set would get created. I can check whether the
replica set is available or not using the command kubectl get rs. So here I do
have the replica set and the desired capacity is 3 and currently there are
3 available and all 3 are ready. Now let me go ahead and get the pods I do have
three pods up and running and all the pods will be having this particular label
that we had marked it as selector. Let me go ahead and delete a pod and see what
happens? So I'm going to use the command kubectl delete pod and let me
select a pod from the replica set, so the pod is ending with the file is getting
deleted. Now let me get the pods check dpwx5 got deleted and one another pod
got started that is around 14 seconds ago and I can get the status of the
replica set where it will maintain desired capacity. So what this means is whenever
a pod is getting deleted or getting terminated for some reason
automatically the replica set will take care of starting the pod and meeting the
desired capacity. This is where the maintaining the load or the order scaling
all going to work and this will be applicable in terms of blue-green
deployment as well as auto scaling as well as high availability deployment of
the applications this replica set will be internally used. That's why I mentioned
initially replica set will not be used directly and that will be used as a subset
within the deployments or in auto scaling and internally it is going to maintain the
desired number of capacity say if the desired capacity is 3 it's going to start
that many number of pods, even if anyone pod gets terminated for some
reason automatically using the template the similar pod would get started and
when it comes to replica set we can go ahead and start the pod manually and
match the labels as per the selector that we have defined as a part of the
replica set and automatically it will get inducted into the replica set and it will try
to match the desired capacity, if it is not matching it will try to match the desired
capacity by starting more pods or by deleting the pods. The same way we can
do the scaling up of the replica set and lot other options available within the
replica set I can go ahead and remove a specific pod from the replica set as well
but as we discussed earlier internally working with the replica set may not be
required most of the time we will be working against the deployment or the
auto-scaling. Anyway as a part of advanced discussion we will have
detailed discussion on how to update the replica set in runtime and change the
replica values all such options we will be seeing it in future. So in a quick summary
we have seen a quick introduction on replica set and did a demo on replica set
how to start a replica set and what's going to happen to the pods with the
desired capacity within the replica sets and what will happen to the replica set
when a specific pod is deleted from the replica set and how it's
going to match the desired capacity.