Azure Container Storage

Azure Container Storage refers to the suite of storage options available for containerized applications running on Azure, primarily within Azure Kubernetes Service (AKS). Containers are ephemeral by design—they can be created, destroyed, and rescheduled across nodes at any time. This poses a challenge for stateful applications that need to persist data beyond the lifecycle of a single container. Container storage solutions provide persistent volumes that survive container restarts and rescheduling, enabling stateful workloads like databases, message queues, and file servers to run in containers.

The AZ-305 exam expects you to understand three main types of storage for containers: block storage (Azure Disk), file storage (Azure Files), and object storage (Azure Blob). Each has distinct characteristics in terms of performance, access modes, and use cases. Additionally, you must understand Kubernetes volume abstractions like PersistentVolume (PV), PersistentVolumeClaim (PVC), and StorageClass, as well as the concept of CSI (Container Storage Interface) drivers that enable integration with Azure storage services.

In Kubernetes, storage is abstracted through a series of layers. A developer creates a PersistentVolumeClaim (PVC) that specifies storage requirements (size, access mode, performance tier). The Kubernetes control plane then binds this PVC to a PersistentVolume (PV), which is a storage resource provisioned by an administrator or dynamically provisioned by a StorageClass. The StorageClass defines the type of storage (e.g., Azure Disk with Premium SSD), the provisioner (e.g., disk.csi.azure.com), and any parameters like caching or mount options.

When a pod is scheduled on a node, the kubelet on that node uses the CSI driver to attach the storage device. For Azure Disk, this involves calling the Azure API to attach a managed disk as a block device to the node's VM. The CSI driver then formats and mounts the filesystem inside the pod's container. For Azure Files, the CSI driver mounts an SMB or NFS share over the network. For Azure Blob, the CSI driver mounts a blob container using BlobFuse or NFS 3.0.

The key internal detail is the access mode: - ReadWriteOnce (RWO): The volume can be mounted as read-write by a single node. Used for Azure Disk, which is a block device that can only be attached to one VM at a time. - ReadWriteMany (RWX): The volume can be mounted as read-write by many nodes simultaneously. Used for Azure Files (SMB/NFS) and Azure Blob (NFS). - ReadOnlyMany (ROX): The volume can be mounted as read-only by many nodes.

When a pod is rescheduled to a different node, a PVC with RWO requires the disk to be detached from the old node and attached to the new node. This process is handled automatically by the CSI driver but introduces a latency of several seconds to minutes depending on disk size and region. For RWX volumes, the share remains available and the new node simply mounts it.

Azure Disk: - Performance tiers: Standard HDD, Standard SSD, Premium SSD, Ultra Disk. Default for AKS is Premium SSD with a size-dependent IOPS/throughput. - Max size: 32,767 GiB for managed disks. - Max IOPS: Up to 160,000 for Ultra Disk. - Access mode: Only RWO (single node). - PersistentVolumeReclaimPolicy: Default is Delete for dynamic provisioning; can be Retain. - StorageClass parameters: cachingmode (None, ReadOnly, ReadWrite), maxShares (for shared disk, but not commonly used).

Azure Files: - Performance tiers: Standard (transaction optimized, hot, cool) and Premium (based on provisioned size). - Max share size: 100 TiB for standard, 100 TiB for premium. - Protocols: SMB 3.0 (with encryption) and NFS 4.1 (premium only). - Access mode: RWX (multiple nodes). - Default StorageClass: azurefile-csi with protocol: smb. - Limitations: NFS support is only available on premium file shares; SMB requires port 445 to be open.

Azure Blob: - Performance tiers: Hot, Cool, Archive. - Access modes: RWX via NFS 3.0 (premium block blobs only) or via BlobFuse (virtual filesystem). - Default StorageClass: azureblob-nfs-premium for NFS. - Limitations: NFS access requires a premium block blob storage account with hierarchical namespace enabled.

Kubernetes Defaults: - Default StorageClass in AKS: managed-csi (Azure Disk Premium SSD) for Windows and Linux. - Volume expansion: Supported for Azure Disk and Azure Files (increase size only). - Snapshot and restore: Supported via VolumeSnapshot CRDs for Azure Disk and Azure Files.

To create a StorageClass for Azure Disk with Ultra Disk:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ultra-disk
provisioner: disk.csi.azure.com
parameters:
  skuname: UltraSSD_LRS
  cachingmode: None
  diskIOPSReadWrite: "2000"
  diskMBpsReadWrite: "100"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

To create a PVC using this StorageClass:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ultra-pvc
spec:
  accessModes:

- ReadWriteOnce
  storageClassName: ultra-disk
  resources:
    requests:
      storage: 100Gi

To verify the binding:

kubectl get pvc
kubectl get pv
kubectl describe pvc ultra-pvc

To check the mounted volume inside a pod:

kubectl exec <pod-name> -- df -h
kubectl exec <pod-name> -- mount | grep /mnt

Container storage interacts with: - Azure NetApp Files: Provides high-performance NFS volumes with RWX access, suitable for HPC and enterprise workloads. It uses its own CSI driver netapp.csi.azure.com. - Azure Container Instances (ACI): Supports Azure Files mounts via volume mounts, but not Azure Disk. - Azure Red Hat OpenShift: Similar storage options via CSI. - Azure Policy: Can enforce allowed StorageClasses or storage configurations via Azure Policy for AKS. - Azure Backup: Supports backup of AKS workloads with persistent volumes using Azure Backup for AKS.

The exam often tests the trade-offs between these options. For example, Azure Disk offers the lowest latency for a single pod, but cannot be shared. Azure Files can be shared but has higher latency. Azure Blob is best for large-scale read-heavy workloads like data lakes.

For stateful sets (e.g., Cassandra, Kafka), use Azure Disk with RWO and multiple replicas, each with its own PVC. For shared configuration, use Azure Files or Azure Blob with RWX.

For cross-region failover, Azure Files with GRS is a common choice, but note that failover is manual and may take hours.

A large e-commerce company runs its product catalog, shopping cart, and order processing on AKS. The product catalog is read-heavy and uses a shared Azure Files share (Premium SSD) mounted as RWX for product images and descriptions, allowing multiple front-end pods to serve the same content. The shopping cart service uses Azure Disk (Premium SSD) with RWO for each user session, ensuring low-latency writes. The order processing service uses Azure Blob (NFS) for storing large order logs. The challenge is managing IOPS at peak traffic (Black Friday). They over-provision Premium Disk size to meet IOPS requirements and use Azure Files with provisioned IOPS. Misconfiguration occurred when they initially used Standard HDD for the catalog, causing timeouts under load. They also learned that Azure Disk's RWO prevents multiple replicas from writing simultaneously, so they had to implement a leader-election pattern for the cart service.

A bank runs its transaction processing on AKS, requiring high durability and cross-region DR. They use Azure Disk with ZRS for RWO volumes for each transaction pod. For shared configuration files that need to be accessed by all pods, they use Azure Files with GRS (geo-redundant storage) to ensure data survives a regional outage. However, they discovered that Azure Files GRS failover is manual and can take up to 24 hours, which is unacceptable. They implemented a DR strategy using Azure Backup for AKS to take snapshots of persistent volumes and replicate them to a secondary region. They also use Azure Policy to enforce that only Premium SSD and Premium Files are used, and that encryption at rest is enabled. A common mistake was assuming that Azure Disk ZRS provides automatic failover; it does not—it only protects against zonal failures within a region.

A media company stores video files on Azure Blob (hot tier) and uses AKS to transcode them. They mount Blob containers via NFS 3.0 (premium block blobs) to allow multiple transcoding pods to read the same file simultaneously. They chose NFS over BlobFuse because of better performance for large sequential reads. However, they hit the limit of 100 MB/s per blob for NFS, so they had to stripe files across multiple blobs. They also use Azure Disk for temporary scratch space during transcoding (emptyDir with medium=Memory for speed). A misconfiguration occurred when they used standard Blob storage (not premium block blobs) for NFS, which is not supported. They also learned that NFS access requires the storage account to have hierarchical namespace enabled, which cannot be changed after creation.