WEBVTT

00:00.170 --> 00:01.160
In this lecture,

00:01.290 --> 00:03.410
we will look at storage classes.

00:04.520 --> 00:05.800
In the previous lectures,

00:05.870 --> 00:06.810
we discussed about

00:06.880 --> 00:08.850
how to create PVs

00:09.010 --> 00:10.560
and then create PVCs

00:10.650 --> 00:11.840
to claim that storage

00:11.910 --> 00:13.580
and then use the PVCs

00:13.770 --> 00:16.580
in the pod definition files as volumes.

00:17.450 --> 00:18.280
In this case,

00:18.440 --> 00:20.030
we create a PVC

00:20.090 --> 00:22.350
from a Google cloud persistent disk.

00:23.190 --> 00:24.910
The problem here is that

00:24.980 --> 00:27.200
before this PV is created,

00:27.400 --> 00:29.150
you must have created the disk

00:29.210 --> 00:30.280
on Google cloud.

00:31.060 --> 00:33.760
Every time an application requires storage,

00:33.980 --> 00:36.780
you have to first manually provision the disk

00:36.830 --> 00:37.830
on Google cloud

00:38.020 --> 00:39.240
and then manually create

00:39.290 --> 00:41.530
a persistent volume definition file

00:41.710 --> 00:42.940
using the same name

00:43.060 --> 00:45.050
as that of the disk that you created.

00:46.110 --> 00:48.920
That's called static provisioning volumes.

00:49.020 --> 00:50.320
It would have been nice

00:50.380 --> 00:52.890
if the volume gets provisioned automatically

00:52.940 --> 00:55.000
when the application requires it

00:55.750 --> 00:58.140
and that's where storage classes come in.

00:59.050 --> 01:00.680
With storage classes,

01:00.880 --> 01:02.790
you can define a provisioner

01:02.830 --> 01:04.490
such as Google storage

01:04.630 --> 01:07.260
that can automatically provision storage

01:07.390 --> 01:08.490
on Google cloud

01:08.610 --> 01:10.700
and attach that to pods

01:10.820 --> 01:11.930
when a claim is made.

01:12.610 --> 01:16.070
That's called dynamic provisioning of volumes.

01:16.710 --> 01:17.530
You do that

01:17.600 --> 01:19.770
by creating a storage class object

01:19.840 --> 01:21.100
with the API version

01:21.170 --> 01:24.400
set to storage.k8s.io/v one,

01:24.740 --> 01:27.230
specify a name and use provisioner

01:27.290 --> 01:31.910
as kubernetes.io/gce-pd.

01:34.080 --> 01:36.200
Going back to our original state

01:36.260 --> 01:37.460
where we have a pod

01:37.510 --> 01:39.770
using a PVC for its storage

01:40.030 --> 01:42.860
and the PVC is bound to APV,

01:43.200 --> 01:45.390
we now have a storage class,

01:45.970 --> 01:49.040
so we no longer need the PV definition

01:49.140 --> 01:52.190
because the PV and any associated storage

01:52.350 --> 01:54.990
is going to be created automatically

01:55.130 --> 01:56.860
when the storage class is created.

01:58.110 --> 02:01.130
For the PVC to use the storage class we defined,

02:01.400 --> 02:04.090
we specify the storage class name

02:04.190 --> 02:05.850
in the PVC definition.

02:07.920 --> 02:09.580
That's how the PVC knows

02:09.630 --> 02:11.360
which storage class to use.

02:12.010 --> 02:14.070
Next time, if PVC is created,

02:14.310 --> 02:16.620
the storage class associated with it

02:16.740 --> 02:19.000
uses the defined provisioner

02:19.140 --> 02:20.840
to provision a new disk

02:20.930 --> 02:23.220
with the required size on GCP

02:23.620 --> 02:25.780
and then creates a persistent volume

02:25.910 --> 02:28.830
and then binds the PVC to that volume.

02:29.410 --> 02:32.660
Remember that it still creates a PV.

02:32.740 --> 02:33.410
It's just that

02:33.480 --> 02:36.000
you don't have to manually create PV anymore.

02:36.210 --> 02:37.870
It's created automatically

02:37.980 --> 02:39.440
by the storage class.

02:40.870 --> 02:43.530
We used the GCE provisioner

02:43.590 --> 02:45.530
to create a volume on GCP.

02:46.080 --> 02:48.280
There are many other provisioners as well,

02:48.360 --> 02:50.540
such as for AWSEBS,

02:50.790 --> 02:51.790
AzureFile,

02:51.840 --> 02:52.700
AzureDisk,

02:53.020 --> 02:54.110
CephFS,

02:54.410 --> 02:55.240
Portworx,

02:55.460 --> 02:57.220
ScaleIO and so on.

02:58.240 --> 03:00.270
With each of these provisioners,

03:00.390 --> 03:02.790
you can pass in additional parameters,

03:02.850 --> 03:05.420
such as the type of disk to provision,

03:05.690 --> 03:07.660
the replication type, et cetera.

03:08.150 --> 03:10.460
These parameters are very specific

03:10.540 --> 03:12.690
to the provisioner that you're using.

03:13.040 --> 03:14.540
For Google persistent disk,

03:14.660 --> 03:16.250
you can specify the type

03:16.440 --> 03:18.640
which could be standard or SSD.

03:18.900 --> 03:21.330
You can specify the replication mode,

03:21.390 --> 03:24.840
which could be none or regional PD.

03:26.050 --> 03:26.860
You see,

03:26.930 --> 03:29.900
you can create different storage classes,

03:30.000 --> 03:32.070
each using different types of disk.

03:32.220 --> 03:32.930
For example,

03:32.990 --> 03:35.770
a silver storage class with the standard disk,

03:35.850 --> 03:38.150
a gold class with SSD drives

03:38.270 --> 03:39.450
and a platinum class

03:39.550 --> 03:41.910
with SSD drives and replication.

03:42.560 --> 03:45.480
That's why it's called storage class.

03:45.930 --> 03:48.930
You can create different classes of service.

03:49.520 --> 03:52.030
Next time you create a PVC,

03:52.190 --> 03:53.860
you can simply specify

03:54.010 --> 03:55.590
the class of storage

03:55.650 --> 03:57.710
you need for your volumes