Let us now review the lab on storage class.
The first question is, how many StorageClasses
exist in the cluster.
Let's do a kubectl get storageclass.
We see one.
We can also do a sc to the StorageClasses.
That's the short form.
We see that there's just one StorageClass, so let's select one.
How about now?
How many StorageClasses exist in the cluster?
We just created a few more.
Let's try it again.
We see that there are three.
Setting things up.
What is the name of the StorageClass that does not support
dynamic volume provisioning?
We know that the provisioner is what defines
how the StorageClass volumes are provisioned,
so the no-provisioner is one
that does not support dynamic volume provisioning.
That's the StorageClass that does not support
dynamic volume provisioning.
That's local-storage.
What is the Volume Binding Mode used for the StorageClass,
the one identified in the previous question?
For this, the volume binding mode is WaitForFirstConsumer,
so this is the answer.
What is the Provisioner used for the StorageClass
called portworx-io-priority-high?
This is the StorageClass called portworx-io-priority-high
and the provisioner is portworx-volume.
Now, is there a PersistentVolumeClaim that is consuming the PersistentVolume
called local-pv?
Is there a PersistentVolumeClaim?
Let's look at PersistentVolumes
and PersistentVolumeClaims.
There are no PersistentVolumeClaims at all, so no is the answer.
Create a PersistentVolumeClaim by the name of local-pvc
that should bind to the volume local-pv.
We need to create a PVC with the name local-pvc
and if it is to bind to the PV, then it must have capacity,
which, yes, 500 megabytes.
That's correct.
Then the access modes should match, so this is ReadWriteOnce,
and the Storage class should also match, so that's local-storage.
We're going to create pvc.yaml with all that information.
Let's go and find persistent volume.
Let's select persistent volume and let's look at PVC.
Here, you have PVC.
We'll copy until here, we don't need the selectors.
Let's paste that here.
The name is local-pvc.
The access mode, as we've discussed it has to be RedWriteOnce, which is fine.
We don't need to specify the volume mode for now.
Storage is 500 megabytes
and the StorageClass name is local-storage.
That's what we saw.
Local storage. That's it.
Let's create the PVC.
Let's make sure it's created.
Now, what is the status of the newly created PersistentVolumeClaim?
It's in a pending state.
Now, why is the PVC in a pending state despite
making a valid request to claim the volume called local-pv?
We made sure that we got everything right.
The 500 megabytes of capacity, ReadWriteOnce access mode is matching,
the StorageClass is also matching.
Why is it that it was not created?
Let's look at the events.
Let's do a kubectl describe pvc local-pvc.
Here, we see that the reason is that it's waiting for first consumer,
waiting for the first consumer to be created before binding.
As we discussed, the WaitForFirstConsumer means
that it's not going to bind to a PV if it's not used.
It's just waiting for someone to use it for--
I get the volume to use it.
The Pod consuming the volume is now scheduled,
persistent Volume and Claim mismatch.
StorageClass not found.
This is the right answer.
The storage class called local-storage makes use of volume binding mode set
to WaitForFirstConsumer.
This will delay the binding and provisioning of a PersistentVolume
until a Pod using the PersistentVolumeClaim is created.
Create a new part called nginx with the image nginx:alpine.
Let's do that.
The Pod should make use of the PVC local-pvc
and mount the volume at the path /var/www/html,
the PV local-pv should be in a bound state.
Let's create a Pod called nginx
with the image nginx:alpine,
and then the Pod should make use of the local-pvc.
For that, we're going to convert this to yaml.
We're going to run it.
We're going to create a yaml file,
redirect it to nginx.yaml
We have all of these details in there.
Now what we need to do is we need to first configure the volume
and the volume mount.
We need the volume section and the volume
has to come from the local-pvc.
Let's look at claims as volumes, and here you have example
of using a claim as volume.
You already have a volume section, so you just need this.
Make sure to fix the format.
We have volumes and the name is going to be,
let's let's name it as local-pvc volume.
Now the claim name has to be local-pvc.
The next thing is we need the volume mount, which is inside the container,
but the volume is on the spec level at the Pod and the volume mount
is inside the container.
Let's do that.
We have the volume mount and the volume mount says,
you can see here, it's at /var/www/html which is right.
The name of the volume is the name that we've given here.
It's going to be this.
If the question does not ask you to use a specific name,
you can use any name.
Just make sure that this name and this name matches.
That's when this volume is going to get mount to this directory.
Let's save that and let's create that file.
Let's see the status of the Pod.
It's created, but it's not in the running state.
Give it a second.
Yes, it's in the running state.
That's successful.
Let's check the status of the PVC now.
We now see that it's in a bound state, so it's in a bound state.
As soon as a volume use that PVC, it went into a bound state.
Create a new StorageClass called delayed-volume-sc that makes use
of the below specs provisioner and volumeBindingMode.
Let's do that.
Let's first create a file called,
delayed-volume-sc.yaml.
We need a template for a StorageClass so let's search for StorageClass.
We're going to use this.
Let's use the first few lines.
Now the name
is going to be delayed-volume-sc.
The provisioner is going to be
no-provisioner
and volumeBindingMode is this,
is going to be WaitForFirstConsumer.
That is WaitForFirstConsumer. Yes.
This seems to be it.
Let's create that StorageClass.
The StorageClass is created.
Let's check it out.
Yes, it's created with the no-provisioner
and the WaitForFirstConsumer
while in binding mount. Good.
Hey, that's successful.
That's the end of this lab.