WEBVTT 00:00.390 --> 00:04.740 Hello and welcome to this lecture on Persistent Volumes in Kubernetes. 00:04.740 --> 00:10.520 My name is Mumshad Mannambeth. Before we head into persistent volumes 00:10.530 --> 00:19.320 let us start with Volumes in Kubernetes. Let us look at volumes in Docker first. Docker containers are 00:19.320 --> 00:26.370 meant to be transient in nature which means they are meant to last only for a short period of time. 00:26.520 --> 00:31.950 They are called upon when required to process data and destroyed once finished. 00:31.950 --> 00:39.600 The same is true for the data within the container the data is destroyed along with the container to 00:39.610 --> 00:46.460 persist data processed by the containers we attach a volume to the containers when they are created. 00:46.510 --> 00:53.390 The data are processed by the container is now placed in this volume thereby retaining it permanently. 00:53.740 --> 01:00.700 Even if the container is deleted the data generated or processed by it remains. 01:00.720 --> 01:03.720 So how does that work in the Kubernetes world. 01:03.720 --> 01:09.030 Just as in Docker, the PODs created in Kubernetes are transient in nature. 01:09.180 --> 01:16.950 When a POD is created to process data and then deleted, the data processed by it gets deleted as well. 01:16.950 --> 01:25.560 For this we attach a volume to the POD. The data generated by the POD is now stored in the volume, and 01:25.590 --> 01:33.660 even after the POD is delete, the data remains. Let’s look at a simple implementation of volumes. 01:33.690 --> 01:36.780 We have a single node kubernetes cluster. 01:36.780 --> 01:42.840 We create a simple POD that generates a random between 1 and 100 and writes that to a file 01:43.200 --> 01:51.650 at /opt/number.out and then gets deleted along with the random number. To retain the 01:51.650 --> 01:53.730 number generated by the pod. 01:53.810 --> 01:58.250 We create a volume and a volume needs a storage. 01:58.310 --> 02:03.740 When you create a volume you can choose to configure it storage in different ways. 02:03.740 --> 02:10.010 We will look at the various options in a bit but for now we will simply configure it to use a directory 02:10.160 --> 02:11.380 on the host. 02:11.510 --> 02:17.210 In this case I specify a path /data on the host. 02:17.210 --> 02:24.320 This way any files created in the volume would be stored in the directory data on my node. Once the volume 02:24.320 --> 02:30.980 is created, to access it from a container we mount the volume to a directory inside the container. 02:31.130 --> 02:38.390 We use the volumeMounts field in each container to mount the data-volume to the directory /opt 02:38.540 --> 02:40.370 within the container. 02:40.370 --> 02:47.750 The random number will now be written to /opt mount inside the container, which happens to be on 02:47.750 --> 02:52.100 the data-volume which is in fact /data directory on the host. 02:52.700 --> 02:58.720 When the pod gets deleted, the file with the random number still lives on the host. 02:58.730 --> 03:03.050 Let's take a step back and look at the volume storage options. 03:03.300 --> 03:10.130 We just used the host path option to configure a directory and the host has storage space for the volume. 03:10.200 --> 03:17.880 Now that works fine on a single node however it is not recommended for use in a multi node cluster. 03:17.880 --> 03:24.930 This is because the PODs would use the /data directory on all the nodes, and expect all of them 03:24.930 --> 03:29.620 to be the same and have the same data since they are on different servers. 03:29.800 --> 03:36.510 They are in fact not the same unless you configure some kind of external replicated cluster storage 03:36.510 --> 03:37.620 solution. 03:37.650 --> 03:44.400 Kubernetes supports several types of standard storage solutions such as NFS, glusterFS, 03:44.400 --> 03:53.110 Flocker, FibreChannel, CephFS, ScaleIO or public cloud solutions like AWS 03:53.190 --> 03:58.700 EBS, Azure Disk or File or Google’s Persistent Disk. 03:59.630 --> 04:07.550 For example, to configure an AWS Elastic Block Store volume as the storage or the volume, we replace 04:07.690 --> 04:14.810 hostPath field of the volume with awsElasticBlockStore field along with the volumeID 04:15.080 --> 04:21.790 and filesystem type. The Volume storage will now be on AWS EBS. 04:21.880 --> 04:27.370 Well, that’s it about Volumes in Kubernetes. We will now head over to discuss Persistent Volumes 04:27.460 --> 04:27.910 next.