Background
This is the sixth part of the series on building highly scalable multi-container apps using AKS. So far in this series we have covered following topics.
- Part 1 : we provisioned a managed Kubernetes cluster using Azure Container Service (AKS).
- Part 2 : Understand basic Kubernetes objects - Kubernetes Namespace.
- Part 3 : Understand basic Kubernetes objects – Pod and Deployment
- Part 4 : Understand Kubernetes object – Service
- Part 5 : Understand Kubernetes Object – init containers
In this post we will learn about a very important concept of Persistent Volumes (PV) and Persistent Volume Claim (PVC). We will use these concepts to manage data for the SQL Server 2017 Linux container.
Why do we need volume in the first place?
Managing data in a containerized scenario is quite tricky. Containers are ephemeral by design. Which means that they can be created, deleted and rescheduled on any host in the cluster. If the container is recreated, what happens to the data stored inside the container? It is oblivious that the data stored locally inside the container will be lost.
This scenario might be ok while testing. But as we start moving to deploying the applications using containers, we would want to persist the data even if the container restarts or a newer version of the image is used to upgrade the older version of container. In such scenario it makes sense to store the data external to the container. It is in such scenario that external volumes play a very important role.
During the course of this post we will focus on following
- Provision Persistent Volume (PV) using Azure Disk
- Create Persistent Volume Claim (PVC) to the provisioned volume
Provision Persistent Volume (PV) using Azure Disk
Persistent Volume abstracts from users details of how the storage is provided and how it is consumed. It is a cluster level resource provisioned by administrator and available to the pods to use. Persistent volume supports multiple types of storage including network storage, physical disks or cloud storage like Azure Disk. The storage is provisioned using one of the supported Storage Class. Lets look at an example of creating a storage class based on Azure Disk
We will skip the initial metadata, on line 7 we specify the provisioner as azure-disk. We also specify the parameters storage account type as Standard_LRS and kind as Managed. The parameters will be different for different types of provisioner. You can refer to the storage-class provisioner link below to know more about the supported provisioners with Kubernetes.
Lets go and apply this Kubernetes manifest to our cluster. Use kubectl command line to execute the command
kubectl apply –f 01_storage-class.yml
We can browse to the Kubernetes dashboard and see that the storage class is created successfully.
The creation of Storage Class is an indication of what kind of storage we are going to provision within the Kubernetes cluster. Lets go ahead and create a Persistent Volume Claim.
Create Persistent Volume Claim to the provisioned storage
Lets look at an example of the Kubernetes manifest file to create a Persistent Volume Claim (PVC).
Above we see the definition of PVC. Line 8 links the storage class named azure-disk. Note that this is the name we gave while creating the storage class earlier. From line 9 onwards we specify the requirements for the storage claim. In our example we have specified ReadWriteOnce as the access mode. For the resource request, we specified 1Gb as the disk space. When we apply this manifest, 1Gb of disk space will be provisioned for us. Run the kubectl command
kubectl apply –f 02_PersistentVolumeClaim.ymlThe Persistent Volume has different lifecycle. It takes few minutes to provision the storage and bind it to the Kubernetes cluster. Initially the status of the persistent volume claim will be Pending.
Once the volume is successfully provisioned it is bound to the claim. We can verify this by looking at the bound state.
At this point we can go to the Persistent Volumes section on the left of the Kubernetes dashboard and find details about the underlying volume.
In this view we can find details like the name of the volume, its capacity, access modes, status, associated claim etc. Like we had done in earlier parts of this series, we can use the Kubernetes cli to query the PV object to know more details. Execute the following command
kubectl describe pv <<name of the pvc>>The output will be as shown in the screenshot below
It is same as what we see in the Kubernetes dashboard. We will see how to make use of this Persistent Volume in the next part of this series.
References
[1] Kubernetes Storage class provisioner : https://kubernetes.io/docs/concepts/storage/storage-classes/
[2] Persistent Volumes : https://kubernetes.io/docs/concepts/storage/persistent-volumes/
Conclusion
We saw how to provision a Persistent Volume backed by Azure Disk. With the help of 2 Kubernetes Manifest files we were able to get the disk and associate a claim with it.
Persistent Volumes are quite powerful concept in Kubernetes. It allows developers and cluster administrators to work on different parts of the application. Using Persistent volumes, the administrator can provision storage which can be used by developers without knowing the underlying storage mechanism. This can be used to swap the underlying storage without any need to make changes to application code. This may not be very clear right now, but I am sure it will make sense in the next part where we will see how to utilize these volumes
Until next time, Code with Passion and Strive for Excellence.
