Using Azure CSI Drivers in Minikube

If you’re running an AKS cluster, you may have the Azure CSI drivers enabled for Azure Disks, Blobs, and Files.

When testing in minikube, while Kubernetes has some built in support for Azure Storage, you may desire to be using the same tools that you are using in AKS.

The unsupported version of the Azure File CSI driver and the Azure Blob Store CSI driver are available to be installed. The Azure Disk CSI driver is available as well, however your node needs to be running on an Azure VM in order for that one to work.

Below, I will show you how to install the Azure File CSI Driver, but the same process will also work for the Azure Blob Storage CSI Driver.

Prerequisites

• Azure Service Principal
• minikube cluster
• Helm CLI

Install Azure File CSI driver

1. Set up the config for the service principal

Set up the config for the service principal The repo contains instructions for using the account key to access Azure Files. But what we’re going to do is set up the Azure Files CSI Driver to use a service principal, which isn’t as clearly documented.

a. The first thing we need to do is create the json config with the information for our service principal. That looks like this:

{
	cloud: AzurePublicCloud,
	tenantId: <Entra ID tenant ID>,
	subscriptionId: <Subscription ID for Azure Storage Resources>,
	resourceGroup: <Resource Group that dynamically provisioned resouces will be created in>,
	location: <Azure region for resources>,
	aadClientId: <Service Principal ID>,
	aadClientSecret: <Service Principal Secret>,
	useManagedIdentityExtension: false
}	

• subscriptionId: If you want to access Azure Files not in this subscription, you will have to fallback to using an account key instead.
• resourceGroup: Dynamic resources will be created here, but you can specify a different resource group in your StorageClass if you are accessing existing Azure Files. The Service Principal will need to be granted the appropriate permissions to the resource group in either case.

b. Save your config as a file called cloud-config

c. Create a secret using the cloud-config file

kubectl create secret generic azure-cloud-provider -n kube-system --from-file=path/to/your/directory/cloud-config

3. Install the chart’s helm repo

helm repo add azurefile-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/charts

5. Install

helm install azurefile-csi-driver azurefile-csi-driver/azurefile-csi-driver --namespace kube-system --set controller.replicas=1

Notes:

• This will use the azure-cloud-provider secret by default. If you want to use a different secret name and/or namespace for the secret you can add additional arguments.
• If you’re trying to install the Blob driver, you may be tempted to set enableBlobfuseProxy: true for seemless updates. But that only works for Debians based nodes, so it will not work with minikube.

6. Testing

To test, we can use some of the example storage classes and persistent volume claim to dynamically provision a storage resource for a pod.

a. Create the storage class

kubectl create -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/storageclass-azurefile-csi.yaml

Anything that uses this storage class with have the storage dynamically created and use the Premium_LRS sku.

b. Create the PVC

kubectl create -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/pvc-azurefile-csi.yaml

This will use the azurefile-csi storage class

c. Create the example pod

kubectl create -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/nginx-pod-azurefile.yaml

This will use the pvc-azurefile PVC and mount the storage at /mnt/azurefile