We've now seen how to throw a pot onto our communities cluster.
Now it turns out that we usually do not create pods in this style.
I know that's kind of annoying to hear given that I just spent a couple of videos telling you about
pods and how to work with them.
Don't worry.
We do work with pods and all the ways that I just showed you.
So we ran out our very frequently run all the commands I showed you just a moment ago.
We just don't usually create pods with this style of config file.
Let me give you a little more clarity.
Help you understand what's going on here.
So in the world the Cuban eddies we have pods and those are intended to run some image or some contain
a really inside them rather than creating these pods directly however we're usually going to create
something called a deployment a deployment is a Cuban eddies object that is intended to manage a set
of pods.
So it might be just one single pod where it might be 10 different pods or 100 different pods each of
these pods are going to be identical in nature.
They will all be running the same configuration same container inside them the deployment has two big
jobs assigned to it the deployment.
First off is going to make sure that if any pod mysteriously just disappears for any reason.
In other words if the pod crashes for any reason whatsoever then the deployment will automatically create
that pod for us again.
The deployments going to make sure that if we tell it make sure there are three pods available running
this image deployments going to say absolutely.
I got it.
I'm going to make sure there are always exactly three pods running that image.
That's the primary job of the deployment the deployment is also very useful for another reason as well.
Second main reason is that well at some point in time you and I are going to decide to update the code
inside of our different containers.
In other words we might start off with all of our pods running a v1 of some applications we put together
but then at some time we might tell the deployment that we want to roll out a new version but maybe
the two the deployment is going to take care of this update for us automatically.
Behind the scenes the deployment is going to create some number of new pods running this new version
of our application.
After these pods are up and running successfully the deployment is then going to start to manage that
set of pods so it's going to say OK I'm now going to manage these three over here and I'll zoom out
just you can see this whole diagram in a second and the deployment will start to sunset or essentially
delete the old pods for us automatically so all these are then going to fade away once the new ones
are up and running and then the deployments going to say OK.
Fantastic.
I've got it.
I've done all this required work.
I've got these three new pods running these updated versions for you.
So we can really think of the deployment as just being a manager who manages a set of pods.
That is what it is all about now understanding how to work with a deployment is pretty straightforward.
Again it really just comes down to writing a config file.
There are very few commands we need to understand around a deployment at most.
The only thing that we're ever going to do with them is to list out the deployments we have and then
tried to inspect their status deployments don't actually run any of our code or anything like that.
So we're not really going to ever have to try to run some command in the context of deployment or really
try to patch some logs from it or something like that.
Instead we really just want to list them out.
Take a look at their status.
That's pretty much it.
So it really just comes down to understanding how we write a config file for these.
So then minds are going to take a quick pause right here.
When come back the next video we're going to create a deployment by writing a config file and tell it
to run our post application inside of a set of pots.