Over the last lectures,
we talked a lot about volumes and persistent volumes.
And from my own experience,
I know that it can be confusing that you have
these different kinds of volumes.
So in this lecture, I wanna compare the two approaches
and make it really clear why we have these two approaches
and which one should be used in which situation.
The first very important thing,
I wanna make absolutely clear though, is that volumes,
no matter if you use the regular volumes
or persistent volumes allow you to persist data.
So even though these normal volumes,
which were defined together with a pod definition
are not labeled such, they do help you persist data.
It's not just persistent volumes that help you with that.
This name can be deceiving and misleading.
The idea behind all volumes here is
that you have data in a container
which should not be lost when the container restarts
or is removed and recreated,
and both types of volumes help you with that.
Now, when it comes to the normal volumes here,
which is not an official term,
just a term I came up with here,
it is important to realize that
they are independent from containers,
but not independent from pods.
They are attached to individual pods and they are lifecycle.
Which means if a part is deleted and removed,
a volume attached to this pod might
also have its data cleared.
It's then depends on the volume type.
For example, the empty dirt type,
would then start again empty if the pod is recreated.
Our volume types like host path
and certain cloud provider types,
of course would not lose their data.
But either way, the volume definition
and the volume configuration is closely tied to a pod.
And indeed we do define
and writes down the volume configuration in the same file
as we define the pod.
It's in the pod template where we don't just define
how the volume is mounted into the container,
but where we also define which volume type to use.
That's what you saw a couple of lectures ago
for these regular volumes.
You saw it for both empty dirt and host path.
Now I outlined that one problem could be
that your data is lost when the pod is removed.
But as I just said already,
that's depends on the type of volume driver you're using.
The bigger problem, which you might face,
even if you use a volume type where data is not lost,
is that it can be repetitive
and hard to administer on a global level
if you work with these pods specific volumes only.
For a small apps,
or if you're the only one working on this project,
it might not be a problem at all.
Though even in that case,
you might have a lot of repetition.
If you have different pods,
different deployments with different pod templates,
and you need the same volume configuration
on different parts,
you need to repeat that same volume set up code
in all your different pod templates.
So that might be annoying.
And if you're working in a bigger project
and you're the administrator responsible
for setting up all the storage and the volumes,
then you always need to
go into the pod templates your colleagues created
just to set up the volume configuration there.
So this could also be annoying.
And that is the very specific problem
to gather with the data persistence,
which to persistent volumes solve.
Because their volumes are not defined together
with pods and therefore attached to pods.
Instead they are standalone resources
in your Kubernetes cluster.
They are not attached to a specific pod.
They can be created standalone.
And then they are claimed with
these persistent volume claims which you saw.
But of course, that means
that if you need the same volume configuration,
the same volume type with the same path
or whatever it is in different parts,
then you just need to create this persistent volume once
and it can be claimed by these different pods.
So the configuration lives in one file
and therefore it's easy to reuse.
You have less repetition.
And of course, it's also easier to administer
if you are the administrator
responsible for managing all the storage
and the volumes in the cluster.
So especially for bigger projects,
these persistent volumes can make it way easier
to manage all the storage options
and all the volumes your clusters should be able to use.
And then some colleagues could focus on
setting up the pods templates
and they would only need to specify the claim
which they wanna use,
and they would not need to
write any volume specific configuration logic
in their templates.
And on the apprehended would be super easy
to manage all the volumes on a global level,
without touching pod templates at all.
And in addition then,
you have to spot and note independence
which I emphasized over the last lectures.
Where you are ensured that your data will not be lost
just because a pod was destroyed
or launched on a different note.
Because with a persistent volume,
you are only allowed to use volume types
which do actually work independent
from the node on which your pods live.
So that's the difference.
And therefore there is no better or worse volume type here.
It really depends on your project.
If you're on your own,
working on your own small demo project,
using persistent volumes, might be overkill.
You can, of course still do it though,
in bigger projects with a lot of pods and a lot of volumes,
and maybe a lot of people working on the project
using persistent volumes
might make it easier to manage that project.