Impossible de définir les options de montage uid et gid sur un disque Azure

Cet article explique comment résoudre les problèmes qui se produisent sur un cluster Microsoft Azure Kubernetes Service (AKS) lorsque vous essayez de définir les options de montage pour l’identificateur d’utilisateur (uid) et l’identificateur de groupe (gid) sur un disque Azure.

Symptômes

Si vous essayez de définir uid et gid de définir 1 000 dans le paramètre de la mountOptions configuration de la classe de stockage du disque Azure, vous recevez une erreur semblable au texte suivant :

Warning  FailedMount             63s                  kubelet, aks-nodepool1-29460110-0  MountVolume.MountDevice failed for volume "pvc-d783d0e4-85a1-11e9-8a90-369885447933" : 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/m436970985 --scope -- mount -t xfs -o dir_mode=0777,file_mode=0777,uid=1000,gid=1000,defaults /dev/disk/azure/scsi1/lun2 /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m436970985
Output: Running scope as unit run-rb21966413ab449b3a242ae9b0fbc9398.scope.
mount: wrong fs type, bad option, bad superblock on /dev/sde,
       missing codepage or helper program, or other error

Cause

Le disque Azure utilise par défaut le filesytem ext4,xfs, et des options de montage telles que uid=x,gid=x ne peuvent pas être définies au moment du montage.

Solution de contournement 1 : utiliser un contexte de sécurité de pod pour spécifier l’utilisateur et le groupe

Configurez le contexte de sécurité d’un pod. Dans le fichier de configuration de pod (format YAML), dans le spec/securityContext champ, définissez le runAsUser champ sur la valeur spécifiée uid précédemment et définissez le fsGroup champ sur la valeur spécifiée gid précédemment. Par exemple, le début du fichier de configuration peut ressembler au code suivant :

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Note

Par défaut, les options gidet uid sont montées en tant que racine ou 0. Si ces options sont définies sur non racine (par exemple, 1000), Kubernetes utilise la commande change owner (chown) pour modifier tous les répertoires et fichiers de ce disque. Cette opération peut prendre du temps et rendre l’opération de montage sur disque très lente.

Solution de contournement 2 : utiliser un conteneur init et la commande change owner pour spécifier l’utilisateur et le groupe

Configurez un conteneur init, puis exécutez une commande chown qui spécifie les valeurs d’utilisateur et de groupe dans le conteneur. Le code suivant montre comment configurer un conteneur init pour définir l’utilisateur et le groupe :

initContainers:
- name: volume-mount
  image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
  command: ["sh", "-c", "chown -R 100:100 /data"]
  volumeMounts:
  - name: <your-data-volume>
    mountPath: /data

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.