So we defined our host Persistent Volume
and that's the first part of the equation.
The second part is to claim
because this just defines the volume in the cluster,
but in order to use it,
we now also need a claim
and that claim then needs to be made by the pods
that want to use this volume.
Therefore, we gotta do two things.
We first of all have to configure this claim
and then we have to use it on all the pods
that do wanna use it.
So I'll start by adding the host-pvc.yaml file,
which is to claim
that's what the C stands for,
for this host Persistent Volume.
And again, we could merge this all into one
or multiple bigger yaml files,
I'm just splitting it up here across multiple yaml files
to keep this a bit more manageable.
So what should go into this claim file now?
As always, we started with the apiVersion
and that should be v1 here again,
just as for the Persistent Volume itself,
then we need a kind, to make Kubernetes aware
of which kind of resource we are creating here.
And a claim is also a resource, everything is a resource
in a Kuberenetes world.
So here we add PersistentVolumeClaim, written like this.
Again, make sure you have no typo in here,
otherwise this will not work.
Next, we add metadata and we give this claim a name.
This name will later be important for using it in a pod.
And here I'll name it, host-pvc.
Now thereafter, you might've guessed it,
we have to spec, the specification,
the configuration for this claim.
And here we of course need to specify
which Persistent Volume we wanna claim.
Now, here we only have one,
but we could have multiple Persistent Volumes,
which also could use different types, If you needed that.
And in real big applications,
you will of course often have multiple Persistent Volumes.
To connect our claim to this Persistent Volume,
in the spec of the claim, we can add a VolumeName key,
and then simply use the name we used here
for the Persistent Volume, in my case, host-pv,
so that this volume will be claimed here.
Now, I will say when it comes
to claiming Persistent Volumes,
Kubernetes, again offers you a lot of flexibility.
You cannot just claim by name,
there are other ways of claiming by resource,
you could say.
So that you don't claim one specific Persistent Volume,
but if you had different volumes,
you could just say,
"I want the volume with that much space
and this and that configuration."
It would be beyond the scope of this course
and all the more and more kind of an administrator's task
to dive into that.
Therefore, we're not going to do that,
but if you dive into the official documentation
for Persistent Volumes,
and also in the examples you find on the Kubernetes' page,
you will also see different ways
of claiming a Persistent Volume.
Claiming it by name however,
is of course very straightforward
and therefore all the perfect for this use case here.
So now we made it clear
which Persistent Volume we wanna use.
Now we need to provide more information here.
For example, we also need accessModes again,
and now we need to define the modes which we wanna use here
for claiming this volume.
Now you could again, list multiple modes here,
but I only want to claim by the only supported way,
which is ReadWriteOnce access mode here.
But if you would use this claim on different pods
and some pods only need read access,
other need read-write access.
You could specify multiple access modes here
for the claim as well.
Next, we can add the resources key here,
which is basically the counterpart to the capacity here.
And we can now specify which resources we wanna get
for this claim.
The resources object has a request key nested below it,
and there you then can request storage.
Again, that's the counterpart to this capacity.
So since I have a storage of one gigabyte
as a capacity in this Persistent Volume,
that's also the maximum I can request here.
So I will actually request one gigabyte of storage here,
but we could also request less for this claim.
If we had multiple claims to the same Persistent Volume,
we might wanna request less, so that in total
we don't request more than we got available.
This could lead to errors,
if we then try to use all these claims
on our pods and we started writing more data
than we have capacity.
And that is it, this is a Persistent Volume Claim.
Now, as you can clearly tell
this still doesn't establish a connection to a pod though.
Instead does this now a claim which can now be used by pods
to make that claim to that Persistent Volume.
So we need to go back to the deployment yaml file
and now connect our pod here to this claim
so that ultimately it reaches out to this Persistent Volume
and gets its volume.
And we established this connection still through
the volumes key in our pod spec.
So in the deployment yaml file, this volumes key.
We can keep our name here, but now the type is different
instead of hostPath,
which created a host path volume just for this pod,
we now use the persistentVolumeClaim type here.
And this does what the name implies,
now the volume type for this pod is this claim.
So we will use the volume created
or accessed by this claim as a volume for this pod now.
And you could use this in different pods of course,
you can use one of the same claim
in different types of pods.
So here we were making this claim
and we now just need to specify the claim name
as a nested option below this persistentVolumeClaim type,
because otherwise, of course, Kubernetes doesn't know
which claim we might wanna make.
Here, we only have one, but again,
in bigger projects and bigger clusters,
you of course might have multiple claims.
So here it's this claim with this name here.
And therefore I will use host-pvc
as a claim name for this volume.
We don't need to change anything
about the volumeMounts here because we still mounted
in the same way as before.
Now, it's just a volume not created specifically
for this pod, but instead for the entire cluster.
And that of course was a lot of talking
and a lot of work.
But with that, if we now apply everything
and start everything,
we should be able to have our application up
and running again.
But now data should be fully independent from our pods.
Just as before with the host path as I will admit,
but now theoretically all is independent from our nodes.
Not for this host path demo here, as I explained.
There we still have this node dependency,
but as I also mentioned multiple times,
what you learned about setting up Persistent Volumes
and persistentVolumeClaims will also hold true,
if you would use a different volume type here.
And then you would have real node independence.
So let's give this a try now.