Azure Files, when mounted into AKS, can actually be slower than local disk for certain workloads, despite being a networked file share.
Here’s a quick demo of mounting an Azure File Share using the CSI driver in an AKS cluster.
First, ensure you have the Azure Files CSI driver installed on your AKS cluster. You can install it using Helm:
helm upgrade --install azure-files-csi-driver azure/azure-files-csi-driver \
--namespace kube-system \
--set controller.replicaCount=2 \
--set node.enable-volume-driver-nodes=true
Next, create a StorageClass that references the Azure Files CSI driver. This StorageClass will define how your file shares are provisioned.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: azurefile-csi-premium
provisioner: file.csi.azure.com
parameters:
skuName: Premium_LRS # Use Premium_LRS for better performance
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
Now, let’s create a PersistentVolumeClaim (PVC) that uses this StorageClass. This PVC will request a specific amount of storage from an Azure File Share.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-azurefile-csi
spec:
accessModes:
- ReadWriteMany # Azure Files supports ReadWriteMany
storageClassName: azurefile-csi-premium
resources:
requests:
storage: 10Gi
With the PVC created, you can now define a Pod that uses this PVC. The volumeMounts section tells Kubernetes where to mount the file share inside the Pod’s container.
apiVersion: v1
kind: Pod
metadata:
name: pod-with-azurefile-csi
spec:
containers:
- name: mycontainer
image: nginx
ports:
- containerPort: 80
volumeMounts:
- mountPath: "/mnt/azurefile"
name: azurefile-volume
volumes:
- name: azurefile-volume
persistentVolumeClaim:
claimName: pvc-azurefile-csi
Once the Pod is running, you can exec into it and verify the mount:
kubectl exec -it pod-with-azurefile-csi -- bash
mount | grep azurefile
You should see an output similar to:
//mystorageaccount.file.core.windows.net/pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx on /mnt/azurefile type cifs (rw,relatime,vers=3.02,cache=strict,username=mystorageaccount,uid=0,noforceuid,gid=0,noforcegid,addr=...,file_mode=0777,dir_mode=0777,serverino,mapprincipal,hard,intr,setuids,splice_read,mapchars,acl,sparsefile,nounix,serverate,nobrl,rsi,rsize=1048576,wsize=1048576,echo_super_cache,use_ino,posixpaths,
This shows the Azure File Share mounted via the CIFS protocol.
The mental model here is that Kubernetes, through the CSI driver, is orchestrating the mounting of a remote network file system (Azure Files) onto your Pods. The StorageClass acts as a blueprint, defining the characteristics of the storage (like performance tier and replication), and the PersistentVolumeClaim is the specific request for that storage. The Pod then consumes this provisioned storage by referencing the PVC in its volumes definition and specifying where it should be accessible within the container’s filesystem.
The skuName parameter in the StorageClass is a critical lever for performance. Premium_LRS provides significantly higher IOPS and throughput compared to Standard_LRS or Standard_ZRS because it uses SSDs. However, even with premium tiers, the inherent latency of a network file share means that workloads with very high IOPS requirements or small, frequent writes might find themselves bottlenecked by the network or the storage protocol overhead, rather than the underlying SSDs. The ReadWriteMany access mode is enabled by default and is a key feature, allowing multiple Pods across different nodes to simultaneously access the same file share.
When you see vers=3.02 in the mount options, it’s indicative of the SMB protocol version used for the connection. Newer versions of SMB (like 3.1.1) can offer better performance and security features, and the CSI driver will negotiate the highest common version supported by both the client (AKS node) and the server (Azure Files). The cache=strict option is also important for performance, dictating how data is cached on the client side; strict aims for consistency but can introduce overhead.
The most surprising thing about Azure Files performance in AKS is how much the choice of SKU and the workload’s I/O patterns dictate the actual throughput and latency. People often assume "cloud storage" means "fast," but for I/O-intensive applications, the network hop and the file protocol overhead can become the dominant factor, making solutions like Azure Disk or even distributed local storage more performant for certain use cases.
The next step in managing Azure Files in AKS is often exploring performance tuning options for the CSI driver itself, or considering alternative storage solutions for high-performance needs.