So persistent volumes
can give us greater independence of the individual pods
and nodes on which these pods are run.
So let's now create a persistent volume
and let's see how we can use that
compared to volumes created as we did it before.
And therefore, I'll create a new file
and I'll name this host-pv.yaml
because there I'll set up a persistent volume,
that is what PV stands for, using the host path driver,
the host path type.
Which, just to make this clear again,
will only work on a single node testing environment.
But this is the environment we have right now
and what I explain about this will always hold true.
So what I teach you here with host path
will then later all to be important
if you would use a number type.
Now, to define our persistent volume
we, first of all, again, need to set the API version
and I'll set it to v1, just as for a service.
Then, just as for the deployment and the service,
we of course need to make Kubernetes aware
of the kind of resource we want to create with this file
because it, of course, can't guess that
and can't know that either
without us adding more information.
So I'll add a kind here.
And here, the kind is PersistentVolume, written like this.
And of course, just as with the other kinds,
like deployment, make sure you type this correctly
and you have no typo in here.
Next we can add metadata
and give this persistent volume a name,
for example, host-pv.
The name as always is up to you.
And then also just as with the deployment and the service,
we have our spec,
our specification for this persistent volume.
This is now where we're going to configure it.
And here we need to configure a couple of things.
For example, of course, which type of volume
we want to define as a standalone entity here.
And I will use host path,
so we add host path here just as we did it here on volumes
in the deployment yaml file.
And indeed we can use the same sub-configuration
as we did there.
So we can add the same configuration,
like the path and the type here, nested below host path.
And this will now set up a host path,
persistent volume as a standalone volume
detached from any pod in this environment.
Again, because it's host path,
it will not be independent from the nodes
and it only works if we have only one node.
But the rest of the explanation
will apply to other types as well.
Because the type is not everything.
With a persistent volume, unlike with a regular volume,
we need to add more information here in this spec object.
For example, we need to define a capacity.
The capacity matters because as an administrator
we might want to control how much capacity can be used
by the different pods
which are later executed in our cluster.
And therefore we can set a capacity here.
A capacity for this persistent volume and the pods,
when they claim this volume later,
can then define how much capacity they need.
So here we specify the overall available capacity.
And we can specify to storage capacity here, to be precise.
And set this, for example, to four gigabytes
by adding 4Gi here .
Now, to know which values are suppoded here
you can dive into the official persistent volume docs.
And there, if you scroll down a bit,
under Persistent Volumes, there is a capacity key or point.
And then there, you can click on the Resource Model.
And here in this document,
you can learn more about how Kubernetes defines resources
and which units it knows.
So here, for example, you see this gigabyte notation.
So this is a document you can look into to learn more
about the available units and how to define resources.
At the moment, we only have to storage resource
and there of course,
you will quite often work with gigabytes.
So here I'm defining that up to four gigabytes of space
can be claimed and used here for this host path volume.
And of course you could define more if you need more.
If you're using some third party service
you of course need to ensure
that you have enough away level space there
so that you don't offer more here
than is realistically available.
So actually here I will shrink this to one gigabyte
to be really sure that this is really available
inside of this virtual minikube machine.
Now, a next option you need to specify here
is the volume mode, and there are two available modes here.
There is file system and block.
And these are different storage types.
Not only defined by Kubernetes, but generally.
When we talk about storage and development,
we have block storage
and we have file system storage, typically.
I attached a resource where you can learn more
about the differences between file system and block storage.
Here, we have file system storage
because we have a folder on the file system
inside of our virtual machine.
The next key we can define here for this persistent volume
is how it may be accessed.
And we set this by adding the access modes key here
which then accepts multiple access modes.
Hence we have a dash here
and we can now list all the access modes we want to support.
And there are three possible access modes we could add here.
That's ReadWriteOnce.
ReadOnlyMany.
And ReadWriteMany.
So what is the difference now?
You can specify all,
because it's only when you claim a volume
that you then have to define
how you want to claim this volume for a given pod.
Here you justifying what should generally be allowed,
so how this may be claimed.
ReadWriteOnce means that this volume can be mounted
as a read-write volume by a single node.
So by multiple pods,
but they all have to be on the same node.
ReadOnlyMany means that it's read-only
but it can be claimed by multiple nodes.
So multiple pods on different nodes
can claim this same persistent volume.
And for example, for the host path type
this is simply not in available option
because host path by definition is defined on one node
and they offer another node
and another pod running on another node
won't be able to claim it.
ReadWriteMany is therefore also not available
because that's the same like ReadOnlyMany,
just with the difference that we're talking about
read-write access.
So here for this specific type of volume,
the host path type, only ReadWriteOnce is available.
Which means, when this value is claimed,
it can be claimed by multiple pods
and they will have read-write access,
so the containers will have read-write access.
But all the pods have to always run on the same node.
Which, for this local dummy environment, will be guaranteed.
So these are the available access modes
which can be used for claiming this later.
And here, I will only to find one available access mode
because it's the only mode which makes sense for this type.
In the official docs under Access Modes,
you also find a matrix, a table,
where you see which access modes are available
for which type.
Of course for the CSI type, which is highly flexible,
it depends on the exact driver you are using.
Now, that's it for the core keys I want to add
at the moment.
This defines that we have this standalone host path volume
which now could be used by any pod in our application.
So if we had multiple deployments and not just one,
and therefore different types of pods,
all these different types of pods
could use that same persistent volume.
But in order to use them
they need to use a persistent volume claim.