Azure Kubernetes Service

Introduction

Applications running on Azure Kubernetes Service Cluster should be able to store and retrieve data. For example, you may plan to run a SQL Server in one of the Pods in the Cluster. The SQL Server needs to store the data files, log files, and all other necessary files somewhere in the Cluster. It cannot keep the files locally inside the Pod where it is running. If the Pod dies or gets recycled to another node, then we lose all the data stored. You may also have to store temporary files in the Cluster or confidential data like secrets in the Cluster. We need some mechanism that may help you store data in the Cluster. In this article, let's explore the following concepts that help you store data in the Azure Kubernetes Service Cluster.

Volumes
Persistent Volumes
Storage Class
Persistent Volume Claims

The following are the links to the previous articles in this series:

Volumes

You can create Azure Disks or Azure Files and attach it to the Pods as Kubernetes resources in the Azure Kubernetes Service cluster as Volumes. If the data is specific to a single Pod, you should use Azure Disks. If you are planning to share data across the Pods, then you should use Azure Files. Azure Kubernetes Service can also attach the Volumes dynamically based on your instruction.

Kubernetes intrinsically support the following types of volumes to store and retrieve data.

emptyDir
secret
configMap

The emptyDir helps in storing temporary data for the Pods, and we lose the data when the Pods get deleted. The data gets stored either in the underlying Node’s disk or in the Node’s memory.

The secret helps you store sensitive data like the Container Registry secret key or password in a secure manner. These secrets are available to the Pods that you have configured to use it. The secrets get stored in a RAM backed temporary volatile storage called as tmpfs.

The configMap helps you store data as key-value pairs. You can store application configuration data here. This storage is also temporary, and you lose the data when the Pod dies.

All the Volume types we describe here are not persistent and exist during the Pod life cycle. When the Pod dies, we lose the data stored in these volumes. However, we may have requirements to store data beyond the Pod life cycle. Persistent Volumes help you store data permanently beyond the Pod life cycle.

Persistent Volumes

The Persistent Volumes helps you store Pods data permanently. You use either Azure Disks or Azure Azure Files to make your data persistent. You can create a Persistent Volume and attach it to your Pod statically. Alternatively, the Azure Kubernetes Service can dynamically create Persistent Volumes based and attach it to the Pod. You may have a scenario where a Persistent Volume is attached to your Pod, and the Pod dies. This Volume should be available for the new Pod that spins up in the same Node or another Node. In such a case, Azure Kubernetes Service first checks if the Volume exists. If the Volume exists then, it attaches it to the Pod, or else it creates a new one and attaches it to the Pod. During dynamic provisioning of Persistent Volumes, the Azure Kubernetes Service uses the concept of the Storage Class and Persistent Volume to figure out the disk it should attach to the Cluster.

Storage Class

Storage Class specifies the type of Volume that the Azure Kubernetes Service would attach to the Pods during dynamic provisioning of the Volumes. It also specifies what to do with the Volumes after the Pod to which the Volume is attached dies. You may configure the reclaim policy of the Storage class to either retain the Volume so that other Pods can use it or delete the Volume once the Pod dies. If you do not specify the Storage Class, the Volume gets deleted by default.

The following are the Storage Classes available for Azure Kubernetes Service:

The default Storage Class uses Azure Standard SSD storage to create Managed Disks.
The managed-premium Storage Class uses Azure Premium Storage to create Managed Disks.
The azurefile Storage Class uses Standard Azure File Share.
The azurefile-premium Storage Class uses Premium Azure File Share.

If you do not specify any Storage Class, then the default Storage Class is used.

Persistent Volume Claim

You can specify the Storage Class, size, access mode for the Volume as Persistent Claim. While attaching a Volume dynamically, the Azure Kubernetes Service searches for the Volume with the Persistent Volume Claim specified and attaches it to the Cluster if it finds the Volume. If the Volume does not exist per the Persistent Volume Claim, then it creates a new Volume based on the Storage Class and other parameters specified in the Persistent Volume Claim. The Pods never loses the Volume even if the Pods get recycled in the same Node or a different Node using the Persistent Volume Claim. The following figure depicts the big picture of how Persistent Volumes work using the Persistent Volume Claim and the Storage Class.

Conclusion

By now, in this series, we have learned all the basics of Azure Kubernetes Service Cluster. In this article, we saw how the Pods in the Azure Kubernetes Service Cluster store data. In the next article, we will build an Azure Kubernetes Service Cluster.