So we had a look at the Pod object.
Now let's have a look at the Deployment object.
Because it turns out that the Deployment object
will be one of the key objects you work with
when working with Kubernetes.
Because you typically don't create
the Pod objects on your own
and manually move them to some worker node.
But instead you create a Deployment object,
which you then give instructions about the number of Pods
and the containers it should create and manage for you.
The Deployment object is able to control
one or multiple Pods.
So, you can also use it to create multiple Pods at once
and the core philosophy behind this Deployment object,
which under the hood is a controller object.
But for us,
it's enough to know that it's a Deployment object.
The idea behind that,
is that we set a desired target state.
For example,
that we have two Pods with this container up and running,
and then Kubernetes will do everything it needs to do
to reach this target state.
So, we can define what we want
and Kubernetes will get us there.
And the advantage of this is,
that the Pod objects are then created by Kubernetes
and the pods are therefore created by Kubernetes.
The containers are started by Kubernetes
and Kubernetes will then, for example,
also place these Pods on worker nodes,
which have sufficient memory and CPU capacity
for these new Pods.
So, we don't manually have to pick a remote machine
and place our Pod on there.
Kubernetes will do this for us instead.
Another advantage of using this Deployment object,
is that we can also pause or delete Deployments
and also roll them back.
So, if we mess something up and our application fails,
we don't have to rush to change our code and fix the error
and replace the failing Pod with a new one.
Instead, we can just roll back the failing Deployment
and go back to the previous Deployment which worked.
Then we can fix the bug without any need to hurry,
and we can then simply start a new Deployment
with the updated code in the updated container image
once we're done.
So, that's another very handy feature.
Another handy feature,
which is worth mentioning here,
is that the Deployments can also be scaled.
We can tell Kubernetes
that we now want to have more Pods or less Pods,
and we can also use a feature called autoscaling,
where we can set certain metrics.
For example, incoming traffic and CPU utilization.
And when these metrics are exceeded,
Kubernetes automatically creates more Pods
and therefore more running container instances,
which are there to handle the incoming requests.
And once the traffic goes down and is less,
these unnecessary Pods will be removed again.
And these are all features we can get
when using this Deployment object.
Now, when we create Deployments,
we manage one Pod with the Deployment,
but we can of course create multiple Deployments
to have multiple Pods being managed by Kubernetes.
And therefore, we typically don't directly create Pods,
we don't directly manage them.
Instead, we let Kubernetes do that for us
by using Deployments and by creating Deployment objects
and sending that to the Kubernetes cluster.
So, now that we know all of that,
let's finally get our hands dirty
and let's run some commands
to finally create such a Deployment
in our Minikube demo cluster.