I've got an error on mounting AzureFile Share inside AKS(1.18.2) container (build on top of Ubuntu 18.04 with cifs-utils installed):
Warning FailedMount 0s kubelet, aks-nodepool1-37397744-vmss000001 MountVolume.SetUp failed for volume "myapplication-logs" : mount failed: exit status 32
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /var/lib/kubelet/pods/5e19e1d0-0bfd-4760-a87a-00cb0f3e573a/volumes/kubernetes.io~azure-file/crawler-logs --scope -- mount -t cifs -o file_mode=0777,dir_mode=0777,vers=3.0,<masked> //myazurestorage.file.core.windows.net/crawler-logs /var/lib/kubelet/pods/5e19e1d0-0bfd-4760-a87a-00cb0f3e573a/volumes/kubernetes.io~azure-file/myapplication-logs
Output: Running scope as unit run-r403b463e326d4562a7e44dc8fe018b4b.scope.
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Here is my yaml config:
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: myapplication-logs
provisioner: kubernetes.io/azure-file
reclaimPolicy: Retain
allowVolumeExpansion: true
parameters:
skuName: Standard_LRS
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: myapplication-logs
spec:
capacity:
storage: 3Gi
accessModes:
- ReadWriteMany
storageClassName: myapplication-logs
azureFile:
secretName: azurefilesharesecretname}
shareName: myapplication-logs
readOnly: false
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myapplication-logs
spec:
accessModes:
- ReadWriteMany
storageClassName: myapplication-logs
resources:
requests:
storage: 3Gi
---
apiVersion: apps/v1
spec:
selector:
matchLabels:
app: myapplication
replicas: 1
template:
spec:
containers:
name: myapplication
readinessProbe:
httpGet:
path: /probes/ready
port: 5000
timeoutSeconds: 60
periodSeconds: 10
ports:
- containerPort: 21602
- containerPort: 5000
livenessProbe:
httpGet:
path: /probes/healthy
port: 5000
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 30
image: myappacr.azurecr.io/myapplication:1.0.391
volumeMounts:
- readOnly: true
name: secrets-volume
mountPath: /usr/bin/myapp/Secrets
- name: configuration-volume
mountPath: /usr/bin/myapp/Configuration
- name: myapplication-logs
mountPath: /usr/bin/myapp/logs
imagePullSecrets:
- name: acr-dev-regcred
volumes:
- name: secrets-volume
secret:
secretName: myapplication-secrets
- configMap:
name: myapplication-configuration
name: configuration-volume
- name: myapplication-logs
persistentVolumeClaim:
claimName: myapplication-logs
metadata:
labels:
app: myapplication
kind: Deployment
metadata:
name: myapplication-deployment
labels:
app: myapplication
StorageClass, PersistentVolume and PersistentVolumeClaim is successfully deployd without any errors\events.
Cannot find out where is the problem? Any ideas on what is happening?
There are two ways to consume azure file share as volume from a container in AKS
Manually create and use a volume with Azure Files share. Docs here
In this case the PV need to specify mountOptions
apiVersion: v1 kind: PersistentVolume metadata: name: azurefile spec: capacity: storage: 5Gi accessModes: - ReadWriteMany storageClassName: azurefile azureFile: secretName: azure-secret shareName: aksshare readOnly: false mountOptions: - dir_mode=0777 - file_mode=0777 - uid=1000 - gid=1000 - mfsymlinks - nobrl
Dynamically create and use a persistent volume with Azure Files. Docs here
In this case StorageClass need to have mountOptions
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: my-azurefile provisioner: kubernetes.io/azure-file mountOptions: - dir_mode=0777 - file_mode=0777 - uid=0 - gid=0 - mfsymlinks - cache=strict parameters: skuName: Standard_LRS
Now looking at your yamls It seems you are mixing the manual and dynamic mode because you are creating both PersistentVolume
and a StorageClass
. I suggest to follow one of the suitable approach and have mountOptions
specified properly which is mandatory for both the modes.
Problem solved! There was a problem with secret I created. It was created with kubectl apply -f secret.json and accountstoragekey wasn't encoded in base64.
Thanx to Azure Support!