I'm trying to create a Redis Cluster on Azure AKS using Bitnami Helm Chart, but I can't get it working.
My cluster have two node pools, one running linux and the other running windows machines, so, I have to specify the nodeSelector attribute. My command is:
helm install --set master.nodeSelector."kubernetes\.io/os"="linux" --set slave.nodeSelector."kubernetes\.io/os"="linux" redis azure-marketplace/redis
I got it from https://bitnami.com/stack/redis/helm
When I run the helm install the master node start running as expected, but the slave node fails. The message says:
Warning FailedMount 26s (x2 over 2m41s) kubelet Unable to attach or mount volumes: unmounted volumes=[redis-data], unattached volumes=[health redis-data config redis-tmp-conf default-token-p7zgf start-scripts]: timed out waiting for the condition
Normal SuccessfulAttachVolume 3s attachdetach-controller AttachVolume.Attach succeeded for volume "pvc-aXXXXXXc-aXXf-4XXe-bXX9-9xxxxxxxxx49"
Warning FailedMount kubelet MountVolume.MountDevice failed for volume "pvc-aXXXXXXc-aXXf-4XXe-bXX9-9XXXXXXXXX49" : azureDisk - mountDevice:FormatAndMount failed with mount failed: exit status 32 Mounting command: systemd-run Mounting arguments: --description=Kubernetes transient mount for /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m38XXXXXX77 --scope -- mount -t ext4 -o defaults /dev/disk/azure/scsi1/lun0 /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m38XXXXXX77
Output: Running scope as unit: run-ra32XXXXXXXXXXXXXXXXXXXXXXXX7f2f7.scope mount: /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m38XXXXXX77: wrong fs type, bad option, bad superblock on /dev/sdc, missing codepage or helper program, or other error.
Warning FailedMount kubelet MountVolume.MountDevice failed for volume "pvc-aXXXXXXc-aXXf-4XXe-bXX9-9XXXXXXXXX49" : azureDisk - mountDevice:FormatAndMount failed with mount failed: exit status 32
I tried many times without success. What am I doing wrong?
Is the slave pod on the same node as where the Persistent Volume attached? We started using
volumeBindingMode: WaitForFirstConsumer
In our storage classes to help avoid pod and pv instantiating on different hosts.
Followup: It appears in this scenario the chart is relying on the clusters default storage class which did not have the same node affinity rules as the deployment/statefulset objects. Additionally the cluster has a mix of workers from different operating systems (win, linux). The chart logic was expecting a linux os mount and encountered a windows host instead.