So now
to apply everything we configured here
we of course can run the kube control, apply command.
But before we do that, there's one thing I forgot
which is all to pretty important.
Kubernetes has a concept called storage classes
and you got a storage class by default.
If you run kube control get sc for storage classes,
you'll see,
there is a storage class by default here on minikube.
The storage class is a number of concept,
which you have in Kubernetes
to give administrators fine grain control over
how storage is managed and how volumes can be configured.
It's an advanced concept
and for our purposes here,
the default storage class is absolutely fine.
The storage class in the end defines two Kubernetes
how exactly that storage,
which we want to use in this case,
the host path storage should be provisioned, you could say.
So behind the scenes to storage class
will provide important information
to the PersistentVolume configuration we set up.
It works together with the PersistentVolume
and our standard storage class,
which we got on minikube is already configured
for this host path type,
which is why it will work just fine here.
We just need to make sure though,
and that's the part which is missing
that we're using this storage class.
So therefore, in our PersistentVolume configuration file
in the specification data
somewhere next to capacity and volume mode,
you should add a storageClassName
and use standard here,
because that is the name we have here, standard.
Use that same storageClassName when you make your claim.
So they're next to resources and access modes
you wanna again have storageClassName, standard.
Now with that done,
we finalized this and now we can apply all of that.
I'll first of all, apply the host-pv.yaml file
so I will apply the PersistentVolume
because applying to claim makes more sense
if we already got the volume.
So now this was created.
Next, I will apply the host-pvc.yaml file
to create the claim.
And thereafter,
we can of course also apply the deployment
because we updated that deployment.yaml file to use that.
Now here for me it's saying
unchanged because I did test this in advance
of course, I did run this in advance,
but for you, it should say configured
because it updated to deployment.
Thereafter, you can run kube control get pv
to get a list of all your PersistentVolumes.
And there you should find your host PersistentVolume using
the storageclass standard, which has a status of bound.
And if you run kube control get pvc
you find all your claims and there you should find
that one claim that was made.
And of course, if you get deployments
you should get your deployment
with the two up and running pods.
Which should now be using
this PersistentVolume as a volume.
So therefore, with all of that up and running
our service remained unchanged.
So that should still work.
Hence if you try to get a story,
we still get our text here
because I'm actually using the same host path here
for my PersistentVolume,
as I did before for the pod specific volume.
That's why the data is still there
because there's always was a path on the node
and therefore, no matter if it's a PersistentVolume
or the double kind of volume, the pod specific volume
it was the same path on the node.
And I also won't be able to show you much new behavior.
If we crashed this,
you will still see that the data is there
because we already had that before with host path.
The important difference now still is though
that this PersistentVolume is independent from
the path and from the node and the node independence is new.
And that we have this independence
not just with the host path,
but with any supported type for PersistentVolumes.
And you'll find these types in the official documentation.
So now we really have that standalone volume
and any part can now use our claim or we create a new claim
if we need a different claim configuration.
And we detached the volume and the volume configuration
from our path.
The only thing we do in the pod is reach out to our claim.
All the configuration, then is in the claim
and specifically in the PersistentVolume configuration.
And now we achieve pod and node independence.
So we learned about PersistentVolumes
and it's a powerful feature because it allows us
to store data in a way that will never be lost.
Because it's node and pod independent
and for some data that's crucial.
I wanna come back to that state
I talked about earlier in this module.
There, we learned about two types of data,
two types of state
and that was some application data like
user-generated data, user accounts, products in a shop,
anything like that.
And it would be intermediate results and temporary data.
Now in both cases, volumes are great solutions.
I wanna highlight though,
that for intermediate temporary results
pod specific volumes might be enough.
You might not need a PersistentVolume for that
though you of course could use it if you needed it
especially for the left kind of data.
So for the user generated data, user accounts and so on
for that PersistentVolumes are awesome
because your data is fully independent from the container
but also, from the pod and from the node
on which the pod runs if you use PersistentVolumes
and PersistentVolume claims.