Azure Blob Storage can be mounted into Azure Kubernetes Service (AKS) clusters using the Azure Blob CSI driver, treating cloud object storage like a traditional file system.
Let’s see this in action. We’ll mount a blob container to a pod.
First, ensure you have the Azure Blob CSI driver installed on your AKS cluster. If not, you can install it via the AKS add-on:
az aks addons enable azure-csi-blob --name <your-aks-cluster-name> --resource-group <your-aks-resource-group>
Next, create a Kubernetes Secret to hold your Azure Storage Account credentials. This secret will contain your storage account name and the access key.
apiVersion: v1
kind: Secret
metadata:
name: azure-storage-account-secret
type: Opaque
data:
azurestorageaccountname: <your-storage-account-name-base64-encoded>
azurestorageaccountkey: <your-storage-account-key-base64-encoded>
To get the base64 encoded values, you can use:
echo -n '<your-storage-account-name>' | base64
echo -n '<your-storage-account-key>' | base64
Now, define a PersistentVolumeClaim (PVC) that requests a PersistentVolume (PV) using the Azure Blob CSI driver. This PVC will specify the blob container to mount and the secret containing credentials.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: blob-pvc
spec:
accessModes:
- ReadWriteOnce # Or ReadOnlyMany, ReadWriteMany depending on your needs
storageClassName: azureblob-csi
resources:
requests:
storage: 10Gi # This is a nominal value, actual storage is in blob
selector:
matchLabels:
storageaccount: <your-storage-account-name> # Matches the label on the PV
The storageClassName: azureblob-csi is crucial; it tells Kubernetes to use the Azure Blob CSI driver for provisioning. The selector helps link the PVC to a specific PV if you were to define it manually, but with dynamic provisioning, the driver often handles this implicitly.
Finally, create a Pod that uses this PVC.
apiVersion: v1
kind: Pod
metadata:
name: blob-pod
spec:
containers:
- name: my-container
image: mcr.microsoft.com/oss/nginx/nginx:1.19.10
ports:
- containerPort: 80
volumeMounts:
- mountPath: "/mnt/blob"
name: blob-storage
volumes:
- name: blob-storage
persistentVolumeClaim:
claimName: blob-pvc
When this pod starts, the Azure Blob CSI driver will provision a PersistentVolume (if one doesn’t exist and dynamic provisioning is enabled) and mount the specified blob container (e.g., mycontainer from your storage account) to /mnt/blob inside the my-container.
The problem this solves is enabling stateful applications in AKS to leverage the cost-effectiveness and scalability of Azure Blob Storage as persistent storage, without requiring complex manual setup or dedicated managed disks for every workload. It abstracts away the underlying object storage, presenting it as a POSIX-like file system to the applications running in containers.
Internally, the CSI driver acts as a bridge. When a pod requests a volume using storageClassName: azureblob-csi, the driver’s controller component creates a corresponding PersistentVolume object. The driver’s node component, running on each AKS node, then handles the actual mounting of the blob container to the specified path in the pod’s filesystem. This involves interacting with the Azure Blob Storage API using the provided credentials.
The accessModes in the PVC are critical. ReadWriteOnce means the volume can be mounted as read-write by a single node. If your application needs to be accessed by multiple pods on different nodes simultaneously and requires write access, you’d typically use ReadWriteMany which is supported by Azure Blob CSI for NFS 3.0 or Blobfuse 2.0. ReadOnlyMany allows multiple nodes to mount the volume in read-only mode.
One subtle but powerful aspect is how the driver handles different blob types and protocols. By default, it often uses Blobfuse2, which translates filesystem operations into blob API calls. However, for certain scenarios, especially with NFS mounts, it can leverage NFS 3.0 protocol support in Azure Blob Storage, offering potentially better performance for specific workloads. The choice between these underlying mechanisms can be influenced by how the storage account is configured and the specific CSI driver version and its configuration.
The next concept to explore is managing the lifecycle of these blob volumes, particularly when pods are deleted or when you need to resize the perceived storage capacity.