Instructor: If you visit kubernedes.io,
you can get started learning more about Kubernetes,
though of course you don't need to go
through their documentation.
Since I'm going to teach you all the fundamentals of
Kubernetes in this and the next sections.
But on this official page, you learn that Kubernetes,
is an open source system, for automating deployment,
scaling, and management of containerized applications.
So it's not a single software, it's a system.
And it's a collection of things, of tools,
and of ways of doing something,
which will help you with container deployment.
But whilst this is a nice sentence to read,
it still doesn't fully tell us,
what exactly Kubernetes is, how we use it,
and why we might wanna use it.
So let's take a step back.
When we think about deploying containers.
And it's really just about that.
It's not about using containers and Docker,
locally on our machine for development,
which we can also do,
but it's just about deployment.
When we think about that, we might have a problem.
And for that specifically,
let's think about manually, deploying containers,
by manually managing servers for them.
So with that, I'm talking about,
for example, creating our own EC2 instances,
which are these virtual machines we could create with AWS,
on which we then were able to install Docker,
to then run our containers on them.
That is something we did initially,
in the deployment section of this course.
Now, when we do that, we will face a couple of challenges.
And I'm not just talking about the security and
configuration concerns,
I already mentioned in the deployment section.
These are all the serious concerns,
that we have to manage and configure our EC2 instances
on our own that we have to ensure,
that the software and the operating system on
there stays updated.
These are definitely challenges,
but I'm not even talking about these challenges here.
Instead, if we install Docker there,
and we manually run our containers, on these EC2 instances,
even if we wouldn't have any security problems,
we still might face other problems,
which I didn't focus on too much, up to this point.
For example, containers, might crash or go down,
and might need to be replaced with a new container.
This is something which can happen.
Something might go wrong,
inside of your containerized application.
Something might fail there,
and therefore the entire container,
in the end crashes and becomes unusable.
If something like this happens,
you want to replace it with a new container,
running your application again,
because otherwise,
your application might not be reachable anymore,
if it crashed and isn't replaced.
Now, when manually deploying,
when manually running containers on an EC2 instance,
we also have to manually monitor,
whenever something crashed,
and we have to manually restart containers thereafter.
And, it should be needless to say that,
that is of course not really something
we wanna do for a serious or bigger applications,
because when we're asleep, we can't monitor.
And even if we're not asleep,
we can't sit the entire day watching our logs,
and seeing if something goes wrong,
just to then restart a container.
So that is clearly a problem we might be facing,
in more realistic and bigger applications.
Now, in addition, even if we wouldn't have that problem,
we might need more container instances,
upon traffic spikes, because if traffic increases,
if we got more workload coming in,
our containers might be still stuck,
finishing the first task,
before they can handle the next task.
The next incoming request, for example.
That's why we might want to scale up the number
of containers, to then decrease and evenly distribute
the incoming traffic across the different containers.
And of course, if we then got less traffic incoming,
we might want to remove a container again.
And that is something we totally haven't talked about at all
up to this point.
Up to this point, we only executed every container once,
no matter, if we consider the EC2 example,
or if we think about ECS,
which we also used in the deployment section,
we always just had one running instance of a container.
And in reality, that might not be enough.
Also keep in mind,
that you cannot just use containers for web development.
If you got a container which runs an application, or a task,
where you maybe transform image files,
then this might not be depending on incoming HTTP requests,
but you might simply be going through image files,
which are uploaded to some folder.
And if more and more files are coming in,
your container might take longer and longer to finish
transforming all these files.
Spinning up multiple containers,
which run the same task on different files,
might then be a solution.
So you might need to scale the number of running container
instances up and down,
as your workload or your traffic increases and decreases.
Besides that, when we talk about traffic,
HTTP traffic coming in for example,
then we also might wanna ensure that it's evenly
distributed across the running container instances.
If we got only one container instance,
of course there is nothing to distribute,
but if we've got multiple instances,
so multiple versions of the same app running.
So the same container running multiple times,
then we might wanna split the incoming traffic evenly,
to ensure that not one container is doing all the work,
while the other container instances are doing nothing.
And I am aware that this concept of having multiple running
container instances.
So the same container running multiple times,
is relatively new.
Of course I did mention earlier in the course already,
that you can run Docker run, on the same image,
as often as you want.
You can run as many containers as you want,
based on one at the same image.
But for our local development,
and also in the deployment section up to this point,
we, of course, didn't really use that.
We always just executed every image, once.
So we created one container per image.
But in reality, for real web apps,
or for whatever costs you are containerizing,
you might need multiple container instances,
which are based on the same image,
so that the work can be split,
and you ensure that for higher amounts of incoming traffic,
for example, you got enough containers available,
to handle all these incoming workloads.
And we'll see this scaling concepts in greater detail,
throughout this and the next modules.
But these are the problems we might be facing,
when deploying containers.
And these are definitely big problems,
if we manually deploy containers.