So let's take a closer look
at these Worker Nodes now.
A Worker Node, as I mentioned,
is simply our machine, a computer,
an ec2 instance, for example, running somewhere.
And the Worker Node is managed
by the Master Node, as I explained.
Now, inside of that Worker Node,
we have our Pods.
And a Pod simply hosts one or more
application containers and all their
resources belonging to these containers.
For example, the configuration
to run the containers correctly,
but also things like volumes.
And the Pods themselves are managed by Kubernetes,
again, by this Master Node.
So, Kubernetes can, for example,
create or delete Pods.
And when a Pod is deleted,
the Pod internally is then able to run
and manage the Container that belongs to the Pod.
And, of course, you can have one Container in a Pod,
but if you have multiple Containers,
which need to work together closely,
you could also have multiple Containers
inside of a Pod.
And then any additional resources that might be needed,
like for example, a Volume, so some space on a
hard drive which the Containers can talk to.
And as I also mentioned, the idea typically is
that you have more than one Pod
running on a given Worker Node.
Now, that can be a copy of another Pod,
in case you're scaling it up and you want to have
multiple instances off one and the same
Container up and running to distribute
incoming traffic, for example.
But it can also be a Pod with a totally different
Container inside of it to do a totally different task.
Because the Worker Node is not task specific,
the Worker Node, it's really important to keep this in mind,
is just your computer, your machine.
It's just a machine somewhere on the internet
with a certain amount of CPU and memory,
and, therefore, you can of course run totally
different Containers and tasks on it,
just as you can run totally different
Containers on our own development machine.
With the "docker run" command,
I can run as many Containers based on
as many different images as I want.
And we actually did this throughout the course,
also with "docker compose".
We definitely had a backend, a frontend,
and a database container running all on our local machine.
And it's basically the same with a Worker Node.
It's just on our local machine, but some machine
out there in the internet offered by some
cloud provider, typically.
Now on this Worker Node, we then all don't just
have these Pods, but also some additional software.
For example, Docker needs to be installed there,
because Docker, of course, is required by the Pods
to create and run the Containers.
We then also have another piece of software
running there, which is called a kubelet,
which is basically the communication device
between the Worker Node and the Master Node.
So, it's basically a software service running
on that machine, on the Worker Node machine,
which does the actual communication with the
Master Node, so that the Master Node is able to
control the Pods on this Worker Node.
And, we've got this proxy service running,
which is responsible for handling incoming and outgoing
traffic to insure that everything is working as desired,
and only allowed traffic is able to reach the Pods,
and only allowed traffic is able to leave the Worker Node.
And that is the Worker Node.
That's a closer look at the Worker Node
and what's running on there.
And the great thing is that with Kubernetes,
you just need to define the desired end state,
and if you're then using a cloud provider like AWS,
they have services which allow you to provide
this Kubernetes definition, and then AWS will
set up all the instances and install all the
required software for you.
So you don't have to deal with that.
You just have to know what's happening there,
because as a developer, you should always know
what your code, and what your configuration is doing.