WEBVTT

00:00.620 --> 00:04.370
Let us now review the lab
on storage class.

00:04.450 --> 00:06.250
The first question is,
how many StorageClasses

00:06.330 --> 00:07.449
exist in the cluster.

00:07.529 --> 00:11.419
Let's do a kubectl get storageclass.

00:12.100 --> 00:13.086
We see one.

00:13.167 --> 00:17.090
We can also do a sc to the StorageClasses.

00:17.170 --> 00:18.310
That's the short form.

00:18.390 --> 00:22.767
We see that there's just one StorageClass,
so let's select one.

00:27.740 --> 00:28.660
How about now?

00:28.740 --> 00:29.930
How many StorageClasses exist
in the cluster?

00:30.010 --> 00:31.310
We just created a few more.

00:31.390 --> 00:32.690
Let's try it again.

00:32.770 --> 00:34.487
We see that there are three.

00:39.380 --> 00:40.350
Setting things up.

00:40.430 --> 00:43.240
What is the name of the StorageClass
that does not support

00:43.320 --> 00:45.749
dynamic volume provisioning?

00:45.829 --> 00:51.159
We know that the provisioner
is what defines

00:51.239 --> 00:54.840
how the StorageClass volumes are provisioned,

00:55.507 --> 00:58.840
so the no-provisioner is one

00:58.920 --> 01:03.400
that does not support
dynamic volume provisioning.

01:03.480 --> 01:08.240
That's the StorageClass
that does not support

01:08.320 --> 01:09.540
dynamic volume provisioning.

01:09.620 --> 01:11.427
That's local-storage.

01:14.800 --> 01:18.180
What is the Volume Binding Mode
used for the StorageClass,

01:18.260 --> 01:21.080
the one identified in the previous question?

01:21.160 --> 01:25.920
For this, the volume binding mode
is WaitForFirstConsumer,

01:26.000 --> 01:27.567
so this is the answer.

01:30.500 --> 01:32.910
What is the Provisioner used
for the StorageClass

01:32.990 --> 01:35.350
called portworx-io-priority-high?

01:35.430 --> 01:39.120
This is the StorageClass called
portworx-io-priority-high

01:39.200 --> 01:41.700
and the provisioner is portworx-volume.

01:47.493 --> 01:51.370
Now, is there a PersistentVolumeClaim
that is consuming the PersistentVolume

01:51.450 --> 01:54.920
called local-pv?

01:55.000 --> 01:57.640
Is there a PersistentVolumeClaim?

01:57.720 --> 02:00.653
Let's look at PersistentVolumes

02:00.733 --> 02:04.040
and PersistentVolumeClaims.

02:05.330 --> 02:09.860
There are no PersistentVolumeClaims at all,
so no is the answer.

02:12.799 --> 02:16.960
Create a PersistentVolumeClaim
by the name of local-pvc

02:17.040 --> 02:20.907
that should bind to the volume local-pv.

02:22.340 --> 02:25.340
We need to create a PVC
with the name local-pvc

02:25.420 --> 02:29.760
and if it is to bind to the PV,
then it must have capacity,

02:29.840 --> 02:33.169
which, yes, 500 megabytes.

02:33.249 --> 02:34.570
That's correct.

02:34.650 --> 02:38.840
Then the access modes should match,
so this is ReadWriteOnce,

02:38.920 --> 02:43.700
and the Storage class should also match,
so that's local-storage.

02:43.780 --> 02:50.689
We're going to create pvc.yaml
with all that information.

02:51.393 --> 02:57.433
Let's go and find persistent volume.

02:58.109 --> 03:03.330
Let's select persistent volume
and let's look at PVC.

03:03.410 --> 03:07.669
Here, you have PVC.

03:07.749 --> 03:12.233
We'll copy until here,
we don't need the selectors.

03:14.120 --> 03:15.640
Let's paste that here.

03:16.379 --> 03:19.879
The name is local-pvc.

03:21.867 --> 03:26.310
The access mode, as we've discussed
it has to be RedWriteOnce, which is fine.

03:26.390 --> 03:30.930
We don't need to specify
the volume mode for now.

03:31.010 --> 03:35.327
Storage is 500 megabytes

03:36.013 --> 03:41.180
and the StorageClass name is local-storage.

03:41.260 --> 03:44.219
That's what we saw.

03:44.299 --> 03:46.670
Local storage. That's it.

03:46.750 --> 03:51.049
Let's create the PVC.

03:51.129 --> 03:55.489
Let's make sure it's created.

03:58.913 --> 04:02.629
Now, what is the status
of the newly created PersistentVolumeClaim?

04:02.709 --> 04:04.433
It's in a pending state.

04:08.153 --> 04:10.639
Now, why is the PVC
in a pending state despite

04:10.719 --> 04:14.299
making a valid request
to claim the volume called local-pv?

04:14.379 --> 04:16.050
We made sure that we got everything right.

04:16.130 --> 04:21.020
The 500 megabytes of capacity,
ReadWriteOnce access mode is matching,

04:21.100 --> 04:24.730
the StorageClass is also matching.

04:24.810 --> 04:27.250
Why is it that it was not created?

04:27.330 --> 04:28.250
Let's look at the events.

04:28.330 --> 04:33.926
Let's do a kubectl describe pvc local-pvc.

04:37.187 --> 04:42.059
Here, we see that the reason
is that it's waiting for first consumer,

04:42.139 --> 04:47.640
waiting for the first consumer
to be created before binding.

04:47.720 --> 04:50.990
As we discussed,
the WaitForFirstConsumer means

04:51.070 --> 04:56.730
that it's not going to bind to a PV
if it's not used.

04:56.810 --> 04:58.920
It's just waiting for someone
to use it for--

04:59.000 --> 05:01.260
I get the volume to use it.

05:01.340 --> 05:04.030
The Pod consuming the volume
is now scheduled,

05:04.110 --> 05:05.920
persistent Volume and Claim mismatch.

05:06.000 --> 05:08.739
StorageClass not found.

05:08.819 --> 05:10.553
This is the right answer.

05:13.319 --> 05:18.200
The storage class called local-storage
makes use of volume binding mode set

05:18.280 --> 05:20.269
to WaitForFirstConsumer.

05:20.349 --> 05:23.250
This will delay the binding
and provisioning of a PersistentVolume

05:23.330 --> 05:26.887
until a Pod using
the PersistentVolumeClaim is created.

05:27.919 --> 05:31.630
Create a new part called nginx
with the image nginx:alpine.

05:32.613 --> 05:33.913
Let's do that.

05:36.379 --> 05:39.170
The Pod should make use
of the PVC local-pvc

05:39.250 --> 05:44.309
and mount the volume
at the path /var/www/html,

05:44.389 --> 05:46.913
the PV local-pv
should be in a bound state.

05:47.430 --> 05:52.593
Let's create a Pod called nginx

05:53.387 --> 05:58.827
with the image nginx:alpine,

06:00.500 --> 06:02.260
and then the Pod
should make use of the local-pvc.

06:02.340 --> 06:07.080
For that,
we're going to convert this to yaml.

06:09.199 --> 06:10.312
We're going to run it.

06:10.393 --> 06:11.793
We're going to create a yaml file,

06:13.167 --> 06:16.320
redirect it to nginx.yaml

06:21.320 --> 06:23.492
We have all of these details in there.

06:23.580 --> 06:26.239
Now what we need to do is we need
to first configure the volume

06:26.319 --> 06:27.627
and the volume mount.

06:28.069 --> 06:33.499
We need the volume section and the volume

06:33.579 --> 06:36.593
has to come from the local-pvc.

06:37.939 --> 06:43.090
Let's look at claims as volumes,
and here you have example

06:43.170 --> 06:44.959
of using a claim as volume.

06:45.039 --> 06:48.190
You already have a volume section,
so you just need this.

06:52.159 --> 06:56.750
Make sure to fix the format.

06:58.033 --> 07:03.679
We have volumes
and the name is going to be,

07:03.759 --> 07:08.213
let's let's name it as local-pvc volume.

07:10.919 --> 07:17.253
Now the claim name has to be local-pvc.

07:20.699 --> 07:26.130
The next thing is we need the volume mount,
which is inside the container,

07:26.210 --> 07:29.531
but the volume is on the spec level
at the Pod and the volume mount

07:29.611 --> 07:32.220
is inside the container.

07:32.300 --> 07:34.010
Let's do that.

07:34.090 --> 07:37.910
We have the volume mount
and the volume mount says,

07:37.990 --> 07:42.013
you can see here,
it's at /var/www/html which is right.

07:45.319 --> 07:48.860
The name of the volume is the name
that we've given here.

07:50.080 --> 07:51.760
It's going to be this.

07:52.273 --> 07:55.669
If the question does not ask you
to use a specific name,

07:55.749 --> 07:57.339
you can use any name.

07:57.419 --> 08:00.250
Just make sure that this name
and this name matches.

08:00.330 --> 08:05.253
That's when this volume
is going to get mount to this directory.

08:06.430 --> 08:12.820
Let's save that and let's create that file.

08:14.160 --> 08:16.030
Let's see the status of the Pod.

08:16.110 --> 08:17.579
It's created,
but it's not in the running state.

08:17.659 --> 08:19.170
Give it a second.

08:19.250 --> 08:22.320
Yes, it's in the running state.

08:22.400 --> 08:25.470
That's successful.

08:25.550 --> 08:29.660
Let's check the status of the PVC now.

08:29.740 --> 08:34.240
We now see that it's in a bound state,
so it's in a bound state.

08:34.320 --> 08:39.540
As soon as a volume use that PVC,
it went into a bound state.

08:39.620 --> 08:45.350
Create a new StorageClass called
delayed-volume-sc that makes use

08:45.430 --> 08:49.653
of the below specs provisioner
and volumeBindingMode.

08:51.647 --> 08:52.950
Let's do that.

08:53.030 --> 08:55.267
Let's first create a file called,

08:56.520 --> 09:01.547
delayed-volume-sc.yaml.

09:05.750 --> 09:11.613
We need a template for a StorageClass
so let's search for StorageClass.

09:13.940 --> 09:15.960
We're going to use this.

09:17.113 --> 09:19.564
Let's use the first few lines.

09:21.300 --> 09:23.800
Now the name

09:23.881 --> 09:29.388
is going to be delayed-volume-sc.

09:30.420 --> 09:32.398
The provisioner is going to be

09:35.307 --> 09:37.820
no-provisioner

09:40.820 --> 09:47.233
and volumeBindingMode is this,

09:49.347 --> 09:51.680
is going to be WaitForFirstConsumer.

09:52.973 --> 09:55.850
That is WaitForFirstConsumer. Yes.

09:58.080 --> 10:00.300
This seems to be it.

10:00.380 --> 10:04.320
Let's create that StorageClass.

10:07.407 --> 10:09.740
The StorageClass is created.

10:10.570 --> 10:11.660
Let's check it out.

10:11.740 --> 10:16.287
Yes, it's created with the no-provisioner

10:16.367 --> 10:19.027
and the WaitForFirstConsumer

10:19.740 --> 10:21.920
while in binding mount. Good.

10:22.780 --> 10:24.160
Hey, that's successful.

10:25.007 --> 10:26.740
That's the end of this lab.