Hello and welcome to this lecture on Cuba.
It is controllers.
My name is Mom child Mohamed.
In this lecture we will discuss about Cuban it is controllers.
Controllers are the brains behind Cuban interests.
They are the processes that monitor Cuban natives objects and respond accordingly.
In this lecture we will discuss about one controller in particular and that is the replication controller.
So what is a replica and why do we need a replication controller.
Let's go back to our first scenario where we had a single pod running our application.
What if for some reason our application crashes and the pod fails.
Users will no longer be able to access our application to prevent users from losing access to our application.
We would like to have more than one instance or pod running at the same time.
That way if one failed we still have our application running on the other one.
The replication controller helps us run multiple instances of a single pod in the cabinet as cluster
thus providing high availability so does that mean you can't use a replication controller if you plan
to have a single pod.
No.
Even if you have a single pod the replication controller can help by automatically bringing up a new
pod when the existing one fails.
Thus the replication controller ensures that the specified number of parts are running at all times
even if it's just one or 100 another reason we need a replication controller is to create multiple paths
to share the load across them.
For example in this simple scenario we have a single pod serving a set of users when the number of users
increase.
We deploy additional pod to balance the load across the two parts if the demand further increases and
if we were to run out of resources on the first node we could deploy additional pods across the other
nodes in the cluster.
As you can see the replication controller spans across multiple nodes in the cluster.
It helps us balance the load across multiple paths on different nodes as well as scale our application.
When the demand increases it's important to note that there are two similar terms replication controller
and replay cassette.
Both have the same purpose but they're not the same replication controller is the older technology that
is being replaced by replicate set properly has said is the new recommended way to setup replication.
However whatever we discussed in the previous few slides remain applicable to both these technologies.
There are minor differences in the way each works and we will look at that in a bit.
As such we will try to stick to replicable sets in all of our demos and implementations going forward.
Let us now look at how we create a replication controller.
As with the previous lecture we start by creating a replication controller definition file we will name
it our C dash to finish thought Jamil as with any Cuban Interest definition file.
We have four sections the API version kind metadata and spec the API version is specific to what we
are creating in this case replication controller is supported in Coburn it is API version V1.
So we will set it as v1 the kind as we know is a replication controller under a metadata we will add
a name and we will call it my ab dash RC and we will also add a few labels app and type and assign values
to them.
So far it has been very similar to how we created a pod in the previous section.
The next is the most crucial part of the definition file and that is the specification written as spec
for any Cuban it is definition file.
The spec section defines what's inside the object we are creating.
In this case we know that the replication controller creates multiple instances of a part but what part
we create a template section under spec to provide a part template to be used by the replication controller
to create replicas now how do we define the part template.
It's not that hard because we have already done that in the previous exercise.
Remember we created a pod definition file in the previous exercise.
We could reuse the contents of the file to populate the template section move all the contents of the
pod definition file into the template section of the replication controller except for the first few
lines which are API version and kind remember whatever we move must be under the template section meaning
this should be intended to the right and have more spaces before them.
Then the template line itself they should be children of the template section looking at our file.
Now we now have two method metadata sections.
One is for the replication controller and another for the pod and we have two aspects sections one for
each.
We have nested to definition files together.
The replication controller being the parent and the part definition being the child.
Now there is something still missing.
We haven't mentioned how many replicas we need in the replication controller for that.
Add another property to the spec called replicas and input the number of replicas you need under it.
Remember that the template and replicas are direct children of spec sections so they are siblings and
must be on the same vertical line which means having equal number of spaces before them once the file
is ready run the cubes GTL create command and input the file using the dash f parameter the replication
controller is created when the replication controller is created it first creates the part using the
part definition template as many as required which is 3.
In this case to view the list of created replication controllers run the cube CDL get replication controller
command and you will see the replication controller listed we can also see the desired number of friendly
cars or parts the current number of friendly cars and how many of them are ready in the output.
If you would like to see the parts that were created by the replication controller run the cube CDL
get parts command and you will see three parts running.
Note that all of them are starting with the name of the replication controller which is my ab dash RC
indicating that they are all created automatically by the replication controller what we just saw was
the replication controller let us now look at replica set it is very similar to replication controller
as usual first we have API version kind metadata and spec the API version though is a bit different
it is apps slash to be one which is different from what we had before for application controller which
was just V1 if you get this wrong you are likely to get an error that looks like this it would say no
match for kind replica set because the specified carbonates API version has no support for replica set
the kind would be replicas set and we add name and labels in the metadata
the specification section looks very similar to replication controller it has a template section where
we provide part definition as before.
So I'm going to copy the contents over from part definition file and we have number of replicas which
is set to three.
However there is one major difference between replication controller and replica set has set requires
a selector definition the selector section helps the replica set identify what parts fall under it but
why would you have to specify what parts fall under it.
If we have provided the contents of the part definition file itself in the template it's because replicas
set can also manage parts that were not created as part of the replica at creation.
Say for example the reports created before the creation of the replica set that match labels specified
in the selector.
The replica set will also take those parts into consideration when creating the replicas.
I will elaborate this in the next slide but before we get into that I would like to mention that the
selector is one of the major differences between replication controller and replica set the selector
is not a required field in case of a replication controller but it is still available when you skip
it as we did in the previous slide.
It assumes it to be the same as the labels provided in the part definition file in case of replica said
a user input is required for this property and it has to be written in the form of match labels as shown
here.
The match labeled selector simply matches the labels specified under it to the labels on the part.
The replica set selector also provides many other options for matching labels that were not available
in the replication.
Controller and as always to create a replica set.
Run the cube CTF and create command providing the definition file as input and to see the created replicas
run the cubes TTL get replica set command to get list of parts simply run the cube control get parts.
Command.
So what is the deal with labels and selectors.
Why do we label our parts and objects in corporate entities.
Let us look at a simple scenario.
Say we deployed three instances of our front end web application as three part.
We would like to create a replication controller or replica set to ensure that we have three active
parts at any time.
And yes that is one of the use case of replica sets.
You can use it to monitor existing parts.
If you have them already created as cities in this example in case they were not created the replica
set will create them for you.
The role of the replica set is to monitor the parts and if any of them were to fail deploy new ones.
The replica set is in fact a process that monitors the parts.
Now how does the replica set.
No.
What part to monitor.
There could be hundreds of other parts in the cluster running different applications.
This is where labelling our parts during creation comes in handy we could now provide these labels as
a filter for replica set under the selector section we use to match labels filter and provide the same
label that we used while creating the parts.
This way the replica set knows which parts to monitor the same concept of labels and selectors is used
in many other places throughout Cuba.
Notice now let me ask you a question along the same lines in the replica set specification section.
We learned that there are three sections template replicas and the selector.
We need three replicas and we have updated our selector based on our discussion in the previous slide
say for instance we have the same scenario as in the previous slide where we have three existing parts
that were created already and we need to create a replica set to monitor the parts to ensure there are
a minimum of three running at all times when the replication controller is created.
It is not going to deploy a new instance of part as three of them with matching labels are already created.
In that case do we really need to provide a template section in the type replica set specification.
Since we are not expecting the replica set to create a new port on deployment yes we do.
Because in case one of the parts were to fail in the future the replicas that needs to create a new
one to maintain the desired number of pods and for the replica set to create a new pod the template
definition section is required let's now look at how we scaled the replica set.
Say we started with three replicas in the future we decided to scale to six.
How do we update our replica set to scale to six replicas.
Well there are multiple ways to do it.
The first is to update the number of replicas in the definition file to 6
then run the cubes TTL replace command to specify the same file using the dash f parameter and that
will update the replica set to have six replicas.
The second way to do it is to run the cube control scale command.
Use the replicas parameter to provide the new number of replicas and specify the same file as input
human either input the definition file or provide the Republicans at name in the type name format however
remember that using the file name as input will not result in the number of replicas being updated automatically
in the file.
In other words the number of friendly cars in the replica set definition file will still be three even
though you scaled your replica set to have six replicas using the cube control scale command and the
file as input.
There are also options available for automatically scaling the replica set based on load but that is
an advanced topic and we will discuss it at a later time.
Let us now review the commands real quick the cube control create command as we know is used to create
a replica set or basically any object in Cuba and it is depending on the file we are providing as input.
You must provide the input file using the dash f parameter use the cube control get command to see List
of replica sets created used to keep control delete replica set command followed by the name of the
replica set to delete the replica set and then we have the cube controlled replace Command to replace
or update the replica set and also the cube control scale command scale replica set simply from the
command line without having to modify the file that's it for this lecture.