Mount volumes
Configuring mount volumes
The supported volume mount type is to mount CSI Azure Blob Container, using CSI Azure blob driver for Kubernetes. See this for more information.
- BlobFuse FlexVolume is considered obsolete and recommended being replaced with CSI Azure blob driver.
- BlobFuse v1 CSI Azure blob driver is considered obsolete and recommended being replaced with BlobFuse2.
In order to make use of this functionality you have to:
- Retrieve necessary values from Azure Storage Account with BlobFuse2 - a Microsoft supported Azure Storage FUSE driver.
Supported features
- Hierarchical file system in the Storage Account, particularly Azure Data Lake Storage Gen2. In this case an option
useAdls
should be set totrue
in the radixconfig. - File streaming, when there is no file caching on nodes. In this case an option
streaming.enabled
should be set totrue
in the radixconfig (it istrue
by default). Streaming file operations are slower than with use of cache, but it is more reliable, and it is recommended to use it, particularly for large files. More details about streaming can be found here
Optional settings
There are optional settings to fine tune volumes.
Account name and key
Name of container
- Define the volume mounts for the environment in the radixconfig.yaml. The container should match the one found in step 1
environmentConfig:
- environment: dev
volumeMounts:
- name: storage
path: /app/image-storage
blobfuse2:
container: blobfusevolumetestdata
- After environment has been built, set the generated secret to key found in step 1. This should ensure that key value is Consistent status. It is recommended to restart a component after a key has been set in the console
This results in the Kubernetes deployment holding the volume mount in PersistentVolumeClaim and its StorageClass:
spec:
containers:
- env:
...
volumeMounts:
- mountPath: /app/image-storage
name: csi-az-blob-frontend-storage1-blobfusevolumetestdata
...
volumes:
- name: csi-az-blob-frontend-storage-blobfusevolumetestdata
persistentVolumeClaim:
claimName: pvc-csi-az-blob-frontend-storage-blobfusevolumetestdata
and files appear inside the container. If there are folders within blob container - it will exist in the pod's container as well
kubectl exec -it -n radix-example-dev deploy/frontend -- ls -l /app/image-storage
total 0
-rwxrwxrwx 1 root root 21133 Nov 13 13:56 image-01.png
-rwxrwxrwx 1 root root 21989 Nov 13 13:56 image-02.png
-rwxrwxrwx 1 root root 47540 Nov 26 14:51 image-04.png
-rwxrwxrwx 1 root root 48391 Nov 26 14:50 image-06.png
-rwxrwxrwx 1 root root 47732 Nov 26 14:50 image-07.png
Multiple volume mounts are also supported
- for multiple blob-containers within one storage account
- for containers within multiple storage accounts
- for containers within storage accounts within multiple subscriptions and tenants
Not supported mount from same blob container to different folders within one component.
Multiple containers within one storage account
To add multiple volumes
-
Define the volume mounts for the environment in the radixconfig.yaml.
- add more
volumeMounts
, withname
-s, unique withinvolumeMounts
of an environment (do not use storage account name as thisname
as it is not secure and can be not unique) - specify
container
names for eachvolumeMount
. Thecontainer
should match the one found in step 1 - specify
path
for eachvolumeMount
, unique withinvolumeMounts
of an environment
environmentConfig:
- environment: dev
volumeMounts:
- name: storage1
path: /app/image-storage
blobfuse2:
container: blobfusevolumetestdata
uid: 1000
- name: storage3
path: /app/image-storage3
blobfuse2:
container: blobfusevolumetestdata3
uid: 1000 - add more
-
After environment has been built, set the generated secret to account name and key, found in step 1 - for each volume. This should ensure that key value is Consistent status. It is recommended to restart a component after a all secrets have been set in the console
This results in the Kubernetes deployment holding the volume mounts in its spec:
spec:
containers:
- env:
...
volumeMounts:
- mountPath: /app/image-storage
name: csi-az-blob-frontend-storage1-blobfusevolumetestdata
- mountPath: /app/image-storage3
name: csi-az-blob-frontend-storage3-blobfusevolumetestdata3
...
volumes:
- name: csi-az-blob-frontend-storage1-blobfusevolumetestdata
persistentVolumeClaim:
claimName: pvc-csi-az-blob-frontend-storage1-blobfusevolumetestdata
- name: csi-az-blob-frontend-storage3-blobfusevolumetestdata3
persistentVolumeClaim:
claimName: pvc-csi-az-blob-frontend-storage3-blobfusevolumetestdata3
and files appear inside the container
kubectl exec -it -n radix-example-dev deploy/frontend -- ls -lR /app
/app:
total 4
drwxrwxrwx 2 root root 4096 Dec 11 15:10 image-storage
drwxrwxrwx 2 root root 4096 Dec 11 15:10 image-storage3
-rw-r--r-- 1 root root 1343 Dec 11 11:52 index.html
/app/image-storage:
total 0
-rwxrwxrwx 1 root root 21133 Nov 13 13:56 image-01.png
-rwxrwxrwx 1 root root 21989 Nov 13 13:56 image-02.png
-rwxrwxrwx 1 root root 47540 Nov 26 14:51 image-04.png
-rwxrwxrwx 1 root root 48391 Nov 26 14:50 image-06.png
-rwxrwxrwx 1 root root 47732 Nov 26 14:50 image-07.png
/app/image-storage3:
total 0
-rwxrwxrwx 1 root root 27803 Dec 11 11:11 image-01.png
-rwxrwxrwx 1 root root 28692 Dec 11 11:11 image-02.png
-rwxrwxrwx 1 root root 29008 Dec 11 11:11 image-03.png
-rwxrwxrwx 1 root root 59023 Dec 11 11:11 image-04.png
-rwxrwxrwx 1 root root 28732 Dec 11 11:11 image-05.png
-rwxrwxrwx 1 root root 60062 Dec 11 11:11 image-06.png
-rwxrwxrwx 1 root root 59143 Dec 11 11:11 image-07.png