Hello and welcome to this lecture on Persistent Volumes in Kubernetes.
My name is Mumshad Mannambeth. Before we head into persistent volumes
let us start with Volumes in Kubernetes. Let us look at volumes in Docker first. Docker containers are
meant to be transient in nature which means they are meant to last only for a short period of time.
They are called upon when required to process data and destroyed once finished.
The same is true for the data within the container the data is destroyed along with the container to
persist data processed by the containers we attach a volume to the containers when they are created.
The data are processed by the container is now placed in this volume thereby retaining it permanently.
Even if the container is deleted the data generated or processed by it remains.
So how does that work in the Kubernetes world.
Just as in Docker, the PODs created in Kubernetes are transient in nature.
When a POD is created to process data and then deleted, the data processed by it gets deleted as well.
For this we attach a volume to the POD. The data generated by the POD is now stored in the volume, and
even after the POD is delete, the data remains. Let’s look at a simple implementation of volumes.
We have a single node kubernetes cluster.
We create a simple POD that generates a random between 1 and 100 and writes that to a file
at /opt/number.out and then gets deleted along with the random number. To retain the
number generated by the pod.
We create a volume and a volume needs a storage.
When you create a volume you can choose to configure it storage in different ways.
We will look at the various options in a bit but for now we will simply configure it to use a directory
on the host.
In this case I specify a path /data on the host.
This way any files created in the volume would be stored in the directory data on my node. Once the volume
is created, to access it from a container we mount the volume to a directory inside the container.
We use the volumeMounts field in each container to mount the data-volume to the directory /opt
within the container.
The random number will now be written to /opt mount inside the container, which happens to be on
the data-volume which is in fact /data directory on the host.
When the pod gets deleted, the file with the random number still lives on the host.
Let's take a step back and look at the volume storage options.
We just used the host path option to configure a directory and the host has storage space for the volume.
Now that works fine on a single node however it is not recommended for use in a multi node cluster.
This is because the PODs would use the /data directory on all the nodes, and expect all of them
to be the same and have the same data since they are on different servers.
They are in fact not the same unless you configure some kind of external replicated cluster storage
solution.
Kubernetes supports several types of standard storage solutions such as NFS, glusterFS,
Flocker, FibreChannel, CephFS, ScaleIO or public cloud solutions like AWS
EBS, Azure Disk or File or Google’s Persistent Disk.
For example, to configure an AWS Elastic Block Store volume as the storage or the volume, we replace
hostPath field of the volume with awsElasticBlockStore field along with the volumeID
and filesystem type. The Volume storage will now be on AWS EBS.
Well, that’s it about Volumes in Kubernetes. We will now head over to discuss Persistent Volumes
next.