Storage Classes – PaaS Compute Options

Storage Classes – PaaS Compute Options

As mentioned earlier, you can use Standard or Premium tiers of both Azure Files and Azure Storage while creating persistent volumes in Azure. The type of storage is determined using StorageClasses. Inside StorageClasses, you can also define reclaimPolicy. Using reclaimPolicy, you can control whether the underlying storage resources should be deleted or persisted when the pod is deleted.

The following are the different types of storage classes supported by AKS:

• default: This is the default StorageClass when no StorageClass is specified for a PV. Here, the default is to use Azure Standard SSD to create managed disks.
• managed-premium: Azure Premium storage is used to create a managed disk.
• azurefile: Standard storage is used to create an Azure File Share instance.
• azurefile-premium: Azure File Share is created using Azure Premium storage.

In all the scenarios, reclaimPolicy is used to determine whether you want to retain or delete the volume when you delete the pod.

Persistent Volume Claims

A persistent volume claim (PVC) requests storage by specifying the access mode and size. In AKS, PVC requests disk or file storage of a StorageClass. If there are no existing resources to fulfil the claim, the Kubernetes API will dynamically provision storage in Azure based on the StorageClass. Persistent volumes are mapped to claims one to one. You can specify the claims in your pod definition while creating the pod.

If you are interested to see how a PVC is created and is attached to a pod in a YAML manifest, refer to the following:

https://github.com/rithinskaria/azure-infra/blob/main/azure-pv-pvc-sample.yaml

Also, you can always refer to the official Kubernetes documentation to gain more insights.

Cluster Upgrade

You need to upgrade your Kubernetes version to address the security vulnerabilities and to use the latest features. When you create a cluster in Azure, you can select the Kubernetes version. In Figure 9.21, you can see the version available in Azure at the time of writing this book.

FIGURE 9.21 Kubernetes versions in AKS

However, you have the option to choose from multiple versions; you also need to upgrade these clusters at some point. The good thing is, Azure provides tools to orchestrate the upgrade of the AKS cluster. The orchestration includes an upgrade of both Azure-provided nodes and customer-managed nodes. As you saw in Figure 9.21, for upgrades also, you will see the list of available versions. Once you select the version, Azure will orchestrate the process of cordoning and draining on each AKS node. During the draining process, all the pods will be evicted from the node and moved to another node. To eliminate the downtime, the upgrade will be performed as a rolling upgrade. In other words, only one node gets upgraded at a time so that other nodes can run the application.

During the upgrade process, AKS nodes are cordoned individually from the cluster. Cordoning ensures that no new pods are scheduled on the node. Once cordoned, the draining process will start. In draining, Kubernetes will drain all the pods in the current node to a different node. The following steps happen during a cluster upgrade:

1. Pods are terminated and scheduled on the remaining nodes.
2. The node undergoes the upgrade and reboot. Once the upgrade is completed, the node joins back to the AKS cluster.
3. The node is uncordoned, which means pods can be scheduled on the node again. However, the drained nodes are not rescheduled back to this node.
4. The next node gets cordoned and drained. The process continues until all the nodes are upgraded.