Hello and welcome to this lecture on cooperative controllers.
My name is Swampscott Manabat, but in this lecture we will discuss about Kubernetes controllers.
Controllers are the brains behind Kubernetes.
They are the processes that monitor Kubernetes 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 feels we still have our application running on the other one, the replication controller
helps us run multiple instances of a single pod in the covenant is 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.
Does the replication controller ensures that the specified number of pods are running at all times,
even if it's just one or?
Another reason we need a replication controller is to create multiple pods 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 pods.
If the demand further increases and if we were to run out of resources on the first node, we could
deploy additional parts 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 replicas set.
Both have the same purpose, but they are not the same.
Replication controller is the older technology that is being replaced by replicas set properly.
How set is the new recommended way to set up replication?
However, whatever we discussed in the previous few slides remain applicable to both these technologies.
There are minor differences in the way it works, and we will look at that in a bit.
As such, we will try to stick to replica sets in all of our demos and implementations going forward.
Let us know 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 Dash to finish definition, thought Yamal.
As with any Kubernetes 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 Kubernetes API version V1, so we will set it as V1.
The kind, as we know is a replication controller.
Under metadata, we will add a name.
And we will call it my app, 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 aspect.
For any Kubernetes, this 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 pod.
But what part we create a template section under spec to provide a pod template to be used by the application
controller to create replicas.
Now, how do we define the 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 than the template line itself.
They should be children of the template section.
Looking at our file now, we now have two metadata sections.
One is for the replication controller and another for the pod, and we have to inspect sections one
for each.
We have nested to definition files together, the replication controller being the parent and the pod
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 CubeSat, he'll 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 three in
this case to view the list of created replication controllers.
Run the cube set to get replication controller command and you will see the replication controller listed.
We can also see the desired number of replicas or parts, the current number of replicas, and how many
of them are ready in the output.
If you would like to see the pods that were created by the replication controller run the cubes, it'll
get pods 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 app that
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 a replication controller as usual.
First, we have ARPA version kind metadata and spec.
The APA version, though, is a bit different.
It is APS V1, 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 Kubernetes API version has no support
for replica set.
The kind would be a replica set.
And we add name and labels in the metadata.
The specifications section looks very similar to the application controller.
It has a template section where we provide pod definition as before.
So I'm going to copy contents over from our definition file and we have a number of replicas, which
is set to three.
However, there is one major difference between a replication controller and replica set.
Replica 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 you have provided the contents of the definition, file itself in the template?
It's because replica set can also manage parts that were not created as part of the replicas had creation.
Say, for example, there were parts created before the creation of the replicas said that matched 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 Réplication controller and Replicas said 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 pod 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 labels selectors simply matches the labels specified under it to the labels on the part.
The Replicas said 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 CTL create command, providing the definition
file as input and to see the created replicas run the cubes that'll get replicas it command.
To get list of pods, 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 Kubernetes?
Let us look at a simple scenario say we deployed three instances of our front end web application as
three parts.
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 pods if you have them already created, as is 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 pods and if any of them were to fail, deploy new ones.
The replica set is, in fact a process that monitors the pods.
Now, how does the replica said no?
What parts 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 replicas set under the selector section, we used
to match labels filter and provide the same label that we used while creating the pods.
This way, the replicas set knows which pods to monitor.
The same concept of labels and selectors is used in many other places throughout Kubernetes.
Now, let me ask you a question along the same lines in the replica set specifications 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 Pod, as three of them with matching labels are already
created.
In that case, do we really need to provide a template section in the replica sets specification since
we are not expecting the replicas to create a new port on deployment?
Yes, we do, because in case one of the parts were to fail in the future, the replica set needs to
create a new one to maintain the desired number of pods and for the replica set to create a new port.
The template definition section is required.
Let's now look at how we scale the replica set, say we started with three replicas and the future we
decided to scale to six.
How do we update our replica said just kill 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 six.
Then run the Cube CTL 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.
You may either input the definition file or provide the replica said 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 replicas 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.
That is now review the command's real quick.
The cube control create command, as we know, is used to create a replica set or basically any object
in Kubernetes, 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 a list of replicas that's created, used to cube control,
delete replicas at command followed by the name of the Republic are set to delete the replicas set.
And then we have the control 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.