WEBVTT

00:00.720 --> 00:03.460
Let's go through the lab
on persistent volumes

00:03.540 --> 00:05.799
and persistent volume claims.

00:05.879 --> 00:06.980
We have deployed a pod.

00:07.060 --> 00:10.080
Inspect the pod and wait for it
to start running.

00:10.160 --> 00:12.650
Let's do that.

00:12.730 --> 00:17.109
We have the webapp pod,
and it's in running state.

00:17.189 --> 00:24.070
The application stores logs at location,
/log/app.log.

00:24.150 --> 00:25.706
View the logs.

00:28.539 --> 00:33.840
In order to view a file within the pod,
we'll do a kubectl exec

00:33.920 --> 00:36.086
and provide the pod name,

00:36.166 --> 00:41.881
and then the command, so cat/log/app.log.

00:43.454 --> 00:49.710
We're able to view the logs
and we see some of the events

00:49.790 --> 00:53.500
that are logged by the application.

00:54.893 --> 00:59.831
Now, if the pod was to get deleted now,
would you be able to view the logs?

01:02.030 --> 01:06.162
Let's check out where those logs are.

01:09.188 --> 01:11.934
Describe pod webapp.

01:18.960 --> 01:20.620
There are no other volumes configured.

01:20.700 --> 01:25.120
You have the kube-api-access,
which is the default volume,

01:25.200 --> 01:28.230
but there are no other volumes.

01:28.310 --> 01:32.160
Anything that's stored in the logapp.log
is stored within the container,

01:32.240 --> 01:33.160
within the pod.

01:33.240 --> 01:36.460
If the pod gets deleted,
the logs get deleted as well.

01:36.540 --> 01:38.899
Would you be able to view logs?

01:38.979 --> 01:42.910
No, we're not going to be able
to view the logs.

01:44.352 --> 01:49.779
Now, configure a volume to store
these logs at this path on the host.

01:49.859 --> 01:53.452
Currently, all the logs are stored

01:53.532 --> 01:57.160
at /log/app.log within the pod

01:57.240 --> 01:59.749
or within the container.

01:59.829 --> 02:06.139
Now, we'd like to use the volume
to store those logs at var/log/webapp.

02:06.219 --> 02:12.216
That's var/log/webapp on the host.

02:12.297 --> 02:13.813
Currently, there's nothing here.

02:15.440 --> 02:18.250
Let's try and set up a volume.

02:18.330 --> 02:24.255
We're going to edit the pod,
so we'll do a kubectl edit pod webapp.

02:27.330 --> 02:28.320
There's a lot of information.

02:28.400 --> 02:31.560
Here, we have the volumeMount,
which is the default volumeMount

02:31.640 --> 02:35.400
for accessing the kube API server.

02:35.480 --> 02:41.520
Below we have the volumes, which is again,
the default volume used for that.

02:41.600 --> 02:45.660
We're just going to add
our own volume here.

02:48.972 --> 02:52.620
We'll call the volume log-volume
because we're going to use this

02:52.700 --> 02:53.790
to store the logs.

02:53.870 --> 02:58.510
This is going to be a hostPath.

02:58.590 --> 03:04.100
The path is going to be whatever path

03:04.180 --> 03:10.420
is given here, which is var/log/webapp.

03:10.500 --> 03:11.820
var/log/webapp.

03:11.900 --> 03:12.820
We have the volume.

03:12.900 --> 03:16.680
Basically, what's going to happen
is when this pod is recreated,

03:16.760 --> 03:21.330
it is going to mount this directory,
and we're supposed to specify

03:21.410 --> 03:23.090
where it's going to be mounted to.

03:23.170 --> 03:25.730
It's going to create a volume
out of that directory

03:25.810 --> 03:29.650
and then we have to specify
where it's going to mount it.

03:29.730 --> 03:31.580
We're going to add a volumeMount,

03:31.660 --> 03:35.360
and we'll call the mountPath

03:36.527 --> 03:39.265
as it is above.

03:39.980 --> 03:42.788
That would be a log,

03:44.599 --> 03:47.540
and then we will have a name

03:51.465 --> 03:54.652
for the volume,
and the name of the volume is log-volume.

03:58.165 --> 04:01.400
What's going to happen
is when the pod is recreated,

04:01.480 --> 04:07.310
is going to create a volume
which will store all data in this path,

04:07.390 --> 04:09.940
on the host,
and it'll be called as log-volume.

04:10.020 --> 04:14.130
Then we can mount this volume
within any container on this pod.

04:14.210 --> 04:16.420
Here, there's only one container.

04:16.500 --> 04:20.330
Under volumeMounts, we have the mountPath,
and we're going to specify

04:20.410 --> 04:23.182
the name of the volume
and it's going to mount that here.

04:23.263 --> 04:25.540
Basically, this is going to be mount

04:25.621 --> 04:28.662
to this path within the container. Okay.

04:29.548 --> 04:32.383
Let's try and save that.
Here's the pod.

04:32.463 --> 04:38.702
It's not going to allow us to save there.
We're going to do a kubectl replace force.

04:49.454 --> 04:51.997
Okay.
This part is now recreated.

04:53.496 --> 04:58.486
Now, let's check the path
at var/log/webapp.

05:01.680 --> 05:06.050
We can see that the file that stores
the logs called app.org is in this path.

05:06.130 --> 05:07.989
We'll do app.log.

05:08.069 --> 05:11.420
You see the logs of the pod
are indeed here.

05:11.500 --> 05:16.430
The logs of the pod are now available
on the host of this particular path.

05:16.510 --> 05:20.699
That indicates that that's working.

05:20.779 --> 05:23.959
The next task is to create
a persistent volume

05:24.039 --> 05:25.100
with a given specification.

05:25.180 --> 05:29.130
Let's go to the Kubernetes
documentation pages

05:29.210 --> 05:33.066
and find persistent volume.

05:34.289 --> 05:36.156
We go to persistent volumes.

05:44.752 --> 05:47.119
Here we have a template for a pod.

05:47.199 --> 05:50.619
This is the volume claim.

05:50.699 --> 05:51.889
Persistent volume.

05:53.099 --> 05:56.242
This doesn't have enough information,
so I'm just going to keep poking.

05:59.559 --> 06:02.369
This is the persistent volume.

06:02.449 --> 06:07.229
I'm going to get copy this much.

06:11.562 --> 06:12.508
[?].

06:12.786 --> 06:16.928
I'm going to create a file called pv.yaml

06:17.008 --> 06:22.240
for persistent volume. Okay.

06:23.819 --> 06:28.000
Then here we have pv-log.

06:31.356 --> 06:33.190
There's the persistent volume name.

06:33.270 --> 06:35.238
Then we have storage.

06:36.569 --> 06:41.485
That's 100 mebibytes.

06:41.969 --> 06:43.429
Then we have volume modes.

06:43.509 --> 06:45.170
We don't need volume mode.

06:46.643 --> 06:47.981
We have access mode.

06:53.430 --> 06:57.567
Access mode is ReadWriteMany.

06:59.590 --> 07:01.935
The persistent volume reclaim policy

07:02.648 --> 07:05.707
is going to be retain.

07:08.360 --> 07:14.665
Then the type is going to be hostPath,
we're going to give the hostPath.

07:15.449 --> 07:18.829
Then we specify the path.

07:18.909 --> 07:24.080
That's going to be /pv/log.

07:24.286 --> 07:25.595
That's the path.

07:29.159 --> 07:31.899
Let's create the file.

07:34.124 --> 07:35.230
That's created.

07:35.310 --> 07:37.389
Let's check it out.

07:37.469 --> 07:40.750
We have the pv-log, 100Mi capacity,
ReadWriteMany,

07:40.830 --> 07:44.399
so this indicates ReadWriteMany,
and the reclaim policy is retain.

07:44.479 --> 07:46.329
Let's check our work.

07:47.529 --> 07:48.449
Okay.

07:48.826 --> 07:51.889
Now, let us claim
some of that storage for application.

07:51.969 --> 07:54.952
Create a persistent volume claim
with the given specification.

07:57.219 --> 08:02.929
Let's find
a persistent volume claim template.

08:06.177 --> 08:09.239
We had one here.

08:13.883 --> 08:16.980
Right here,
I have persistent volume claims.

08:17.060 --> 08:19.239
We'll use this template.

08:19.319 --> 08:21.869
We don't need the advanced selectors.

08:21.949 --> 08:26.850
Our use case is simple
so we're just going to copy this much.

08:27.892 --> 08:30.893
Let's do a pvc.yaml.

08:36.174 --> 08:37.805
We have persistent volume claim.

08:42.839 --> 08:46.205
The name is going to be claim-log-1.

08:49.180 --> 08:52.054
Access mode is going to be

08:52.627 --> 08:56.993
ReadWriteOnce.

09:01.984 --> 09:03.933
We don't need a volume mode.

09:04.570 --> 09:08.319
The storage is going to be 50Mi.

09:16.157 --> 09:22.224
Now we're going to create -f pvc.

09:22.351 --> 09:23.772
Let's check out the status.

09:25.551 --> 09:26.860
That's created.

09:28.151 --> 09:30.150
Let's go next.

09:30.230 --> 09:31.870
What is the state
of the persistent volume claim?

09:31.950 --> 09:37.040
If you look at the state,
it is in a pending state. That's that.

09:37.120 --> 09:42.819
Now, what is the state
of the persistent volume?

09:42.899 --> 09:47.780
Still the persistent volume,
it is available.

09:47.860 --> 09:51.949
Let's try it now again.

09:52.029 --> 09:53.919
It's in an unavailable state.

09:56.959 --> 10:02.140
Why is the claim not bound

10:02.220 --> 10:06.670
which has 100 mebibytes of capacity,
and then we have the PVC

10:06.750 --> 10:10.080
which requested about 50,
but it's still in a pending state.

10:10.160 --> 10:11.150
Why is that?

10:11.230 --> 10:13.929
If you look at it,
it's not a capacity mismatch

10:14.009 --> 10:18.400
because we know that when you create
a persistent volume claim,

10:18.480 --> 10:19.400
if there's a volume

10:19.480 --> 10:24.660
it's going to bind that volume
to that persistent volume claim.

10:24.740 --> 10:25.850
That's not the case here.

10:25.930 --> 10:27.460
We have the reclaim policy set.

10:27.540 --> 10:32.410
The name of these policy
is the PV and PVC does not really matter.

10:32.490 --> 10:35.350
The only other thing that it looks at
is the access mode.

10:36.376 --> 10:40.870
If you look at the PV that we created,

10:41.558 --> 10:44.020
it had an access mode ReadWriteMany.

10:44.100 --> 10:47.501
If you look at the PVC,

10:48.485 --> 10:50.766
it has ReadWriteOnce.

10:54.399 --> 10:55.390
That's the reason.

10:55.470 --> 10:58.249
Access mode mismatch is the reason.

10:58.329 --> 11:02.580
Now, the next question is update
the access mode on the claim

11:02.660 --> 11:05.179
to bind it to the PV.

11:05.259 --> 11:10.770
We're going to do an update on the claim.

11:14.893 --> 11:20.410
We want to change the access mode
on the PVC to ReadWriteMany,

11:20.490 --> 11:22.178
which is on the PV.

11:24.220 --> 11:26.684
That's what is requested here.

11:43.366 --> 11:50.362
Now we're going to do
a replace force -f PVC.

11:59.750 --> 12:03.790
Now, you requested for 50 mebibytes,
how much capacity

12:03.870 --> 12:06.770
is now available to the PVC?

12:06.850 --> 12:08.689
Let's look at that.

12:10.256 --> 12:15.766
Let's do a kubectl get PV, kubectl get PVC.

12:16.990 --> 12:22.504
If you look at the PVC,
the capacity that it has is 100 mebibytes.

12:26.488 --> 12:29.710
Now, update the webapp pod to use
the persistent volume claim

12:29.790 --> 12:31.699
as its storage.

12:31.779 --> 12:35.569
What we're going to do now
is we're going to replace hostPath

12:35.649 --> 12:40.080
with the persistent volume claim
to use the persistent volume claim.

12:40.160 --> 12:45.874
Before that we've created the PV to store

12:45.954 --> 12:51.160
the logs, to use the hostPath at ls/pv/log.

12:51.240 --> 12:53.030
Right now, there is nothing in there.

12:53.699 --> 12:57.680
Let's go ahead and edit the pod webapp.

13:01.620 --> 13:02.540
This is okay.

13:02.620 --> 13:04.240
The MountPath,
we're going to leave it as this.

13:04.320 --> 13:09.340
We're going to go down
and we're going to change this

13:10.028 --> 13:14.677
from hostPath to persistent.

13:18.129 --> 13:19.470
Let's see what that is.

13:19.550 --> 13:20.976
If you look here,

13:26.542 --> 13:27.540
we should be able to see how to use

13:27.620 --> 13:30.920
a persistent volume in a pod.

13:33.988 --> 13:37.319
You have claim as volumes.

13:37.399 --> 13:41.420
Within volumes,
you use the persistent volume claim.

13:41.500 --> 13:42.968
That's what we're looking for.

13:50.750 --> 13:53.379
You have claim name.

13:57.521 --> 13:59.530
We don't need these lines.

14:10.399 --> 14:15.119
Then the claim name
is going to be claim-log-1.

14:21.141 --> 14:25.956
You have persistent volume claim,
claim name, and log-1.

14:26.037 --> 14:27.569
That should be it.

14:33.930 --> 14:37.670
Let's replace the file.

14:37.750 --> 14:43.449
Let's replace the pod forcefully. Okay.

14:43.529 --> 14:44.699
That is done.

14:44.779 --> 14:47.299
Let's check our work. All right.

14:48.652 --> 14:53.759
Now let's see if you look at /pv/log,

14:54.547 --> 14:56.030
you see the logs there,

14:56.110 --> 15:00.257
and if you look at log/app.log,

15:00.337 --> 15:03.890
you can see lots of the application there.

15:03.970 --> 15:07.135
Now, the PV is using a hostPath

15:07.215 --> 15:12.929
as the location for storing data,

15:13.250 --> 15:16.299
but then the PV
is then claimed by the PVC,

15:16.379 --> 15:19.190
and then the PVC is configured
as a volume for the pod,

15:19.270 --> 15:23.559
and then that's how it is mounted
to the pod.

15:23.639 --> 15:25.290
That's how this is working right now.

15:25.370 --> 15:28.509
The next question is,
what is the reclaim policy set

15:28.589 --> 15:30.629
on the persistent volume pv-log.

15:30.709 --> 15:31.629
Let's see.

15:31.709 --> 15:35.770
Kubectl get pv pv-log.

15:37.595 --> 15:42.929
We can see that it is retained,
so retain is the answer.

15:43.860 --> 15:48.080
Now, what would happen to the PV
if the PVC was destroyed?

15:48.160 --> 15:54.199
We know that with the reclaim policy set
to retain, the pv is going to be retained,

15:54.279 --> 15:57.150
so it's not going to be deleted
along with the PVC.

15:57.230 --> 15:59.590
The PV is greater as well. No.

15:59.670 --> 16:00.650
The PV is made available again.

16:00.730 --> 16:04.590
No, it's not made available again,
that will be recycling.

16:04.670 --> 16:05.590
The PV is scrubbed.

16:05.670 --> 16:07.759
No, the PV is not deleted,
but not available.

16:07.839 --> 16:11.080
It's not deleted,
but it's not available either.

16:11.160 --> 16:12.581
That's the status.

16:14.976 --> 16:18.259
Now, try deleting the PVC
and notice what happens.

16:18.339 --> 16:22.478
Let's do that. Get pvc.

16:23.019 --> 16:26.784
Delete pvc claim-log-1.

16:28.069 --> 16:30.540
Let's wait for that to be deleted.

16:32.559 --> 16:37.669
It's not going to get deleted
because it's actually going to be statless.

16:37.749 --> 16:40.100
Let's look at the status
in a new terminal.

16:40.180 --> 16:44.160
Let's do a kubectl get pvc,
and we see that it's in a terminating state,

16:44.240 --> 16:46.595
so it's stuck in a terminating state.

16:49.589 --> 16:51.460
Let's do a describe.

16:57.655 --> 16:59.211
Yes, so you see it's stuck
in a terminating state

16:59.300 --> 17:02.960
for the last 30 seconds or so.

17:03.040 --> 17:06.070
Why is the PVC stuck
in a terminating state?

17:06.150 --> 17:11.869
That's obviously because it is associated,
has a volume with a pod,

17:11.949 --> 17:13.540
so it is being used by a pod.

17:13.620 --> 17:17.550
That's the reason it's stuck
in a terminating state.

17:17.630 --> 17:19.129
Now let's now delete the webapp pod.

17:19.209 --> 17:22.009
Let's go ahead and do that.

17:22.089 --> 17:25.205
Let's delete pod webapp,

17:26.431 --> 17:27.660
and let's see what happens.

17:30.720 --> 17:36.430
Okay, so that was deleted,
and we see we're now unstuck

17:36.510 --> 17:39.610
and the PV was deleted as well.

17:39.690 --> 17:41.430
Let's check that out.

17:41.510 --> 17:44.870
Yes, the pod was deleted
and the PVC was deleted as well.

17:44.950 --> 17:47.180
What is state of the PVC now?

17:47.260 --> 17:49.010
It is deleted.

17:51.249 --> 17:53.520
What is the state of the PV now?

17:53.600 --> 17:55.450
Let's try that.

17:56.780 --> 18:02.404
We see that it is in a released state.

18:07.741 --> 18:10.760
Okay, so that's the end of this lab.