Configure Azure file share as a volume
In this guide we would like to showcase the different ways one could mount Azure file shares as a volume into a pod.
- AzureFile
- PersistentVolumeClaim
Prerequisites
- Access to Azure Storage account with a file share
- Storage Account name and access key should be available in a key vault
Create a secret
Create a Kubernetes secret which holds both the account name (azurestorageaccountname
) and key (azurestorageaccountkey
). Secrets from Key Vault can be mounted to a pod using Secrets Store CSI Driver.
Example:
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
namespace: "<my-team-namespace>"
name: "<my-sa-spc>"
labels:
app: "<my-sa>"
spec:
provider: azure
secretObjects:
- secretName: "<my-sa-credentials>"
type: Opaque
data:
- objectName: "<my-sa-name-kv-secret>"
key: "azurestorageaccountname"
- objectName: "<my-sa-access-key-kv-secret>"
key: "azurestorageaccountkey"
parameters:
usePodIdentity: "true"
keyvaultName: "<my-team-keyvault-name>"
objects: |
array:
- |
objectName: "<my-sa-name-kv-secret>"
objectType: secret
- |
objectName: "<my-sa-access-key-kv-secret>"
objectType: secret
tenantId: "<azure-tenant-id>"
See Accessing Key Vault with Secrets Store CSI Driver for detailed instructions.
Simple mounting of Azure Files into a pod
This solution is preferred if you only want to read something off your file share.
apiVersion: apps/v1
kind: Deployment
metadata:
...
spec:
...
template:
...
spec:
containers:
...
volumeMounts:
- name: "azure-files" # [1]
mountPath: "/mnt/azurefiles" # [2]
volumes:
- name: "azure-files" # [1]
azureFile:
secretName: <my-sa-credentials> # [3]
shareName: <myazurefileshare> # [4]
- Give a name to
volumeMounts
and the same tovolumes
. Both names have to match. - Decide where in the container you want to mount your file share.
- The name of the Kubernetes secret holding the credentials for your Azure file share (see Create a secret).
- The file share name which you would like to mount. The file share has to be created beforehand in your Azure Storage account.
Advanced mounting of Azure Files into a pod
This solution is preferred if you need to do write changes. In Gjensidige we do not allow containers running as root for security reasons. Its recommended that a running container has an UID of 10001 or higher. When not running at UID 0(root), some applications may break when writing to Azure files if the directory permissions are not set correctly. With this solution we have the ability to change the directory permission to whatever we want.
Prerequisites
- ArgoCD must be allowed to create PersistentVolumes in your project. See example for details.
PersistentVolume (PV)
Define a PersistentVolume resource
apiVersion: v1
kind: PersistentVolume
metadata:
name: "team-a-app-1-azurefiles" # [1]
labels:
pv: "app-1-azurefiles" # [2]
team: "team-a" # [2]
spec:
capacity:
storage: 100Gi
accessModes:
- ReadWriteMany
azureFile:
secretName: <my-sa-credentials> # [3]
secretNamespace: <my-team-namespace> # [4]
shareName: blob # [5]
readOnly: false
mountOptions:
- dir_mode=0755 # [6]
- file_mode=0755 # [7]
- uid=10001 # [8]
- gid=10001 # [9]
- mfsymlinks
- nobrl
- Be aware that the resource
persistentVolume
(PV) is cluster wide, meaning the names have to be unique in the cluster - Labels are an important way of connecting resources in Kubernetes. Have at least 2 labels that when combined give a unique key. This key is needed for the
PersistentVolumeClaim
resource. - The name of the Kubernetes secret holding the credentials for your Azure file share (see Create a secret).
- The namespace in which your above secret mentioned secret[3] is located
- The file share name which you would like to mount. The file share has to be created beforehand in your Azure Storage account.
- The default directory permissions to be set
- The default file permissions to be set
- The default UID to set on directories and files. Use your application UID
- The default GID to set on directories and files. Use your application GID
PersistentVolumeClaim (PVC)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
namespace: "<my-team-namespace>" # [1]
name: "team-a-app-1-azurefiles" # [2]
labels:
app: "your-app-name"
spec:
accessModes:
- ReadWriteMany
storageClassName: ""
selector:
matchLabels:
pv: "app-1-azurefiles" # [3]
team: "team-a" # [3]
resources:
requests:
storage: 100Gi
- The namespace where you will be running your pod.
PersistentVolumeClaim
(PVC) are namespaced resources, as such PVC names have to be unique in a namespace- These labels have to match the labels defined in your
PersistentVolume
resource.
Tying it all together
Now that you have defined a PersistentVolumeClaim
that hooks onto a PersistentVolume
, one can then reference the PVC in a deployment.
apiVersion: apps/v1
kind: Deployment
metadata:
...
spec:
...
template:
...
spec:
containers:
...
volumeMounts:
- name: "azure-files" # [1]
mountPath: "/mnt/azurefiles" # [2]
volumes:
- name: "azure-files" # [1]
persistentVolumeClaim:
claimName: team-a-app-1-azurefiles # [3]
- Give a name to
volumeMounts
and the same tovolumes
. Both names have to match. - Decide where in the container you want to mount your file share.
- The name of the
persistentVolumeClaim
you created earlier.
Deleting a deployment does not delete the PVC or the PV. These are separate resources and has to be handled accordingly.