So that was the liveness probe.
If we have a look at the official reference,
for the container object,
we see that there's a lot we can configure here.
For example the default command that should be configured,
that should be executed if the container is run,
and you might recall that
that was also possible for Docker-compose,
and to a certain extent,
this of course is equal to Docker-compose.
You define how your containers should be executed
by Kubernetes.
And that's very similar to what we did with Docker-compose.
We defined how containers should be started.
Here of course it's just in the bigger context,
of doing that in a cluster.
So besides defining how our containers should be executed,
we also define our cluster relevant things like services.
But therefore it shouldn't be a surprise
that on the container level,
you can configure a lot of things,
which you also can configure when executing Docker run,
or in a Docker-compose file.
For example all the environment variables,
or the image, but also then Kubernetes is specific,
how the image should be pulled.
And that's quite interesting.
You might remember that earlier when we updated our image,
it didn't pick up that image change,
unless we changed the image tag.
Well it turns out, that it should have picked it up,
if we defined latest, as the image tag here.
Because then it will always pull the image
and use the latest image therefore.
But if you don't specify colon latest,
it will not re pull it.
So that's something you can of course also configure here.
You can add the image pull policy,
and set that to always,
to always pull the latest image,
even if you have no tag specified at all,
or you go with the default in which case you don't need
to specify this,
or you set it to one of the other supported values,
like never or if not present.
So that it's only pulled if it's not there yet,
or that you don't even try pulling it.
Of course that might rarely be helpful, but you can set it.
And here I'll set it to always,
to always force pulling that latest image on that tag.
So now if we would redeploy our application
on the same tag as before, it should still pull it.
And let's maybe give this a try right away.
Let's change something in our code.
Let's say we remove that paragraph again,
which fit the moments still have here.
And we remove all the extra exclamation marks.
Instead we add one in the frontier,
then we can of course build this image,
with that tag, which we need to push it.
So our repository image name Kub first app.
And I want to build it on that tag too.
So call colon two has to be added here.
So thereafter We can push it,
like this, on that tag.
And now since the tag didn't change,
previously Kubernetes would not pull the image again, right?
Because that's what we learn.
And now I pushed to the same tag we already used,
but because of our image pull policy always,
Kubernetes now hopefully stills pulls that latest image,
if we change something about the deployment.
So if I apply this deployment.yaml file,
it should re pull that image,
and therefore if you run get pods,
you indeed see one container is being terminated,
And then new one is getting started,
because it detected a change in the image,
and therefore it's performing a rolling update,
and it's rolling out this latest version
or this new version of the app.
So after some seconds, if you reload,
you see that latest version.
So that's always good to know.
And these are the kind of things
you can of course find out in the docs here.
Now there's still will be many options,
which you rarely need to set, but I do recommend
that you do have a look at this documentation
from time to time, to find out what you can configure here.
Of course there also are certain options
like these volume options,
which we'll have a look at together later in the course,
when we talk about volumes being used
in a Kubernetes managed application.
You can also not just check out
the specification of containers,
but also of the pods
to find out what could be configured there.
Even though again, many things here are rarely needed,
and might not tell you much, which is totally fine.
In that case the official docs
are always a place you can dive into.
But with that we actually got all we need for the moment.
So what I'll do now here, is I'll delete my deployment,
by deleting the files so to say,
by pointing at the files of the resources
that should be deleted,
and we can now wrap up this module,
and then move on to the next module,
where we dive deeper into Kubernetes.