So now we learned about Kubernetes volumes,
and how we can use them
and that there are different types of volumes.
And we saw the hostPath and the emptyDir type
in action already.
I also briefly talked about the CSI type.
Now these volumes have one disadvantage.
They are destroyed when a Pod is removed
when a Pod is terminated and replaced
by a new Pod for example.
Or if you scale your Pods,
and you go from one Pod to two Pods
then depending on the type of volume you're using,
the new Pod might not have access to the data
written by the first Pod.
For example, when using the emptyDir.
Now, when you use the hostPath type
this problem was kind of solved
but it is super important to keep in mind,
that this solution only works here with minikube,
because it's a One-Node environment.
All the Pods always run on the same worker node
because with minikube, we only have one worker Node.
Now of course, once you move from your local environment
and from minikube to a real deployment and a real cluster,
for example, on AWS, you will have multiple Nodes
and then hostPath also won't help you anymore.
Then you will really have the problem
that volumes are attached to Pods
and therefore, multiple Pods might not share the same data.
And when a Pod is destroyed or replaced
the data stored in the volume, will be lost.
But of course, sometimes you therefore need
Pod and node independent volumes.
For example, if you had a container
with a database in there
or a container writing files
which should survive Pod replacement.
So it's not always great, if you lose your data,
once a Pod is removed.
For some data, especially intermediate results
and temporary data, that might be fine.
But for a long-term data,
like the key data, your application generates
you of course don't wanna lose it
just because a Pod was scaled up or replaced.
And therefore, Kubernetes also has a solution for that.
Besides the normal volumes, which we saw up to this point,
Kubernetes also has this concept of persistent volumes.
And as the name implies, the difference here is,
that they will always persist.
They will be Pod and Node independent.
Now, of course you might argue
that a lot of the volume types we can use.
Like AWSElasticBlockStore, AzureDisc, AzureFile, NFS
and a lot of other options here, indeed in the end give us
Pod and Node independent storage.
Because of all the species still set up a volume
when setting up a Pod, after all
we add our volume definition to the deployment YAML file
or to the Pod templates to be precise.
Whilst we do that, of course by nature,
a lot of the solutions here actually store the data
outside of the Pod or node our application is running on.
If we use awsElasticBlockStore,
our data is getting stored on AWS servers
and it's not getting removed there
just because a Pod shuts down.
You actually find this here as well
unlike emptyDir, which is erased when a Pod is removed,
the data here persists.
So why do we then have this our type of volume,
the persistent volume, if for regular volumes
we also can use volume types
which give us this Node and Pod independence.
Well, as you will see over the next lectures,
the persistent volume concept
is more than just independent storage.
The key idea however is,
that the volume will be detached from the Pod.
And that includes a total detachment
from the Pod life cycle.
Instead with persistent volumes,
we will have that Pod and Node independence
and as a cluster administrator
we will have full power over how this volume is configured.
We don't need to configure it multiple times
for different Pods and indifference deployment
YAML files or anything like that.
Instead, we'll be able to define it once
and then use it in multiple Pods if you want to.
So persistent volumes are built around the idea
of Pod and Node independence.
And that helps us when it comes to how data is stored,
that it's not lost if a Pod is destroyed and recreated
but that also helps us with defining volumes
independent from Pods, defining them in a central place
and then using volumes and different Pods
without editing multiple Pod YAML files.
Which for bigger deployments, as you can imagine,
can be very cumbersome
and which might also not give us all the control
we as a cluster administrator might want.
That is where persistent volumes can help us.
So how do persistent volumes work
and how do they differ
if we compare them to regular volumes?
Well, if we have a cluster with multiple Nodes
and different Pods,
either different instances of the same Pod
or different Pods with different containers
which are running on these Nodes.
And you'll learn that volumes
would be inside of these Pods.
Now with persistent volumes,
the idea is that you have new resources,
new entities in your cluster.
Which are detached from your Nodes and from your Pods.
Instead you can create so-called persistent volume claims.
These will be part of Pods
but I added the next to the Pod here
to just show that these claims belong to the Pods
and the Nodes on which the Pods run.
And these claims could reach out to these standalone
Pod and Node independent entities,
the persistent volumes to request access to them.
So that for example, the container running in the Pod
is able to write into this volume.
And of course you can have claims to multiple
different persistent volumes.
And you can have different claims to different volumes
on different Pods on different Nodes
so you got full flexibility here.
And the idea is that these persistent volumes, of course,
don't store data on one of these Nodes,
but instead they are really independent from the Node.
And therefore, for example, in the official docs
if you have a look at the persistent volume documentation
you can learn more about them.
But the most important thing there can be found
if you have a look at the types of persistent volumes.
And there you will see that the types here
are kind of similar to the types we saw before.
But for example, the emptyDir is missing.
And hostPath is there,
but you see one important restriction.
It's really only a available
if you have a single Node setup,
like our local minikube setup.
So in reality, on a real deployment on the real cluster
with multiple Nodes, hostPath, all wouldn't be available.
And of course it's not available
because the entire idea behind persistent volumes
is that it's detached from your Nodes and Pods.
Therefore you can, for example, use cloud storage
like AWSElasticBlockStore, or AzureFile, AzureDisc,
or again, this very flexible CSI type
to attach any kind of storage to your cluster.
But the key thing is that the storage
will not be on the cluster Nodes
it will be somewhere else, for example,
some cloud storage service.
And again, we'll see the CSI type in action later
once we really deploy our application.
But we can right away get started with persistent volumes
to understand how they work
and how the claim and the volume work together
by again, using hostPath.
Again, it's only here for a testing
and for this local dummy environment
which uses only one Node,
but the idea is the same
as if you would use any other type.
So it's perfect for getting started
with persistent volumes.