Now, before we dive into
the declarative approach into volumes and networking,
and dive deeper into Kubernetes in general,
let's play around with the deployment we have here.
And, for example, remember that we have this
get error route here, on this application,
which will actually crash the node app,
and therefore, also the container running the app.
Because this is a Node.js specific command,
which will immediately stop the node server,
and since our container started this node server,
it will crash as well, if that command fails,
which it does when we exit.
So let's now visit slash error here,
and you see it crashes.
And now if you try the original route again,
without slash error, this still works.
Now, if you run Q+Ctrl get pods,
you see the status is running,
but because it was restarted once.
Now if we crashed this again,
by again going to the error route,
you see the status as error,
but if we wait for a while,
it will restart this again.
Now the time after which it restarts,
gets longer and longer,
to prevent infinite loops,
where maybe you have a container,
which simply fails all the time,
to prevent such infinite loops,
Kubernetes waits longer and longer with restarting,
but eventually you'll see it's now back to running,
and it restarted it twice.
And that's a behavior we get
because we created a deployment here.
Because of that, this pod and the container in the pod,
is being monitored, and if it fails, it's restarted.
We can also see this here in the dashboard.
If we have a look at our pods
we see that this pod was indeed restarted twice now.
So it was not recreated and not replaced,
but it was simply restarted,
and the container in there was restarted.
You can also see that here in this events log.
And you can see that it created different containers,
every time this pod was restarted.
So this container was recreated
when the pod failed or when
the application, the container failed,
and the pod therefore decided that
it needed to restart the container.
So that's a very useful behavior we get here.