1

00:00:00,390 --> 00:00:04,740

Hello and welcome to this lecture on Persistent Volumes in Kubernetes.



2

00:00:04,740 --> 00:00:10,520

My name is Mumshad Mannambeth. Before we head into persistent volumes



3

00:00:10,530 --> 00:00:19,320

let us start with Volumes in Kubernetes. Let us look at volumes in Docker first. Docker containers are



4

00:00:19,320 --> 00:00:26,370

meant to be transient in nature which means they are meant to last only for a short period of time.



5

00:00:26,520 --> 00:00:31,950

They are called upon when required to process data and destroyed once finished.



6

00:00:31,950 --> 00:00:39,600

The same is true for the data within the container the data is destroyed along with the container to



7

00:00:39,610 --> 00:00:46,460

persist data processed by the containers we attach a volume to the containers when they are created.



8

00:00:46,510 --> 00:00:53,390

The data are processed by the container is now placed in this volume thereby retaining it permanently.



9

00:00:53,740 --> 00:01:00,700

Even if the container is deleted the data generated or processed by it remains.



10

00:01:00,720 --> 00:01:03,720

So how does that work in the Kubernetes world.



11

00:01:03,720 --> 00:01:09,030

Just as in Docker, the PODs created in Kubernetes are transient in nature.



12

00:01:09,180 --> 00:01:16,950

When a POD is created to process data and then deleted, the data processed by it gets deleted as well.



13

00:01:16,950 --> 00: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



14

00:01:25,590 --> 00:01:33,660

even after the POD is delete, the data remains. Let’s look at a simple implementation of volumes.



15

00:01:33,690 --> 00:01:36,780

We have a single node kubernetes cluster.



16

00:01:36,780 --> 00:01:42,840

We create a simple POD that generates a random between 1 and 100 and writes that to a file



17

00:01:43,200 --> 00:01:51,650

at /opt/number.out and then gets deleted along with the random number.  To retain the



18

00:01:51,650 --> 00:01:53,730

number generated by the pod.



19

00:01:53,810 --> 00:01:58,250

We create a volume and a volume needs a storage.



20

00:01:58,310 --> 00:02:03,740

When you create a volume you can choose to configure it storage in different ways.



21

00:02:03,740 --> 00: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



22

00:02:10,160 --> 00:02:11,380

on the host.



23

00:02:11,510 --> 00:02:17,210

In this case I specify a path /data on the host.



24

00:02:17,210 --> 00:02:24,320

This way any files created in the volume would be stored in the directory data on my node. Once the volume



25

00:02:24,320 --> 00:02:30,980

is created, to access it from a container we mount the volume to a directory inside the container.



26

00:02:31,130 --> 00:02:38,390

We use the volumeMounts field in each container to mount the data-volume to the directory /opt



27

00:02:38,540 --> 00:02:40,370

within the container.



28

00:02:40,370 --> 00:02:47,750

The random number will now be written to /opt mount inside the container, which happens to be on



29

00:02:47,750 --> 00:02:52,100

the data-volume which is in fact /data directory on the host.



30

00:02:52,700 --> 00:02:58,720

When the pod gets deleted, the file with the random number still lives on the host.



31

00:02:58,730 --> 00:03:03,050

Let's take a step back and look at the volume storage options.



32

00:03:03,300 --> 00:03:10,130

We just used the host path option to configure a directory and the host has storage space for the volume.



33

00:03:10,200 --> 00:03:17,880

Now that works fine on a single node however it is not recommended for use in a multi node cluster.



34

00:03:17,880 --> 00:03:24,930

This is because the PODs would use the /data directory on all the nodes, and expect all of them



35

00:03:24,930 --> 00:03:29,620

to be the same and have the same data since they are on different servers.



36

00:03:29,800 --> 00:03:36,510

They are in fact not the same unless you configure some kind of external replicated cluster storage



37

00:03:36,510 --> 00:03:37,620

solution.



38

00:03:37,650 --> 00:03:44,400

Kubernetes supports several types of standard storage solutions such as NFS, glusterFS,



39

00:03:44,400 --> 00:03:53,110

Flocker, FibreChannel, CephFS, ScaleIO or public cloud solutions like AWS



40

00:03:53,190 --> 00:03:58,700

EBS, Azure Disk or File or Google’s Persistent Disk.



41

00:03:59,630 --> 00:04:07,550

For example, to configure an AWS Elastic Block Store volume as the storage or the volume, we replace



42

00:04:07,690 --> 00:04:14,810

hostPath field of the volume with awsElasticBlockStore field along with the volumeID



43

00:04:15,080 --> 00:04:21,790

and filesystem type. The Volume storage will now be on AWS EBS.



44

00:04:21,880 --> 00:04:27,370

Well, that’s it about Volumes in Kubernetes. We will now head over to discuss Persistent Volumes



45

00:04:27,460 --> 00:04:27,910

next.