Condividi tramite

Errori durante il montaggio di una condivisione file di Azure

  • Articolo

Questo articolo fornisce le possibili cause e soluzioni per gli errori che causano l'esito negativo del montaggio di una condivisione file di Azure.

Sintomi

Si distribuisce una risorsa Kubernetes, ad esempio una distribuzione o un statefulSet, in un ambiente servizio Azure Kubernetes (servizio Azure Kubernetes). La distribuzione creerà un pod che monta un'istanza di PersistentVolumeClaim (PVC) che fa riferimento a una condivisione file di Azure.

Tuttavia, il pod rimane nello stato ContainerCreating . Quando si esegue il kubectl describe pods comando, nell'output del comando potrebbe essere visualizzato uno degli errori seguenti, che causa l'esito negativo dell'operazione di montaggio:

Fare riferimento al seguente output come esempio:

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)

Nota

  • Se l'account di archiviazione è accessibile pubblicamente, il nome host visualizzato nell'output sarà <storage-account-name.file.core.windows.net>.
  • Se l'account di archiviazione è configurato privatamente con un collegamento privato, un endpoint o una zona DNS, il nome host sarà <storage-account-name.privatelink.file.core.windows.net>.

Prima della risoluzione dei problemi

In base al messaggio nell'output, come illustrato nell'esempio seguente, identificare l'account di archiviazione e la condivisione file, i valori verranno usati nei passaggi successivi per la risoluzione dei problemi.

montare "//<storage-account-name.file.core.windows.net/>< pv-fileshare-name>"

Vedere le sezioni seguenti per le possibili cause e soluzioni.

Errore di montaggio(2): nessun file o directory di questo tipo

Questo errore indica che non esiste connettività tra il cluster del servizio Azure Kubernetes e l'account di archiviazione.

Risoluzione dei problemi iniziale

File di Azure si basa sul protocollo SMB (porta 445). Assicurarsi che la porta 445 e/o l'indirizzo IP dell'account di archiviazione non siano bloccati.

Per controllare l'indirizzo IP dell'account di archiviazione, eseguire un comando DNS (Domain Name System) come nslookup, digo host. Ad esempio:

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

Per verificare se esiste connettività tra il cluster del servizio Azure Kubernetes e l'account di archiviazione, accedere al nodo o al pod ed eseguire il comando o telnet seguentenc:

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

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

Possibili cause dell'errore di montaggio(2)

Nota

  • La causa 1, 2 e 4 si applica agli scenari di account di archiviazione pubblici e privati.
  • La causa 3 si applica solo allo scenario pubblico.

Causa 1: La condivisione file non esiste

Per verificare se la condivisione file esiste, seguire questa procedura:

  1. Search account di archiviazione nel portale di Azure e accedere all'account di archiviazione.

    Screenshot dell'elenco degli account di archiviazione in portale di Azure.

  2. Selezionare Condivisioni file in Archiviazione dati nell'account di archiviazione e verificare se l'oggetto PersistentVolumeClaim associato nel file yaml del pod, della distribuzione o dello statefulset è presente nelle condivisioni file.

    Screenshot della selezione delle condivisioni file nell'account di archiviazione.

Soluzione: verificare che la condivisione file esista

Per risolvere questo problema, assicurarsi che la condivisione file associata al PV/PVC esista.

Causa 2: Il gruppo di sicurezza di rete blocca il traffico tra il servizio Azure Kubernetes e l'account di archiviazione

Controllare l'output del nc comando o telnet indicato nella sezione Risoluzione dei problemi iniziale . Se viene visualizzato un timeout, controllare il gruppo di sicurezza di rete (NSG) e assicurarsi che l'indirizzo IP dell'account di archiviazione non sia bloccato.

Per verificare se il gruppo di sicurezza di rete blocca l'indirizzo IP dell'account di archiviazione, seguire questa procedura:

  1. Nel portale di Azure passare a Network Watcher e selezionare Diagnostica gruppo di sicurezza di rete.

  2. Compilare i campi usando i valori seguenti:

    • Protocollo: qualsiasi
    • Direzione: In uscita
    • Tipo di origine: indirizzo IPv4/CIDR
    • Indirizzo IPv4/CIDR: indirizzo IP di un'istanza associata al nodo del servizio Azure Kubernetes
    • Indirizzo IP di destinazione: indirizzo IP dell'account di archiviazione
    • Porta di destinazione: 445

  3. Selezionare il pulsante Controlla e controllare lo stato del traffico .

Lo stato del traffico può essere Consentito o Negato. Lo stato Negato indica che il gruppo di sicurezza di rete blocca il traffico tra il cluster del servizio Azure Kubernetes e l'account di archiviazione. Se lo stato è Negato, verrà visualizzato il nome del gruppo di sicurezza di rete.

Soluzione: consentire la connettività tra il servizio Azure Kubernetes e l'account di archiviazione

Per risolvere questo problema, eseguire le modifiche di conseguenza a livello di gruppo di sicurezza di rete per consentire la connettività tra il cluster del servizio Azure Kubernetes e l'account di archiviazione sulla porta 445.

Causa 3: l'appliance virtuale blocca il traffico tra il servizio Azure Kubernetes e l'account di archiviazione

Se si usa un'appliance virtuale (in genere un firewall) per controllare il traffico in uscita del cluster del servizio Azure Kubernetes( ad esempio, l'appliance virtuale ha una tabella di route applicata nella subnet del cluster del servizio Azure Kubernetes e la tabella di route include route che inviano traffico verso l'appliance virtuale), l'appliance virtuale può bloccare il traffico tra il cluster del servizio Azure Kubernetes e l'account di archiviazione.

Per isolare il problema, aggiungere una route nella tabella di route per l'indirizzo IP dell'account di archiviazione per inviare il traffico verso Internet.

Per verificare quale tabella di route controlla il traffico del cluster del servizio Azure Kubernetes, seguire questa procedura:

  1. Passare al cluster del servizio Azure Kubernetes nel portale di Azure e selezionare Gruppodirisorse Infrastruttura proprietà>.
  2. Accedere al set di scalabilità di macchine virtuali (VMSS) o a una macchina virtuale in un set di disponibilità se si usa tale tipo di set di macchine virtuali.
  3. Selezionare Subnet di rete virtuale/subnet>e identificare la subnet del cluster del servizio Azure Kubernetes. Sul lato destro verrà visualizzata la tabella di route.

Per aggiungere la route nella tabella di route, seguire la procedura descritta in Creare una route e compilare i campi seguenti:

  • Prefisso indirizzo: <storage-account's-public-IP>/32
  • Tipo di hop successivo:Internet

Questa route invierà tutto il traffico tra il cluster del servizio Azure Kubernetes e l'account di archiviazione tramite Internet pubblico.

Dopo aver aggiunto la route, testare la connettività usando il nc comando o telnet ed eseguire di nuovo l'operazione di montaggio.

Soluzione: verificare che l'appliance virtuale consenta il traffico tra il servizio Azure Kubernetes e l'account di archiviazione

Se l'operazione di montaggio ha esito positivo, è consigliabile consultare il team di rete per assicurarsi che l'appliance virtuale possa consentire il traffico tra il cluster del servizio Azure Kubernetes e l'account di archiviazione sulla porta 445.

Causa 4: viene usato il pool di nodi abilitato per FIPS

Se si usa un pool di nodi fips (Federal Information Processing Standard) abilitato, l'operazione di montaggio avrà esito negativo perché fips disabilita alcuni moduli di autenticazione, che impedisce il montaggio di una condivisione CIFS. Questo comportamento è previsto e non è specifico del servizio Azure Kubernetes.

Per risolvere il problema, usare una delle soluzioni seguenti:

Soluzione 1: Pianificare i pod nei nodi in un pool di nodi non FIPS

FIPS è disabilitato per impostazione predefinita nei pool di nodi del servizio Azure Kubernetes e può essere abilitato solo durante la creazione del pool di nodi usando il --enable-fips-image parametro .

Per risolvere l'errore, è possibile pianificare i pod nei nodi in un pool di nodi non FIPS.

Soluzione 2: Creare un pod che può essere pianificato in un nodo abilitato per FIPS

Per creare un pod che può essere pianificato in un nodo abilitato per FIPS, seguire questa procedura:

  1. Usare il driver CSI file di Azure per creare una classe di archiviazione personalizzata che usa il protocollo NFS.

    Fare riferimento al file YAML seguente come esempio:

    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

    Lo SKU è impostato su Premium_LRS nel file YAML perché lo SKU Premium è necessario per NFS. Per altre informazioni, vedere Provisioning dinamico.

    A causa dello SKU Premium, la dimensione minima della condivisione file è di 100 GB. Per altre informazioni, vedere Creare una classe di archiviazione.

  2. Creare un PVC che faccia riferimento all'oggetto StorageClass personalizzato azurefile-sc-fips.

    Fare riferimento al file YAML seguente come esempio:

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

  3. Creare un pod che monta il PVC azurefile-pvc-fips.

    Fare riferimento al file YAML seguente come esempio:

    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

Errore di montaggio(13): autorizzazione negata

Di seguito sono riportate le possibili cause dell'errore:

Nota

  • La causa 1 si applica agli scenari pubblici e privati.
  • La causa 2 si applica solo allo scenario pubblico.
  • La causa 3 si applica solo allo scenario privato.
  • La causa 4 si applica agli scenari pubblici e privati.
  • La causa 5 si applica agli scenari pubblici e privati.

Causa 1: il segreto Kubernetes non fa riferimento al nome o alla chiave dell'account di archiviazione corretto

Se la condivisione file viene creata in modo dinamico, viene creata automaticamente una risorsa privata Kubernetes con il nome "azure-storage-account-storage-account-name-secret<>".

Se la condivisione file viene creata manualmente, la risorsa privata Kubernetes deve essere creata manualmente.

Indipendentemente dal metodo di creazione, se il nome dell'account di archiviazione o la chiave a cui viene fatto riferimento nel segreto Kubernetes non corrisponde al valore effettivo, l'operazione di montaggio avrà esito negativo con l'errore "Autorizzazione negata".

Possibili cause di mancata corrispondenza

  • Se il segreto Kubernetes viene creato manualmente, potrebbe verificarsi un errore di digitazione durante la creazione.

  • Se viene eseguita un'operazione di rotazione della chiave a livello di account di archiviazione, le modifiche non verranno riflesse a livello di segreto Kubernetes. Ciò comporterà una mancata corrispondenza tra il valore della chiave a livello di account di archiviazione e il valore a livello di segreto Kubernetes.

    Se si verifica un'operazione "Ruota chiave", verrà visualizzata un'operazione con il nome "Rigenera chiavi account di archiviazione" nel log attività dell'account di archiviazione. Tenere presente il periodo di conservazione di 90 giorni per il log attività.

Verificare la mancata corrispondenza

Per verificare la mancata corrispondenza, seguire questa procedura:

  1. Search e accedere all'account di archiviazione nel portale di Azure. Selezionare Chiavi> di accessoMostra chiavi nell'account di archiviazione. Verranno visualizzati il nome dell'account di archiviazione e le chiavi associate.

    Screenshot del nome e delle chiavi dell'account di archiviazione.

  2. Passare al cluster del servizio Azure Kubernetes, selezionareSegretidi configurazione> e quindi cercare e accedere al segreto associato.

    Screenshot della ricerca e della selezione dell'account di archiviazione.

  3. Selezionare Mostra (icona a occhio) e confrontare i valori del nome dell'account di archiviazione e della chiave associata con i valori nel passaggio 1.

    Screenshot che mostra il nome e la chiave dell'account di archiviazione in un segreto.

    Prima di selezionare Mostra, i valori del nome dell'account di archiviazione e della chiave associata vengono codificati in stringhe base64. Dopo aver selezionato Mostra, i valori vengono decodificati.

Se non si ha accesso al cluster del servizio Azure Kubernetes nel portale di Azure, eseguire il passaggio 2 a livello kubectl:

  1. Ottenere il file YAML del segreto Kubernetes e quindi eseguire il comando seguente per ottenere i valori del nome dell'account di archiviazione e della chiave dall'output:

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

  2. Usare il echo comando per decodificare i valori del nome dell'account di archiviazione e della chiave e confrontarli con i valori a livello di account di archiviazione.

    Ecco un esempio per decodificare il nome dell'account di archiviazione:

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

    Screenshot del comando che decodifica il nome dell'account di archiviazione.

Soluzione: regolare il segreto Kubernetes e ricreare i pod

Se il valore del nome o della chiave dell'account di archiviazione nel segreto Kubernetes non corrisponde al valore nelle chiavi di accesso nell'account di archiviazione, modificare il segreto Kubernetes a livello di segreto Kubernetes eseguendo il comando seguente:

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

Il valore del nome dell'account di archiviazione o della chiave aggiunta nella configurazione del segreto Kubernetes deve essere un valore con codifica base64. Per ottenere il valore codificato, usare il echo comando .

Ecco un esempio per codificare il nome dell'account di archiviazione:

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

Per altre informazioni, vedere Gestione dei segreti tramite kubectl.

Dopo che il segreto azure-storage-account-<storage-account-name>-secret Kubernetes ha i valori corretti, ricreare i pod. In caso contrario, questi pod continueranno a usare i valori precedenti che non sono più validi.

Causa 2: la rete virtuale e la subnet del servizio Azure Kubernetes non sono consentite per l'account di archiviazione

Se la rete dell'account di archiviazione è limitata alle reti selezionate, ma la rete virtuale e la subnet del cluster del servizio Azure Kubernetes non vengono aggiunte alle reti selezionate, l'operazione di montaggio avrà esito negativo con l'errore "Autorizzazione negata".

Soluzione: consentire la rete virtuale e la subnet del servizio Azure Kubernetes per l'account di archiviazione

  1. Identificare il nodo che ospita il pod difettoso eseguendo il comando seguente:

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

    Controllare il nodo dall'output del comando:

    Screenshot del comando che può identificare il nodo e l'output.

  2. Passare al cluster del servizio Azure Kubernetes nel portale di Azure, selezionare Gruppo dirisorse Infrastrutturadelle proprietà>, accedere al servizio VMS associato al nodo e quindi selezionare Rete virtuale/subnet per identificare la rete virtuale e la subnet.

    Screenshot del valore di rete virtuale/subnet.

  3. Accedere all'account di archiviazione nel portale di Azure. Selezionare Rete. Se Consenti l'accesso da è impostato su Reti selezionate, verificare se la rete virtuale e la subnet del cluster del servizio Azure Kubernetes sono state aggiunte.

    Screenshot dell'elenco di reti selezionate vuote.

    Se la rete virtuale e la subnet del cluster del servizio Azure Kubernetes non vengono aggiunte, selezionare Aggiungi rete virtuale esistente. Nella pagina Aggiungi reti digitare la rete virtuale e la subnet del cluster del servizio Azure Kubernetes e quindi selezionare Aggiungi>salvataggio.

    Screenshot dell'aggiunta di reti all'account di archiviazione.

    L'applicazione delle modifiche potrebbe richiedere alcuni minuti. Dopo aver aggiunto la rete virtuale e la subnet, verificare se lo stato del pod passa da ContainerCreating a Running.

    Screenshot dell'output del comando che mostra lo stato corrente del pod.

Causa 3: la connettività avviene tramite collegamento privato, ma i nodi e l'endpoint privato si trovano in reti virtuali diverse

Quando il cluster del servizio Azure Kubernetes e l'account di archiviazione sono connessi tramite un collegamento privato, viene usata una connessione endpoint privato approvata.

Screenshot della connessione dell'endpoint privato.

In questo scenario, se l'endpoint privato e il nodo del servizio Azure Kubernetes si trovano nella stessa rete virtuale, sarà possibile montare una condivisione file di Azure.

Se l'endpoint privato e il cluster del servizio Azure Kubernetes si trovano in reti virtuali diverse, l'operazione di montaggio avrà esito negativo con l'errore "Autorizzazione negata".

Accedere al nodo e verificare se il nome di dominio completo (FQDN) viene risolto tramite un indirizzo IP pubblico o privato. A tale scopo, utilizzare il seguente comando:

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

Se il nome di dominio completo viene risolto tramite un indirizzo IP pubblico (vedere lo screenshot seguente), creare un collegamento di rete virtuale per la rete virtuale del cluster del servizio Azure Kubernetes a livello di zona DNS privata ("privatelink.file.core.windows.net"). Si noti che un collegamento di rete virtuale è già stato creato automaticamente per la rete virtuale dell'endpoint privato dell'account di archiviazione.

Screenshot che mostra che il nome di dominio completo viene risolto da un indirizzo IP pubblico.

Per creare il collegamento alla rete virtuale, seguire questa procedura:

  1. Accedere alla zona DNS privato e selezionare Collegamenti >di rete virtualeAggiungi.

    Screenshot che mostra un collegamento di rete virtuale aggiunto all'account di archiviazione.

  2. Compilare i campi e selezionare la rete virtuale del cluster del servizio Azure Kubernetes per reti virtuali. Per informazioni su come identificare la rete virtuale del cluster del servizio Azure Kubernetes, vedere la sezione Soluzione: Consentire la rete virtuale e la subnet del servizio Azure Kubernetes per l'account di archiviazione .

    Screenshot che mostra come aggiungere un collegamento di rete virtuale.

  3. Seleziona OK.

Dopo l'aggiunta del collegamento alla rete virtuale, il nome di dominio completo deve essere risolto tramite un indirizzo IP privato e l'operazione di montaggio dovrebbe avere esito positivo. Per un esempio, vedere lo screenshot seguente:

Screenshot che mostra che l'indirizzo IP privato è stato risolto.

Causa 4: l'account di archiviazione è impostato per richiedere la crittografia non supportata dal client

File di Azure Impostazioni di sicurezza contengono una serie di opzioni per controllare le impostazioni di sicurezza e crittografia negli account di archiviazione. La limitazione di metodi e algoritmi consentiti può impedire la connessione dei client.

Le versioni del servizio Azure Kubernetes precedenti alla versione 1.25 sono basate su Ubuntu 18.04 LTS, che usa il kernel Linux 5.4 e supporta solo gli algoritmi di crittografia AES-128-CCM e AES-128-GCM. Il profilo di sicurezza massimo o un profilo personalizzato che disabilita AES-128-GCM causerà errori di mapping delle condivisioni.

Le versioni 1.25 e successive del servizio Azure Kubernetes sono basate su Ubuntu 22.04, che usa il kernel Linux 5.15 e supporta AES-256-GCM.

Soluzione: consentire l'uso dell'algoritmo di crittografia AES-128-GCM

Abilitare l'algoritmo AES-128-GCM usando il profilo di compatibilità Massimo o un profilo personalizzato che abilita AES-128-GCM. Per altre informazioni, vedere File di Azure Impostazioni di sicurezza.

Causa 5: Il requisito minimo di crittografia per un account di archiviazione non viene soddisfatto

Soluzione: abilitare l'algoritmo di crittografia AES-128-GCM per tutti gli account di archiviazione

Per montare o accedere correttamente a una condivisione file, è necessario abilitare l'algoritmo di crittografia AES-128-GCM per tutti gli account di archiviazione.

Se si vuole usare solo la crittografia AES-256-GCM, ovvero la sicurezza massima (SMB 3.1.1), eseguire le operazioni seguenti:

Linux

Usare lo script seguente per verificare se il client supporta AES-256-GCM e applicarlo solo se lo supporta:

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

Usare il comando Di PowerShell Set-SmbClientConfiguration per specificare le crittografie di crittografia usate dal client SMB e il tipo di crittografia preferito senza conferma dell'utente:

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

Nota

Il EncryptionCiphers parametro è disponibile a partire dall'aggiornamento cumulativo 2022-06 per Windows Server versione 21H2 per i sistemi basati su x64 (KB5014665) e dall'aggiornamento cumulativo per Windows 11 versione 22H2 (KB5014668).

Ulteriori informazioni

Se si verificano altri errori di montaggio, vedere Risolvere i problemi di File di Azure in Linux.

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.