Erreurs lors du montage d’un partage de fichiers Azure

Cet article fournit des causes et des solutions possibles pour les erreurs qui provoquent l’échec du montage d’un partage de fichiers Azure.

Symptômes

Vous déployez une ressource Kubernetes telle qu’un déploiement ou un StatefulSet, dans un environnement Azure Kubernetes Service (AKS). Le déploiement crée un pod qui monte un PersistentVolumeClaim (PVC) référençant un partage de fichiers Azure.

Toutefois, le pod reste dans le status ContainerCreating. Lorsque vous exécutez la kubectl describe pods commande, vous pouvez voir l’une des erreurs suivantes dans la sortie de la commande, ce qui entraîne l’échec de l’opération de montage :

• Erreur de montage(2) : aucun fichier ou répertoire de ce type
• Erreur de montage(13) : Autorisation refusée

Consultez l’exemple de sortie suivant :

MountVolume.MountDevice failed for volume "\<pv-fileshare-name>"
rpc error: code = Internal desc =
volume(\<storage-account's-resource-group>#\<storage-account-name>#\<pv/fileshare-name>#) > mount "//\<storage-account-name>.file.core.windows.net/\<pv-fileshare-name>" on "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/\<pv-fileshare-name>/globalmount" failed with
mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t cifs -o dir_mode=0777,file_mode=0777,uid=0,gid=0,mfsymlinks,cache=strict,actimeo=30,\<masked> //\<storage-account-name>.file.core.windows.net/\<pv-name> /var/lib/kubelet/plugins/kubernetes.io/csi/pv/\<pv-name>/globalmount
Output: mount error(\<error-id>): \<error-description>
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

Remarque

• Si le compte de stockage est accessible publiquement, le nom d’hôte affiché dans la sortie sera <storage-account-name.file.core.windows.net>.
• Si le compte de stockage est configuré en privé avec une liaison privée, un point de terminaison ou une zone DNS, le nom d’hôte est <storage-account-name.privatelink.file.core.windows.net>.

Avant la résolution des problèmes

En fonction du message dans la sortie, comme indiqué dans l’exemple suivant, identifiez le compte de stockage et le partage de fichiers. Les valeurs seront utilisées dans les étapes de dépannage ultérieures.

mount « //<storage-account-name.file.core.windows.net/>< pv-fileshare-name> »

Consultez les sections suivantes pour connaître les causes possibles et les solutions.

Erreur de montage(2) : aucun fichier ou répertoire de ce type

Cette erreur indique qu’il n’existe aucune connectivité entre le cluster AKS et le compte de stockage.

Résolution des problèmes initiaux

Azure File s’appuie sur le protocole SMB (port 445). Assurez-vous que le port 445 et/ou l’adresse IP du compte de stockage ne sont pas bloqués.

Pour case activée l’adresse IP du compte de stockage, exécutez une commande DNS (Domain Name System) comme nslookup, digou host. Par exemple :

nslookup <storage-account-name>.file.core.windows.net

Pour case activée s’il existe une connectivité entre le cluster AKS et le compte de stockage, accédez au nœud ou au pod et exécutez la commande ou telnet suivante nc :

nc -v -w 2 <storage-account-name>.file.core.windows.net 445

telnet <storage-account-name>.file.core.windows.net 445

Causes possibles de l’erreur de montage(2)

• Cause 1 : Le partage de fichiers n’existe pas
• Cause 2 : le groupe de sécurité réseau bloque le trafic entre AKS et le compte de stockage
• Cause 3 : L’appliance virtuelle bloque le trafic entre AKS et le compte de stockage
• Cause 4 : le pool de nœuds compatible FIPS est utilisé

Remarque

• Cause 1, 2 et 4 s’appliquent aux scénarios de compte de stockage public et privé.
• La cause 3 s’applique uniquement au scénario public.

Cause 1 : Le partage de fichiers n’existe pas

Pour case activée si le partage de fichiers existe, procédez comme suit :

1. Recherche comptes de stockage dans le Portail Azure et accédez à votre compte de stockage.

   

2. Sélectionnez Partages de fichiers sous Stockage de données dans le compte de stockage et case activée si l’élément PersistentVolumeClaim associé dans le fichier yaml du pod, du déploiement ou de l’ensemble de états existe dans les partages de fichiers.

   

Solution : Vérifier l’existence d’un partage de fichiers

Pour résoudre ce problème, assurez-vous que le partage de fichiers associé au PV/PVC existe.

Cause 2 : Le groupe de sécurité réseau bloque le trafic entre AKS et le compte de stockage

Vérifiez la sortie de la nc commande ou telnet mentionnée dans la section Résolution des problèmes initial . Si un délai d’expiration s’affiche, case activée le groupe de sécurité réseau (NSG) et assurez-vous que l’adresse IP du compte de stockage n’est pas bloquée.

Pour case activée si le groupe de sécurité réseau bloque l’adresse IP du compte de stockage, procédez comme suit :

1. Dans le Portail Azure, accédez à Network Watcher et sélectionnez Diagnostic NSG.

2. Renseignez les champs à l’aide des valeurs suivantes :

   • Protocole : n’importe quel
   • Direction : sortant
   • Type de source : adresse IPv4/CIDR
   • Adresse IPv4/CIDR : adresse IP d’un instance associé au nœud AKS
   • Adresse IP de destination : adresse IP du compte de stockage
   • Port de destination : 445

3. Sélectionnez le bouton Vérifier et case activée le status trafic.

Le trafic status peut être Autorisé ou Refusé. Le status Refusé signifie que le groupe de sécurité réseau bloque le trafic entre le cluster AKS et le compte de stockage. Si le status est Refusé, le nom du groupe de sécurité réseau s’affiche.

Solution : Autoriser la connectivité entre AKS et le compte de stockage

Pour résoudre ce problème, effectuez des modifications en conséquence au niveau du groupe de sécurité réseau pour permettre la connectivité entre le cluster AKS et le compte de stockage sur le port 445.

Cause 3 : L’appliance virtuelle bloque le trafic entre AKS et le compte de stockage

Si vous utilisez une appliance virtuelle (généralement un pare-feu) pour contrôler le trafic sortant du cluster AKS (par exemple, une table de routage est appliquée à l’appliance virtuelle sur le sous-réseau du cluster AKS et que la table de routage a des itinéraires qui envoient le trafic vers l’appliance virtuelle), l’appliance virtuelle peut bloquer le trafic entre le cluster AKS et le compte de stockage.

Pour isoler le problème, ajoutez un itinéraire dans la table de routage pour l’adresse IP du compte de stockage afin d’envoyer le trafic vers Internet.

Pour vérifier quelle table de routage contrôle le trafic du cluster AKS, procédez comme suit :

1. Accédez au cluster AKS dans le Portail Azure et sélectionnez Propriétés>Groupe de ressources Infrastructure.
2. Accédez au groupe de machines virtuelles identiques (VMSS) ou à une machine virtuelle dans un groupe à haute disponibilité si vous utilisez ce type de jeu de machines virtuelles.
3. Sélectionnez Réseau virtuel/sous-réseau>Sous-réseaux et identifiez le sous-réseau du cluster AKS. Sur le côté droit, vous verrez la table de routage.

Pour ajouter l’itinéraire dans la table de routage, suivez les étapes décrites dans Créer un itinéraire et renseignez les champs suivants :

• Préfixe d’adresse : <storage-account’s-public-IP>/32
• Type de tronçon suivant : Internet

Cet itinéraire envoie tout le trafic entre le cluster AKS et le compte de stockage via l’Internet public.

Après avoir ajouté l’itinéraire, testez la connectivité à l’aide de la nc commande ou et telnet effectuez à nouveau l’opération de montage.

Solution : Vérifier que l’appliance virtuelle autorise le trafic entre AKS et le compte de stockage

Si l’opération de montage réussit, nous vous recommandons de consulter votre équipe de mise en réseau pour vous assurer que l’appliance virtuelle peut autoriser le trafic entre le cluster AKS et le compte de stockage sur le port 445.

Cause 4 : le pool de nœuds compatible FIPS est utilisé

Si vous utilisez un pool de nœuds FIPS (Federal Information Processing Standard), l’opération de montage échoue, car fiPS désactive certains modules d’authentification, ce qui empêche le montage d’un partage CIFS. Ce comportement est attendu et non spécifique à AKS.

Pour résoudre le problème, utilisez l’une des solutions suivantes :

Solution 1 : Planifier des pods sur des nœuds dans un pool de nœuds non-FIPS

FIPS est désactivé par défaut sur les pools de nœuds AKS et ne peut être activé que lors de la création du pool de nœuds à l’aide du --enable-fips-image paramètre .

Pour résoudre l’erreur, vous pouvez planifier les pods sur les nœuds d’un pool de nœuds non-FIPS.

Solution 2 : Créer un pod qui peut être planifié sur un nœud compatible FIPS

Pour créer un pod qui peut être planifié sur un nœud compatible FIPS, procédez comme suit :

1. Utilisez le pilote CSI Azure File pour créer un StorageClass personnalisé qui utilise le protocole NFS.

   Reportez-vous au fichier YAML suivant comme exemple :

   kind: StorageClass 
   apiVersion: storage.k8s.io/v1 
   metadata: 
     name: azurefile-sc-fips 
   provisioner: file.csi.azure.com 
   reclaimPolicy: Delete 
   volumeBindingMode: Immediate 
   allowVolumeExpansion: true 
   parameters: 
     skuName: Premium_LRS 
     protocol: nfs 
   

   La référence SKU est définie sur Premium_LRS dans le fichier YAML, car la référence SKU Premium est requise pour NFS. Pour plus d’informations, consultez Provisionnement dynamique.

   En raison de la référence SKU Premium, la taille minimale du partage de fichiers est de 100 Go. Pour plus d’informations, consultez Créer une classe de stockage.

2. Créez un PVC qui référence le StorageClass personnalisé azurefile-sc-fips.

   Reportez-vous au fichier YAML suivant comme exemple :

   apiVersion: v1 
   kind: PersistentVolumeClaim 
   metadata: 
     name: azurefile-pvc-fips 
   spec: 
     accessModes: 
       - ReadWriteMany 
     storageClassName: azurefile-sc-fips 
     resources: 
       requests: 
         storage: 100Gi 
   

3. Créez un pod qui monte le PVC azurefile-pvc-fips.

   Reportez-vous au fichier YAML suivant comme exemple :

   kind: Pod 
   apiVersion: v1 
   metadata: 
     name: azurefile-pod-fips 
   spec: 
     containers: 
     - name: azurefile-pod-fips 
       image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine 
       resources: 
         requests: 
           cpu: 100m 
           memory: 128Mi 
         limits: 
           cpu: 250m 
           memory: 256Mi 
       volumeMounts: 
       - mountPath: "/mnt/azure" 
         name: volume 
     volumes: 
       - name: volume 
         persistentVolumeClaim: 
           claimName: azurefile-pvc-fips 
   

Erreur de montage(13) : Autorisation refusée

Voici les causes possibles de cette erreur :

• Cause 1 : le secret Kubernetes ne fait pas référence au nom ou à la clé de compte de stockage corrects
• Cause 2 : le réseau virtuel et le sous-réseau AKS ne sont pas autorisés pour le compte de stockage
• Cause 3 : La connectivité se fait via une liaison privée, mais les nœuds et le point de terminaison privé se trouvent dans des réseaux virtuels différents
• Cause 4 : Le compte de stockage est configuré pour exiger un chiffrement que le client ne prend pas en charge
• Cause 5 : L’exigence minimale de chiffrement pour un compte de stockage n’est pas remplie

Remarque

• La cause 1 s’applique aux scénarios publics et privés.
• La cause 2 s’applique uniquement au scénario public.
• La cause 3 s’applique uniquement au scénario privé.
• La cause 4 s’applique aux scénarios publics et privés.
• La cause 5 s’applique aux scénarios publics et privés.

Cause 1 : le secret Kubernetes ne référence pas le nom ou la clé de compte de stockage corrects

Si le partage de fichiers est créé dynamiquement, une ressource secrète Kubernetes est automatiquement créée avec le nom « azure-storage-account-name-secret<> ».

Si le partage de fichiers est créé manuellement, la ressource secrète Kubernetes doit être créée manuellement.

Quelle que soit la méthode de création, si le nom du compte de stockage ou la clé référencée dans le secret Kubernetes ne correspond pas à la valeur réelle, l’opération de montage échoue avec l’erreur « Autorisation refusée ».

Causes possibles de l’incompatibilité

• Si le secret Kubernetes est créé manuellement, une faute de frappe peut se produire lors de la création.

• Si une opération de « rotation de clé » est effectuée au niveau du compte de stockage, les modifications ne se reflètent pas au niveau du secret Kubernetes. Cela entraîne une incompatibilité entre la valeur de clé au niveau du compte de stockage et la valeur au niveau du secret Kubernetes.

  Si une opération « Rotation de clé » se produit, une opération nommée « Régénérer les clés de compte de stockage » s’affiche dans le journal d’activité du compte de stockage. Tenez compte de la période de rétention de 90 jours pour le journal d’activité.

Vérifier l’incompatibilité

Pour vérifier l’incompatibilité, procédez comme suit :

1. Recherche et accéder au compte de stockage dans le Portail Azure. Sélectionnez Clés >d’accèsAfficher les clés dans le compte de stockage. Vous verrez le nom du compte de stockage et les clés associées.

   

2. Accédez au cluster AKS, sélectionnezSecretsde configuration>, puis recherchez et accédez au secret associé.

   

3. Sélectionnez Afficher (icône d’œil) et comparez les valeurs du nom du compte de stockage et de la clé associée aux valeurs de l’étape 1.

   

   Avant de sélectionner Afficher, les valeurs du nom du compte de stockage et de la clé associée sont encodées en chaînes base64. Une fois que vous avez sélectionné Afficher, les valeurs sont décodées.

Si vous n’avez pas accès au cluster AKS dans le Portail Azure, effectuez l’étape 2 au niveau kubectl :

1. Obtenez le fichier YAML du secret Kubernetes, puis exécutez la commande suivante pour obtenir les valeurs du nom du compte de stockage et de la clé à partir de la sortie :

   kubectl get secret <secret-name> -n <secret-namespace> -o <yaml-file-name>
   

2. Utilisez la echo commande pour décoder les valeurs du nom du compte de stockage et de la clé et les comparer aux valeurs au niveau du compte de stockage.

   Voici un exemple pour décoder le nom du compte de stockage :

   echo -n '<storage account name>' | base64 --decode ;echo
   

   

Solution : Ajustez le secret Kubernetes et recréez les pods

Si la valeur du nom du compte de stockage ou de la clé dans le secret Kubernetes ne correspond pas à la valeur dans Clés d’accès dans le compte de stockage, ajustez le secret Kubernetes au niveau du secret Kubernetes en exécutant la commande suivante :

kubectl edit secret <secret-name> -n <secret-namespace>

La valeur du nom du compte de stockage ou de la clé ajoutée dans la configuration du secret Kubernetes doit être une valeur codée en base64. Pour obtenir la valeur encodée, utilisez la echo commande .

Voici un exemple pour encoder le nom du compte de stockage :

echo -n '<storage account name>'| base64 | tr -d '\n' ; echo

Pour plus d’informations, consultez Gestion des secrets à l’aide de kubectl.

Une fois que le secret azure-storage-account-<storage-account-name>-secret Kubernetes a les valeurs appropriées, recréez les pods. Sinon, ces pods continueront à utiliser les anciennes valeurs qui ne sont plus valides.

Cause 2 : le réseau virtuel et le sous-réseau AKS ne sont pas autorisés pour le compte de stockage

Si le réseau du compte de stockage est limité aux réseaux sélectionnés, mais que le réseau virtuel et le sous-réseau du cluster AKS ne sont pas ajoutés aux réseaux sélectionnés, l’opération de montage échoue avec l’erreur « Autorisation refusée ».

Solution : Autoriser le réseau virtuel et le sous-réseau d’AKS pour le compte de stockage

1. Identifiez le nœud qui héberge le pod défectueux en exécutant la commande suivante :

   kubectl get pod <pod-name> -n <namespace> -o wide
   

   Vérifiez le nœud à partir de la sortie de la commande :

   

2. Accédez au cluster AKS dans le Portail Azure, sélectionnez Propriétés>Groupe de ressources Infrastructure, accédez au VMSS associé au nœud, puis case activée Réseau virtuel/sous-réseau pour identifier le réseau virtuel et le sous-réseau.

   

3. Accédez au compte de stockage dans le Portail Azure. Sélectionnez Mise en réseau. Si Autoriser l’accès à partir de est défini sur Réseaux sélectionnés, case activée si le réseau virtuel et le sous-réseau du cluster AKS sont ajoutés.

   

   Si le réseau virtuel et le sous-réseau du cluster AKS ne sont pas ajoutés, sélectionnez Ajouter un réseau virtuel existant. Dans la page Ajouter des réseaux, tapez le réseau virtuel et le sous-réseau du cluster AKS, puis sélectionnez Ajouter enregistrer>.

   

   L’application des modifications peut prendre quelques instants. Une fois le réseau virtuel et le sous-réseau ajoutés, case activée si le pod status passe de ContainerCreating à Running.

   

Cause 3 : La connectivité se fait via une liaison privée, mais les nœuds et le point de terminaison privé se trouvent dans des réseaux virtuels différents

Lorsque le cluster AKS et le compte de stockage sont connectés via une liaison privée, une connexion de point de terminaison privé approuvée est utilisée.

Dans ce scénario, si le point de terminaison privé et le nœud AKS se trouvent dans le même réseau virtuel, vous pouvez monter un partage de fichiers Azure.

Si le point de terminaison privé et votre cluster AKS se trouvent dans des réseaux virtuels différents, l’opération de montage échoue avec l’erreur « Autorisation refusée ».

Solution : Créer une liaison de réseau virtuel pour le réseau virtuel du cluster AKS dans la zone DNS privée

Entrez dans le nœud et case activée si le nom de domaine complet (FQDN) est résolu via une adresse IP publique ou privée. Pour ce faire, exécutez la commande suivante :

nslookup <storage-account-name>.privatelink.file.core.windows.net

Si le nom de domaine complet est résolu via une adresse IP publique (voir la capture d’écran suivante), créez un lien réseau virtuel pour le réseau virtuel du cluster AKS au niveau de la zone DNS privée (« privatelink.file.core.windows.net »). Notez qu’une liaison de réseau virtuel est déjà créée automatiquement pour le réseau virtuel du point de terminaison privé du compte de stockage.

Pour créer le lien de réseau virtuel, procédez comme suit :

1. Accédez à la zone DNS privé et sélectionnez Liens de> réseau virtuelAjouter.

   

2. Renseignez les champs et sélectionnez le réseau virtuel du cluster AKS pour Réseaux virtuels. Pour savoir comment identifier le réseau virtuel du cluster AKS, consultez la section Solution : Autoriser le réseau virtuel et le sous-réseau AKS pour le compte de stockage .

   

3. Sélectionnez OK.

Une fois la liaison de réseau virtuel ajoutée, le nom de domaine complet doit être résolu via une adresse IP privée et l’opération de montage doit réussir. Pour obtenir un exemple, consultez la capture d’écran suivante :

Cause 4 : Le compte de stockage est configuré pour exiger un chiffrement que le client ne prend pas en charge

Azure Files Paramètres de sécurité contiennent un certain nombre d’options permettant de contrôler les paramètres de sécurité et de chiffrement sur les comptes de stockage. La restriction des méthodes et algorithmes autorisés peut empêcher les clients de se connecter.

Les versions d’AKS antérieures à 1.25 sont basées sur Ubuntu 18.04 LTS, qui utilise le noyau Linux 5.4 et prend uniquement en charge les algorithmes de chiffrement AES-128-CCM et AES-128-GCM. Le profil de sécurité maximale , ou profil personnalisé qui désactive AES-128-GCM, entraîne des échecs de mappage de partage.

AKS versions 1.25 et ultérieures sont basées sur Ubuntu 22.04, qui utilise le noyau Linux 5.15 et prend en charge AES-256-GCM.

Solution : Autoriser l’utilisation de l’algorithme de chiffrement AES-128-GCM

Activez l’algorithme AES-128-GCM à l’aide du profil de compatibilité maximale ou d’un profil personnalisé qui active AES-128-GCM. Pour plus d’informations, consultez Azure Files Paramètres de sécurité.

Cause 5 : L’exigence minimale de chiffrement pour un compte de stockage n’est pas remplie

Solution : Activer l’algorithme de chiffrement AES-128-GCM pour tous les comptes de stockage

Pour monter ou accéder à un partage de fichiers, l’algorithme de chiffrement AES-128-GCM doit être activé pour tous les comptes de stockage.

Si vous souhaitez utiliser le chiffrement AES-256-GCM uniquement, qui correspond à la sécurité maximale (SMB 3.1.1), procédez comme suit :

Linux

Utilisez le script suivant pour case activée si le client prend en charge AES-256-GCM et l’appliquer uniquement si c’est le cas :

cifsConfPath="/etc/modprobe.d/cifs.conf" 
echo "`date` before change ${cifsConfPath}:"
cat ${cifsConfPath}
if !(( grep require_gcm_256 ${cifsConfPath} ))
then
modprobe cifs
echo 1 > /sys/module/cifs/parameters/require_gcm_256
echo "options cifs require_gcm_256=1" > ${cifsConfPath}
echo "`date` after changing ${cifsConfPath}:"
cat ${cifsConfPath}
fi

Windows

Utilisez la commande PowerShell Set-SmbClientConfiguration pour spécifier les chiffrements utilisés par le client SMB et le type de chiffrement préféré sans confirmation de l’utilisateur :

Set-SmbClientConfiguration -EncryptionCiphers "AES_256_GCM" -Confirm:$false

Remarque

Le EncryptionCiphers paramètre est disponible à partir de la mise à jour cumulative 2022-06 pour Windows Server version 21H2 pour les systèmes x64 (KB5014665) et de la mise à jour cumulative pour Windows 11, version 22H2 (KB5014668).

Informations supplémentaires

Si vous rencontrez d’autres erreurs de montage, consultez Résoudre les problèmes de Azure Files dans Linux.

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.