Condividi tramite

Errori durante il montaggio di una condivisione file di Azure

  • Articolo

Questo articolo fornisce 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 oggetto StatefulSet, in un ambiente del servizio Azure Kubernetes. La distribuzione creerà un pod che monta un oggetto 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, è possibile che venga visualizzato uno degli errori seguenti nell'output del comando, causando 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 sarà 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 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.

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/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, dig o host. Ad esempio:

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

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

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 nella portale di Azure e accedere all'account di archiviazione.

    Screenshot dell'elenco di 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 dell'oggetto statefulset esiste nelle condivisioni file.

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

Soluzione: garantire l'esistenza della condivisione file

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 stia bloccando l'indirizzo IP dell'account di archiviazione, seguire questa procedura:

  1. Nella 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: indirizzo IP di un'istanza associata al nodo 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 potrebbe 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 in modo da inviare il traffico verso Internet.

Per verificare quale tabella di route controlli 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 Gruppo di risorse 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: <indirizzo-account-public-IP>/32
  • Tipo hop successivo:Internet

Questa route invierà tutto il traffico tra il cluster del servizio Azure Kubernetes e l'account di archiviazione attraverso 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 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 abilitato per FIPS (Federal Information Processing Standard), l'operazione di montaggio avrà esito negativo perché FIPS disabilita alcuni moduli di autenticazione, impedendo il montaggio di una condivisione CIFS. Questo comportamento è previsto e non specifico per il 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 parametro --enable-fips-image.

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

Soluzione 2: creare un pod che possa essere pianificato in un nodo abilitato per FIPS

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

  1. Usare il driver CSI di 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

    L'SKU è impostato su Premium_LRS nel file YAML perché l'SKU Premium è necessario per NFS. Per altre informazioni, vedere Provisioning dinamico dei pacchetti.

    A causa dell'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 a 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 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 corrispondono al valore effettivo, l'operazione di montaggio avrà esito negativo con l'errore "Autorizzazione negata".

Possibili cause della mancata corrispondenza

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

  • Se viene eseguita un'operazione "Ruota chiave" a livello di account di archiviazione, le modifiche non si riflettono 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 dell'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, 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. 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, selezionare Segreti di configurazione>e quindi cercare 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 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 di 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 segreto Kubernetes azure-storage-account-<storage-account-name>-secret ha i valori corretti, ricreare i pod. In caso contrario, i 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 in grado di identificare il nodo e l'output.

  2. Passare al cluster del servizio Azure Kubernetes nel portale di Azure, selezionare Gruppo di risorse Infrastruttura proprietà>, accedere al set di scalabilità di macchine virtuali 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 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 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>salva.

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

    Per rendere effettive le modifiche potrebbe essere necessari alcuni istanti. Dopo l'aggiunta della rete virtuale e della subnet, verificare se lo stato del pod cambia da ContainerCreating a Running (In esecuzione).

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

Causa 3: la connettività avviene tramite un 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 all'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 privato ("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 della rete virtuale, seguire questa procedura:

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

    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 le 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 aver aggiunto il collegamento alla rete virtuale, il nome di dominio completo sarà risolto tramite un indirizzo IP privato e l'operazione di montaggio avrà esito positivo. Vedere lo screenshot seguente per un esempio:

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

Causa 4: l'account di archiviazione è impostato per richiedere una 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.

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. Il profilo Massima sicurezza o Personalizzato che disabilita AES-128-GCM causeranno errori di mapping delle condivisioni.

Le versioni del servizio Azure Kubernetes 1.25 e successive 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 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

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

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

Se si vuole usare solo la crittografia AES-256-GCM, eseguire le operazioni seguenti:

Linux

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

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

Finestre

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

Quando si usa il profilo di sicurezza massimo o un profilo di sicurezza personalizzato senza il meccanismo di autenticazione NTLM v2 abilitato, l'operazione di montaggio avrà 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 montarlo correttamente nel servizio Azure Kubernetes, è necessario abilitare il meccanismo di autenticazione NTLM v2 per il profilo di sicurezza personalizzato o usare il profilo di sicurezza di compatibilità massima.

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.