Errori durante il montaggio di una condivisione file di Azure

Sommario

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

Sintomi

Quando si distribuisce una risorsa Kubernetes, ad esempio una distribuzione o un oggetto StatefulSet in un ambiente Servizio Azure Kubernetes (AKS), la distribuzione crea un pod che monta un oggetto PersistentVolumeClaim (PVC) che fa riferimento a una condivisione file Azure.

Tuttavia, il pod rimane nello stato ContainerCreating. Quando si esegue il kubectl describe pods comando, è possibile che venga visualizzato uno degli errori seguenti nell'output del comando 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)

Note

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

Prerequisiti

In base al messaggio visualizzato nell'output, identifica l'account di archiviazione e la condivisione di file, come illustrato nell'esempio seguente. Usare questi valori nei passaggi successivi per la risoluzione dei problemi.

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

Per le possibili cause e soluzioni, vedere le sezioni seguenti.

Errore di montaggio (2): No such file or directory (Causa: il file o la directory non esiste)

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

Procedure iniziali per la risoluzione dei problemi

File di Azure si basa sul protocollo SMB (porta 445). Assicurarsi che la porta 445 e 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), ad esempio nslookup, digo host. Ad esempio:

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

Per verificare se vi sia connettività tra il cluster AKS e l'account di archiviazione, accedere al nodo o al pod ed eseguire il comando seguente nc o telnet:

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)

Note

  • Le cause 1, 2 e 4 si applicano 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. Cercare gli account di archiviazione nel portale di Azure e accedere al tuo account di archiviazione.

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

  2. Seleziona Condivisioni file in Archiviazione dati dell'account di archiviazione e verifica se il PersistentVolumeClaim associato (PVC) nel file YAML del pod, del deployment o dello statefulset è presente in Condivisioni file.

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

Soluzione: garantire l'esistenza della condivisione file

Per risolvere questo problema, assicurarsi che la condivisione file associata a PersistentVolume (PV) o PersistentVolumeClaim (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 comando nc o telnet menzionato 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 NSG.

  2. Compilare i campi con i valori seguenti:

    • Protocollo: Qualsiasi
    • Direzione: In uscita
    • Tipo di origine: indirizzo IPv4/CIDR
    • Indirizzo IPv4/CIDR: l'indirizzo IP di un'istanza associata al nodo AKS (Azure Kubernetes Service)
    • Indirizzo IP di destinazione: indirizzo IP dell'account di archiviazione
    • Porta di destinazione: 445

  3. Selezionare 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, viene visualizzato il nome dell'NSG.

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

Per risolvere questo problema, apportare modifiche a livello di NSG per consentire la connettività tra il cluster AKS e l'account di archiviazione sulla porta 445.

Causa 3: l'appliance virtuale blocca i flussi di traffico tra AKS e l'account di archiviazione

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

Per isolare il problema, aggiungere una rotta nella tabella di routing per l'indirizzo IP dell'account di archiviazione, in modo da instradare il traffico verso Internet.

Per confermare quale tabella di routing controlla il traffico del cluster AKS, si prega di seguire questa procedura:

  1. Passare al cluster AKS nel portale di Azure e selezionare Proprietà>Gruppo di risorse dell'infrastruttura.
  2. Accedi al set di scalabilità di macchine virtuali (VMSS) o a una macchina virtuale in un set di disponibilità, se usi questo tipo di set di VM.
  3. Selezionare Rete virtuale/subnet>Subnet e identificare la subnet del cluster di Azure Kubernetes Service. Viene visualizzata la tabella di route sul lato .

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

  • Prefisso indirizzo: <IP pubblico dell'account di archiviazione>/32
  • Tipo hop successivo: Internet

Questa rotta invia tutto il traffico tra il cluster AKS e l'account di archiviazione tramite la rete Internet pubblica.

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

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

Se l'operazione di montaggio riesce, consultare il team di rete per assicurarsi che l'appliance virtuale consenta il traffico tra il cluster AKS 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 abilitato per FIPS (Federal Information Processing Standard), l'operazione di montaggio ha esito negativo perché FIPS disabilita alcuni moduli di autenticazione. Questa limitazione impedisce di montare una condivisione CIFS. Questo comportamento è previsto e non è specifico di AKS.

Per risolvere il problema, usare una delle soluzioni seguenti:

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

Per impostazione predefinita, i pool di nodi di AKS hanno FIPS disabilitato. È possibile abilitare FIPS solo durante la creazione del pool di nodi usando il --enable-fips-image parametro .

Per risolvere l'errore, eseguire i pod su nodi appartenenti a un pool di nodi non FIPS.

Soluzione 2: Creare un pod da pianificare su un nodo con FIPS abilitato

Per creare un pod che puoi pianificare su un nodo con FIPS abilitato, segui questi passaggi:

  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 è 100 GB. Per altre informazioni, vedere Creare una classe di archiviazione.

  2. Creare un PVC che faccia riferimento allo 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

Possibili cause di questo errore:

Note

  • 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.
  • Causa 5 si applica agli scenari pubblici e privati.
  • La causa 6 si applica agli scenari pubblici e privati.

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

Se si crea dinamicamente la condivisione file, il sistema crea automaticamente una risorsa privata Kubernetes con il nome azure-storage-account-<storage-account-name>-secret.

Se si crea manualmente la condivisione file, è necessario creare manualmente la risorsa privata Kubernetes.

Indipendentemente dal metodo di creazione, se il nome o la chiave dell'account di archiviazione a cui fa riferimento il segreto Kubernetes non corrisponde al valore effettivo, l'operazione di montaggio non riesce con l'errore "Autorizzazione negata".

Possibili cause della mancata corrispondenza

  • Se si crea manualmente il segreto Kubernetes, è possibile introdurre un errore di digitatura.

  • Se si esegue un'operazione di rotazione della chiave a livello di account di archiviazione, il segreto Kubernetes non riflette le modifiche. Questa discrepanza si verifica tra il valore della chiave a livello dell'account di archiviazione e il valore a livello del segreto Kubernetes.

  • Se si esegue un'operazione di Rotazione della chiave, il registro attività dell'account di archiviazione mostra un'operazione denominata Rigenera le chiavi 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, attenersi alla seguente procedura:

  1. Cercare e accedere all'account di archiviazione nel portale di Azure. Selezionare Chiavi di accesso>Mostra chiavi nell'account di archiviazione. Viene visualizzato il nome dell'account di archiviazione e le chiavi associate.

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

  2. Passare al cluster AKS, selezionare Configurazione>Segreti e quindi individuare e accedere al segreto associato.

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

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

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

    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 di Azure Kubernetes Service nel portale di Azure, eseguire il passaggio 2 con 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 comando echo 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: modificare 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 comando echo.

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.

Una volta che il secret Kubernetes azure-storage-account-<storage-account-name>-secret ha i valori corretti, ricrea i pod. In caso contrario, i pod continuano a usare i valori precedenti che non sono più validi.

Causa 2: La rete virtuale AKS e la subnet non sono autorizzate per l'account di archiviazione

Se le regole del firewall limitano la rete dell'account di archiviazione alle reti selezionate, ma non si aggiungono la rete virtuale e la subnet del cluster AKS alle reti selezionate, l'operazione di montaggio non riesce e viene visualizzato l'errore "Autorizzazione negata". Per altre informazioni, vedi Configurare i firewall e le reti virtuali di Archiviazione di Azure e La rete virtuale o le regole del firewall sono abilitate nell'account di archiviazione.

Soluzione: consentire l'accesso della rete virtuale e della subnet di AKS all'account di archiviazione

  1. Eseguire il comando seguente per identificare il nodo che ospita il pod difettoso:

    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 AKS nel portale di Azure, selezionare Proprietà>Gruppo di risorse dell'infrastruttura, accedere al set di scalabilità di macchine virtuali associato al nodo e quindi controllare Rete virtuale/subnet per identificare la rete virtuale e la subnet.

    Screenshot del valore del parametro di rete virtuale/sottorete.

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

    Screenshot dell'elenco vuoto delle reti selezionate.

    Se non hai aggiunto la rete virtuale e la subnet del cluster AKS, seleziona Aggiungi una rete virtuale esistente. Nella pagina Aggiungi reti digitare la rete virtuale e la subnet del cluster del servizio Azure Kubernetes e quindi selezionare Aggiungi>salva.

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

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

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

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

Quando si collega il cluster AKS e l'account di archiviazione tramite un collegamento privato, si usa una connessione dell'endpoint privato approvata.

Screenshot della connessione all'endpoint privato.

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

Se l'endpoint privato e il cluster del servizio Azure Kubernetes si trovano in reti virtuali diverse, l'operazione di montaggio ha 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 l'FQDN viene risolto tramite un indirizzo IP pubblico (vedere lo screenshot seguente), creare un collegamento di rete virtuale per la rete virtuale del cluster AKS a livello della zona DNS privata ("privatelink.file.core.windows.net"). Viene già creato automaticamente un collegamento di rete virtuale per la rete virtuale dell'endpoint privato dell'account di archiviazione.

Screenshot dell'output del comando nslookup in cui il Fully Qualified Domain Name (FQDN) dell'account di archiviazione viene risolto in un indirizzo IP pubblico.

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

  1. Accedere alla zona DNS privata e selezionare Collegamenti di rete virtuale>Aggiungi.

    Screenshot della zona DNS privata che mostra un collegamento di rete virtuale per l'account di archiviazione.

  2. Compila i campi e seleziona la rete virtuale del cluster AKS 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 del riquadro Aggiungi collegamento alla rete virtuale, utilizzato per selezionare una rete virtuale di AKS.

  3. Seleziona OK.

Dopo aver aggiunto il collegamento alla rete virtuale, l'FQDN si risolve tramite un indirizzo IP privato e l'operazione di montaggio riesce. Vedere lo screenshot seguente per un esempio:

Screenshot dell'output di nslookup in cui il nome di dominio completo (FQDN) dell'account di archiviazione viene risolto in un indirizzo IP privato.

Causa 4: L'account di archiviazione richiede la crittografia che il client non supporta

Le Impostazioni di sicurezza di File di Azure contengono diverse opzioni per controllare le impostazioni di sicurezza e crittografia negli account di archiviazione. La limitazione di metodi e algoritmi consentiti può impedire ai client di connettersi.

L'algoritmo di crittografia SMB supportato dipende dal sistema operativo del nodo e dalla versione del kernel Linux:

  • Le versioni del servizio Azure Kubernetes precedenti alla 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. In queste versioni, il profilo di sicurezza massimo (o un profilo personalizzato che disabilita AES-128-GCM) causa errori di mapping delle condivisioni. Queste versioni di AKS non sono più supportate, quindi aggiorna a una versione ancora supportata.
  • Le versioni del servizio Azure Kubernetes 1.25 e successive sono basate su Ubuntu 22.04 o versione successiva, che usa il kernel Linux 5.15 o una versione successiva 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 Massima compatibilità o Personalizzato che abilita AES-128-GCM. Per altre informazioni, vedere Impostazioni di sicurezza di File di Azure.

Causa 5: il requisito di crittografia minimo per un account di archiviazione non è soddisfatto

Questo problema si verifica quando un account di archiviazione applica un algoritmo di crittografia SMB minimo (ad esempio, solo AES-256-GCM) che il client SMB nel nodo servizio Azure Kubernetes non supporta o non è configurato per l'uso. Se il nodo non riesce a negoziare la crittografia richiesta, l'operazione di montaggio non riesce con l'errore "Autorizzazione negata".

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

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

Se si vuole usare solo la crittografia AES-256-GCM, seguire questa procedura:

Linux

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

cifsConfPath="/etc/modprobe.d/cifs.conf"
echo "$(date) before change ${cifsConfPath}:"
cat ${cifsConfPath}

# Check if 'require_gcm_256' is already present in the configuration file
if ! grep -q "require_gcm_256" "${cifsConfPath}"; then

    # Load the CIFS module
    modprobe cifs

    # Set the parameter at runtime
    echo 1 > /sys/module/cifs/parameters/require_gcm_256

    # Persist the configuration
    echo "options cifs require_gcm_256=1" >> "${cifsConfPath}"

    echo "$(date) after changing ${cifsConfPath}:"
    cat "${cifsConfPath}"
else
    echo "require_gcm_256 is already set in ${cifsConfPath}"
fi

È anche possibile usare un DaemonSet di Kubernetes per applicare AES-256 a ogni nodo. Vedere l'esempio seguente:

support-cifs-aes-256-gcm.yaml

Windows

Usare il comando 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

Note

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

Causa 6: Il profilo di sicurezza viene usato senza l'autenticazione NTLM v2 abilitata

Se si usa il profilo di sicurezza massimo o un profilo di sicurezza personalizzato senza abilitare il meccanismo di autenticazione NTLM v2 , l'operazione di montaggio ha esito negativo con l'errore "Errore di montaggio(13): Autorizzazione negata".

Soluzione: abilitare l'autenticazione NTLM v2 o usare il profilo di "Compatibilità massima"

Per montare correttamente la condivisione in AKS, abilitare il meccanismo di autenticazione NTLM v2 per il profilo di sicurezza Personalizzato o usare il profilo di sicurezza Compatibilità massima.

References

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

  • Last updated on