Errori durante il montaggio di una condivisione file di Azure
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:
- Errore di montaggio (2): No such file or directory (Causa: il file o la directory non esiste)
- Errore di montaggio (13): Autorizzazione negata
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)
- Causa 1: la condivisione file non esiste
- Causa 2: Il gruppo di sicurezza di rete blocca il traffico tra il servizio Azure Kubernetes e l'account di archiviazione
- Causa 3: l'appliance virtuale blocca il traffico tra il servizio Azure Kubernetes e l'account di archiviazione
- Causa 4: viene usato il pool di nodi abilitato per FIPS
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:
Cercare gli account di archiviazione nella portale di Azure e accedere all'account di archiviazione.
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.
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:
Nella portale di Azure passare a Network Watcher e selezionare Diagnostica NSG.
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
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:
- Passare al cluster del servizio Azure Kubernetes nel portale di Azure e selezionare Gruppo di risorse Infrastruttura proprietà>.
- 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.
- 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:
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.
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
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:
- Causa 1: il segreto Kubernetes non fa riferimento al nome o alla chiave dell'account di archiviazione corretto
- Causa 2: la rete virtuale e la subnet del servizio Azure Kubernetes non sono consentite per l'account di archiviazione
- Causa 3: la connettività avviene tramite un collegamento privato, ma i nodi e l'endpoint privato si trovano in reti virtuali diverse
- Causa 4: l'account di archiviazione è impostato per richiedere una crittografia che il client non supporta
- Causa 5: il requisito di crittografia minimo per un account di archiviazione non è soddisfatto
- Causa 6: Il profilo di sicurezza viene usato senza l'autenticazione NTLM v2 abilitata
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:
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.
Passare al cluster del servizio Azure Kubernetes, selezionare Segreti di configurazione>e quindi cercare e accedere al segreto associato.
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.
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:
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>
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
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
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:
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.
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.
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.
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).
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.
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".
Soluzione: creare un collegamento di rete virtuale per la rete virtuale del cluster del servizio Azure Kubernetes nella zona DNS privata
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.
Per creare il collegamento della rete virtuale, seguire questa procedura:
Accedere alla zona DNS privato e selezionare Collegamenti>di rete virtuale Aggiungi.
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.
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:
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:
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.