Stateless is the Kubernetes happy path, but real platforms carry state: the message broker someone insists on self hosting, the ML training scratch space, the legacy app that writes files. AKS exposes Azure storage through CSI drivers, and choosing among them is an access pattern decision that teams keep making by default instead of design.

The Decision by Access Pattern

Azure Disk CSI is block storage, one pod at a time (ReadWriteOnce): the highest IOPS and lowest latency, the right answer for databases and anything resembling one, with Premium SSD v2 as the default choice for serious workloads because it decouples size from IOPS and throughput, you provision performance and capacity independently instead of buying size to get speed. Azure Files CSI is SMB or NFS shares, many pods concurrently (ReadWriteMany): the right answer for shared content, lift and shift apps expecting a filesystem, and cross pod scratch, with the premium NFS flavor being the performance floor worth accepting for anything hot. Blob CSI mounts object storage via blobfuse or NFS: right for large read mostly datasets, ML training data, media, where object economics matter and POSIX fidelity does not, and wrong for anything doing small random writes through a fuse layer. The anti pattern each driver punishes: databases on Azure Files (latency), shared state on Disk via hostPath contortions (correctness), and write heavy workloads on blobfuse (both).

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: premiumv2-zrs
provisioner: disk.csi.azure.com
parameters:
  skuName: PremiumV2_LRS
  DiskIOPSReadWrite: "4000"
  DiskMBpsReadWrite: "200"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Two parameters there carry the operational lessons. WaitForFirstConsumer defers provisioning until the pod schedules, so the disk lands in the pod’s zone, without it, zonal mismatch strands pods pending forever, the classic multi zone storage incident. And allowVolumeExpansion true makes resize a PVC edit; online expansion works, and it beats the alternative migration ceremony by weeks.

Day Two: Snapshots, Backup, and Zones

Volume snapshots through the CSI snapshot controller give crash consistent point in time copies, useful for pre upgrade safety and clone based test data, but they are not a backup strategy alone: AKS backup (from the vault machinery in the backup post) covers cluster state plus disk volumes with the same policy, immutability, and restore drill discipline as everything else, and application consistent protection for databases still belongs to the database’s own tooling. Zone resilience for state is sharper than for compute: an LRS disk lives in one zone, so a zone loss strands it, and the choices are ZRS disks (synchronous cross zone replication, modest latency cost, the sane default for critical PVs), application level replication across zonal instances (what the brokers and databases you would self host do natively), or accepting the zonal risk in writing via the WAF review from last week.

The Honesty Check

For workloads needing serious local performance or storage pooling across nodes, Azure Container Storage manages ephemeral NVMe and disk pools with replication, worth evaluating before hand rolling anything. But the recurring conclusion of this series applies hardest here: every stateful thing you run in cluster carries the operational bill the managed posts, PostgreSQL, Redis, Service Bus, Event Hubs, exist to avoid. The checklist before self hosting state on AKS: is there a managed equivalent, does the team own the backup restore drill, is zone loss survivable, and who wakes up for it. When those answers are good, the CSI machinery above makes it work well; when they are not, the answer was a connection string all along.

Cheers
Osama