So Kubernetes is this collection of concepts and tools,
which can help us with deploying containers anywhere.
Let's therefore now, dig into the architecture
of a Kubernetes deployment
and let's see what Kubernetes can set up and manage
on any cloud provider of our choice.
And it all starts with a container which we wanna deploy,
which in the Kubernetes world is actually managed
by a so-called pod.
You can think of a pod as the smallest possible unit
in the Kubernetes world,
which you can define in some configuration fall
for a Kubernetes to create.
And the pod simply holds a container.
Actually, a pod is always able to hold multiple containers
which might need to work together
but the smallest possible unit is simply one pod
which then in turn is responsible for running this container
or which is basically executing this container.
Now this pod with the container inside of it,
then itself, runs on a so-called worker node.
So a worker node is the thing in the Kubernetes world
which runs your containers in the end.
And you can think of worker nodes as your machines,
your virtual instances.
So in the AWS world which we saw in the deployment section
an EC2 instance which is a remote machine
fully owned and managed by you could be a worker node.
A worker node is simply a machine, a computer somewhere,
with a certain amount of CPU and memory
and on that machine, you can run your pods.
And you can have more than one pod
running on one of the same worker node.
Now besides this worker node pod concept on a worker node
Kubernetes also needs a proxy
which in the end just is another tool
Kubernetes sets up for you in the end
on such a worker node to control the network traffic
of the pods on that worker node.
So basically to control
whether these pods can reach the internet
and how these pods
and therefore the containers running inside of them,
can be reached from the outside world.
If you are running a web application
in a container in such a pod for example,
the proxy needs to be configured such that
traffic from the outside world from your users
is able to reach this container.
And of course, we will learn how to set all these things up
and how to create and deploy all these things
throughout the next lectures and course modules.
No worries.
Now when working with Kubernetes,
you typically need at least one worker node
because otherwise there is no place to run your pods
and therefore your containers.
But of course, for bigger applications,
you typically will have more than one worker node
which are then able to run your different pods.
Because you might need more than one server
to have enough compute power
to run all your containers
and this includes containers scaling.
If you use Kubernetes to dynamically add
and remove containers, and therefore pods,
as traffic in and decreases
these pods are automatically distributed by Kubernetes
across all available worker nodes.
So you can have different and equal containers
running on multiple worker nodes
to distribute workload evenly.
Now all these worker nodes
and the pods and containers running on them,
need to be controlled somehow.
Someone needs to create and start these containers and pods
and someone needs to replace them or shut them down
if they are failing or not needed anymore.
And that's done by the master node
specifically by the control plane as it's called.
So this is basically the control center
which then interacts with the worker nodes to control them.
So when working with Kubernetes,
you typically don't directly interact
with your worker nodes or pods,
though you could do that, but you typically don't do that,
instead you let Kubernetes and this control plane
do that heavy lifting and you as a developer
just define the desired end state
Kubernetes should take into account.
So it's this master node simply another server
another remote machine,
which has this control plane running on it,
which then is responsible for interacting
with the worker nodes and the pods running on them.
Now theoretically, you can have one machine
which acts as both the master and only worker node,
but for bigger deployments
of course you will have a master node
which itself might actually be split
across multiple machines to ensure high availability
and your worker nodes would then be other instances
other machines independent from the master node.
So that if one worker node goes down,
your master node doesn't go down together with it.
Now on the master node, this control plane thing,
is actually a collection of different tools
different services, which are running on the master node.
And we'll have a closer look
at both a worker and master node in just a second.
Now all together, this forum's a cluster.
This forms a cluster
of your master and worker nodes and therefore one network
in which all these different parts are connected.
And then your master node is able to send instructions
to a cloud provider API,
to tell that cloud provider
to create it's cloud provider specific resources
to replicate this desired big picture this end state
on that cloud provider.
So if we think about AWS, we might interact with AWS
such that AWS creates all the required EC2 instances
a load balancer which might be needed
and everything else which is required to have this network
and to then have Kubernetes and some Kubernetes tools
running on the master node, EC2 instance,
which then in turn controls the other EC2 instances,
which belong to this network
to then run containers in these pods on them.
Now I'm totally aware
that this at this point still sounds a bit abstract
it will make more sense once we get our hands dirty
and once we start working with Kubernetes
in the next course section.
It's this theory and big picture
which you should have in your mind first though
so that all the terms and the concepts we use
in the hands-on section later, make sense to you.
Now, before we get our hands dirty though,
let's dig a bit deeper into worker and master nodes.