-: All right, my friends, we've got a whole bunch
of experience with Docker under our belts.
So now it's time to move on to the world of Kubernetes.
In this section, we're gonna start doing a little
introduction to the world of Kubernetes,
first beginning by answering two very important questions.
First off, what is Kubernetes?
Secondly, why would we ever want to use it?
Now, we're gonna try to answer both these questions
at the same time inside this section, so let's get to it.
All right, so to begin, I want you to think back
to the Elastic Beanstalk application
that we just put together.
Inside that application, we had four different containers
running at the same exact time.
We had Nginx, which was forwarding traffic to our server
in our client, and then behind the scenes we kind
of had that worker process running as well.
And of course, we had a copy of Redis and Postgres
running as well, but those weren't really containers
that were running with the rest of all of our other
containers as well.
They were outside services.
Now, I wanna think about this application
and I wanna ask you a very simple question.
How would we scale up this application?
In other words, if we started getting a lot
of traffic and we started having a lot
of different users starting to enter
in different numbers to calculate the
Fibonacci sequence four.
How would we kind of respond to that?
Well, if I had to take a guess, I would say
that it would probably be this worker container
over here that was doing the absolute brunt
of all the work inside of our application.
In other words, this worker process was using an algorithm
for calculating that Fibonacci value
that was very inefficient
and we very purposefully left it kind of
inefficient just to see what would happen
if it took a long time
for that particular container to get some work done.
And so if we started having a lot of users making use
of our application, the most critical part to make sure
that this thing was working correctly
or the entire application was working correctly,
would've been this worker container over here.
Now, ideally, what would've been really nice
is if we had some way to easily spin up multiple processes
or multiple containers of that worker image.
And so if we had like three users come into our application
at the exact same time, it would've been great
if we had three different workers.
One of each could've been used to create
or to calculate a different Fibonacci value.
However, this would've been rather challenging to do
in the world of Elastic Beanstalk.
You see, in order to scale a application by default
with Elastic Beanstalk, here's what actually happens
behind the scenes.
So this is the typical scaling strategy
for Elastic Beanstalk.
Rather than creating more copies of a single container
Elastic Beanstalk looks at that dockerrun.aws.json file
and it spins up additional copies
of the entire set of containers.
In other words, we can kind of imagine that to scale up
our application, Elastic Beanstalk
would've created maybe two, three, four, five different
sets of all of our containers.
Now, unfortunately, we don't really have a lot
of control over what each
of these different groups of containers are doing.
In other words, on each
of these different groups of containers
we got an additional copy of nginx, an additional copy
of the server and an additional copy of the client.
But at the end of the day, chances are
that the Nginx or the client or the server images
or the containers that we were running were not
going to be really the limiting factor of performance
inside of our application.
Like we just discussed, it was the worker container
that was the limiting factor.
And so it would've been way more ideal
to scale our application if we had the opportunity
to do something a little bit more like this.
Let me show you, it would've been just great
if we had the ability to spin
up these additional machines and just create a ton
of additional copies of that worker container on each one.
Chances are we didn't really need multiple copies
of Nginx or the server API or the client.
They were all relatively simple and for the most part
were just kind of serving up flat files
or responding to very simple API requests.
It was only the worker container that was doing
some major computational work inside of our application.
And so it probably would've been ideal
if we could have done something like this instead.
So as you might imagine, this is the type
of approach that Kubernetes would allow us to have.
If we were making use of Kubernetes,
we could have had additional machines running each
of our containers, and we could have had a lot
of control over what these additional machines were doing
or what containers they were running.
So let's take a look at a quick diagram
of how Kubernetes could have been used
to solve this entire scaling issue.
So what you see on the screen right here is a diagram
of a very simple Kubernetes cluster.
A cluster in the world of Kubernetes is the assembly
of something called a master, and one or more nodes.
A node, which is each of these blue boxes right here,
are a virtual machine or a physical computer
that is going to be used to run some number
of different containers.
So each of these different virtual machines
or physical computers that you see right here
can be used to run different sets of containers.
I wanna be really clear that each of them
can run different containers.
Like different images or even different numbers.
So for example, the node on the far right hand side
over here is running three separate containers,
and the one in the middle is running just one container.
These can be completely different containers.
They don't have to be identical.
And so in the world of Kubernetes, you can imagine
that we could have very easily gotten closer to a kind
of scaling flow like this right here.
Or maybe we had just one node or one virtual machine
that was running Nginx, our server in our client
and then maybe we had a bunch of additional nodes
or virtual machines that were running
copies of our worker image.
Now, in the world of Kubernetes
all these different nodes that get created are managed
by something called a master.
This master down here has a set
of different programs running on it that control what each
of these different nodes is running at any given time.
You and I as developers interact with a Kubernetes cluster
by reaching out to this master right here.
You and I give some set of directions to the master.
For example, we might say,
"Hey please run five containers using
the client worker image."
The master receives that command
and then ultimately relays that command
to all of these different nodes.
Now, outside of our cluster, which is represented
by this gray block box right here, we have a load balancer
which will take some amount of outside traffic
in the form of network requests and relay all those requests
into each of our different nodes.
Now, one thing that's going to be a big point of discussion
for us is exactly how this node balancer works
and so that's gonna be something we talk
about inside of the next many videos
on Kubernetes that we're going to go through as well.
Okay, so in this section, just a very high level discussion
on Kubernetes and what it is and what it does for us.
So at this point, I think we've kind of established
that Kubernetes is a system
for running many different containers, so different types
of containers, different numbers of containers
over several different computers or virtual machines.
And we would choose to use Kubernetes
if we had the need to scale up our application
and run multiple different types
of containers in different quantities.
If we only wanted to have a system where we essentially ran-
Let's go back way over here.
If we ran the same set
of containers over and over again, like you see right here,
not a lot of good reason to use Kubernetes.
Again, we want to use it anytime we expect to have
an application that consists
of many different types of containers,
running in different quantities
on multiple different computers.
All right, so with all that in mind
let's take a quick pause right here
and continue in the next section.