Now the good news is that Kubernetes
is able to Mount volumes into containers.
We can add instructions to our pod templates,
when we set up a deployment for example,
that a volume should be mounted into the container
which will be launched as part of the pod.
And Kubernetes actually has a quiet powerful volume support,
you could say.
It supports a broad variety of volume types and drivers,
and that's not something we necessarily know
from just Docker.
But since with Kubernetes we run our application
possibly across multiple nodes,
and possibly on different cloud and hosting providers.
It supports different types of volumes
which simply means it is quite flexible
regarding where the data is actually stored.
It supports local volumes.
So simply a folder on the worker node,
where the pod is running.
But it also supports cloud provider specific volumes.
And we're going to have a look
at the different types supported by Kubernetes
in greater detail throughout discourse section, of course.
Now what's important to note
and understand about Kubernetes though,
is that the volume lifetime by default
depends on the pod lifetime.
Because you must not forget that the volumes
are part of the pods, which are started
and managed by Kubernetes.
I mentioned this in the section where I introduced you
to Kubernetes, and gave you a first overview.
So volumes are pod specific
and often that is totally fine,
but of course, sometimes this can also cause problems.
Though I will also present a solution for potential problems
throughout this course section.
However, before we dive into any potential problems
and solutions, let's first understand the basics.
So the volume lifetime, because the volume
is part of the pod, depends on the pod lifetime.
And therefore it survives container restarts
and removals, because the container is inside of the pod
and the volume is outside of the container,
but also inside of the pod.
But since the volume is inside of the pod,
of course volumes are removed when pods are destroyed.
So they survive container restarts and removals,
which is great, which is what we need here.
But if you would remove a pod
then the volume would also be gone.
And if you want a volume to survive the removal of a pod
there also will be away for achieving that.
But it's an advanced concept which we're going to explore
at the next step.
For the moment let's have a look at these pod internal
and pod specific volumes.
And therefore it is important to understand
that Kubernetes has this volume support.
But volumes managed by Kubernetes are not exactly the same
as volumes managed by Docker,
or to be precise, the idea is the same
but Kubernetes volumes are a bit more powerful.
With Kubernetes volumes,
you have different drivers and types.
Which gives you great control over where the data is stored.
Now, when you work with just Docker and Docker compose,
that's not the case,
because that's also not something you really need.
You run it locally on one machine anyways,
and therefore it's clear that the data should be stored
on that machine right?
So when you use just Docker and Docker compose
you don't necessarily need that much support
for different storage systems.
But with Kubernetes of course, running your application
on a cluster with multiple nodes,
on different hosting environments.
On AWS, or your own data center or somewhere else,
of course it needs to be flexible
regarding how data should be stored.
Which service by some cloud provider
should be used for example,
or if it should be stored on the hard drive
on a specific machine.
And that is some flexibility Kubernetes gives you.
In addition, as I mentioned before,
the volumes are not necessarily persistent.
They do survive container restarts but not pod restarts,
at least not by default.
And of course, for just Docker,
since you don't have the concept of pods
and different machines and nodes.
Data is always persistent until manually cleared,
because you run Docker on one machine,
for example, on your local development machine.
And well, the data would be erased there as well,
If you totally destroyed that machine
or if you re-installed the operating system on your machine
and you reset your machine.
Then the data would be lost of course,
but that's not something you typically do.
That is the comparison we should make,
however, when we compare it to Kubernetes.
There we work on a cluster with different nodes and pods,
and of course, if a pod is removed on some node,
that is kind of equivalent
to you resetting your local laptop.
So of course, volumes are then lost.
If just a container stopped and restarted
and was removed in between,
then in both cases, volumes will persist.
Because that is the core idea behind volumes.
So in the end, Kubernetes leverages
the Docker volume system, but adds more power
and more configuration options to it,
because it needs these extra configuration options.
And with all that theory out of the way,
let's simply get started
and let's see how we can utilize Kubernetes volumes.