Use Azure Disk as a Persistent Volume in Kubernetes: Step-by-Step Guide

Kubernetes has emerged as the most popular containerized application management platform, especially for microservice-based architectures. With Azure Kubernetes Service, the operational complexities of Kubernetes are taken care of by Azure, so you can focus on what's important: your application workload.

That aside, when managing any stateful applications, the concept of persistent storage cannot be ignored. By default, the data inside a pod’s storage is temporary and disappears when the pod is terminated or recreated. For applications like databases or systems needing permanent data storage to maintain the state of an application, we need Persistent Volumes (PV). Azure provides an easy way to do this using Azure Disks.

In this blog, we’ll walk through how to use Azure Disks as a Persistent Volume in Kubernetes, explore the differences between static and dynamic provisioning, and highlight common issues and or scenarios you might face.

Why do pods need persistent storage?

Normally, within a pod, once a pod stops, the data within it vanishes. However, in a stateful application, for example, a database, you would wish for the data to persist even if the pod is stopped or restarted. Persistent storage is what ensures that regardless of what may happen to the pod, information is persisted.

What Is Azure Disk?

Azure Disk is a block storage type that is attached to your Azure VM or pod in your AKS cluster. It is fast, reliable, and available in different flavours as Standard HDD, Standard SSD, and Premium SSD - depending on performance needs. However, it is an ideal solution when you need high-performance storage accessible by a single pod.

Should I Use Azure Disk or Azure File Share?

It depends on your use case! Here’s a simple way to decide:

When to Use Azure Disk:

• Single-node applications: If your app only needs to run on one pod (or one node), and you want low-latency, high-performance storage, go with Azure Disk. Think of databases like SQL Server, MySQL, or MongoDB running as single instances.
• High performance: If you need fast read/write speeds or high IOPS, Azure Disk is ideal.

Limitations: Azure Disk can only be attached to one pod at a time. It doesn’t support shared access across multiple nodes.

When to Use Azure File Share:

• Multiple-node access: If your app needs to share storage across multiple pods, like a web server cluster or content management system, Azure File Share is perfect. It lets several nodes read and write the same files simultaneously.

Limitations: Azure File Share is slower than Azure Disk. It’s not great for workloads needing high IOPS or low latency.

Dynamic vs. Static Provisioning with Azure Disk

The Persistent Volumes in Kubernetes can be used in two ways, i.e. Static Provisioning and Dynamic Provisioning. The key difference when the two strategies lies in how the storage resources are provisioned, allocated, and managed.

Static Provisioning:

With static provisioning, the first step is to create an Azure Disk and then to make it a Persistent Volume (PV) in Kubernetes. Of course, that gives the maximum control over the disk - size, location, type - but at the price of doing a little bit more work, managing everything by yourself.

Use static provisioning when you want to have fine control over the properties of the disks or have very strict compliance requirements whereby you cannot allow the disks to get created automatically.

Dynamic Provisioning:

In dynamic provisioning, Kubernetes will automatically create and manage the Azure Disk on your behalf if you create a Persistent Volume Claim. That saves you the hassle of provisioning disks. This is a default choice for cloud-native applications.

Use dynamic provisioning whenever you want automation or flexibility. It comes in handy when you are dealing with scalable environments where storage requests are persistent.

In this blog, we will limit ourselves to dynamic provisioning only.

Some of the core characteristics of dynamic provisioning are as follows:

• Automatic: Azure Disk or PV can be created without human intervention.
• Efficient: It reduces the complexity of managing storage as the provisioning of storage is automated.
• Flexible: This will allow creating storage volumes on the fly as needed by applications without requiring the manual creation of disks.

StorageClass, PVC, and PV: Vocabulary Check

What's more, before beginning with the creation of persistent volumes using Azure Disk,

Let's get familiar with the vocabulary:

• Storage Class: In Kubernetes, a storage class is said to be an abstraction that defines the types of storage a cluster offers along with their properties. It is one of the Kubernetes resources that enable the administrator to create classes of storage and define their properties, whether availability or performance.
• Persistent Volume: It is a storage piece in the cluster that has either been provisioned by an administrator or dynamically provisioned by using Storage Classes.
• Persistent Volume Claims: With Persistent Volume being in place, a user can request the required amount of storage using a PersistentVolumeClaim(PVC) in Kubernetes. Through these claims, users can request specific sizes and access modes as per their needs.
• Reclaiming: When a user is done using a volume, they can delete the PVC objects from the API. The reclaim policy for a PersistentVolume is a rule that determines what the cluster will do with the volume once its claim has been released. To date, volumes are either Retained, Recycled, or Deleted.

Set Up Persistent Volumes with Dynamic Provisioning: Step by Step Guide

1. Create a StorageClass

A StorageClass defines the kind of Azure Disk you want Kubernetes to provision dynamically. It lets Kubernetes know how to provision an Azure Disk whenever a PVC requests it automatically.

To create a storage class, one needs to provide the following fields:

• Provisioner: It assigns various volume plugins
• Parameters: Specifies the type of storage
• ReclaimPolicy: indicates the reclaim policy

Following is an example of a StorageClass Yaml manifest file:

This manifest will create a storage class in Kubernetes informing it to provision managed Premium_LRS disks in Azure. With reclaimPolicy set to Retain, the persistent volume will not get deleted even if the pod to which it is attached gets deleted. Using the allowVolumeExpansion parameter set to true, the volume could now expand even after provisioning.

2. Persistent Volume Claim End

First, create a PVC to demand some storage. Kubernetes will then dynamically provision an Azure Disk for you through StorageClass and then create a matching PV for it.

Here is an example of a PVC:

This PVC is configured such that it will request 2 GB storage space which can be read or written by a single node only as specified in the AccessMode attribute.

When creating a PVC, Kubernetes dynamically provisions an Azure Disk and creates an associated PV, which automatically gets bound to the PVC.

That's it. You have now completed the configuration for the persistent volume utilizing dynamic provisioning in Kubernetes.

Common Issues

Now, while we are setting up, we may fall into a few pits; let's discuss those and see how we can fix them.

1. PVC Binding Failure

This most probably occurs since your PVC doesn't align with any available PV, or there's an issue with the configuration in StorageClass. Check for the correct access mode, size, and definitions used in the storage class.

2. Disk Performance Bottlenecks

For example, your workloads are the kind that requires the utmost high performance. You can see yourself using a lower-tier Azure Disk (example: Standard HDD). This is likely going to cause you to have latency issues. Use Premium SSD for better performance.

3. Disk Attachment Issue after Pod Recreation

A common issue in AKS is that it can't attach a disk to your pod-hosting VM because the disk and node are in different availability zones. Here's why you might encounter this and how to resolve it.

Azure Disks, by default, are locally redundant implying it can be attached only within a single availability zone. As soon as you have an AKS node pool spread across multiple zones and a pod is scheduled to a node other than the zone for the disk, you will get an error when the disk is attached.

The above problem can be solved by either of the following procedures,

• Ensure Disk and Node in Availability Zone: Using node affinity, ensure that the disk and nodes running the pod are in the same availability zone. So, there must not be a schedule on any other node than in the same disk zone.
• Use Zone-Redundant Storage (ZRS) Disks: Another option would be to use zone-redundant storage (ZRS) disks, which can then be attached to pods running on nodes in any zone or even on non-zonal nodes.

Conclusion

By using Azure Disks as Persistent Volumes in AKS you can manage your storage for stateful applications with ease. Whether you opt for static or dynamic provisioning, Kubernetes makes sure your storage is available and connected to your pods. By following the steps in this guide and keeping an eye out for potential issues, you’ll be well-equipped to manage persistent storage in AKS efficiently.