Fel vid montering av en Azure-filresurs

Den här artikeln innehåller möjliga orsaker och lösningar på fel som gör att monteringen av en Azure-filresurs misslyckas.

Symptom

Du distribuerar en Kubernetes-resurs, till exempel en distribution eller en StatefulSet, i en Azure Kubernetes Service -miljö (AKS). Distributionen skapar en podd som monterar en PersistentVolumeClaim (PVC) som refererar till en Azure-filresurs.

Podden finns dock kvar i statusen ContainerCreating . När du kör kubectl describe pods kommandot kan du se något av följande fel i kommandoutdata, vilket gör att monteringsåtgärden misslyckas:

• Monteringsfel(2): Ingen sådan fil eller katalog
• Monteringsfel(13): Behörighet nekad

Se följande utdata som ett exempel:

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)

Obs!

• Om lagringskontot är offentligt tillgängligt kommer värdnamnet som visas i utdata att vara <storage-account-name.file.core.windows.net>.
• Om lagringskontot konfigureras privat med en privat länk, slutpunkt eller DNS-zon blir <värdnamnet storage-account-name.privatelink.file.core.windows.net>.

Innan du felsöker

Enligt meddelandet i utdata, som du ser i följande exempel, identifierar du lagringskontot och filresursen – värdena används i senare felsökningssteg.

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

I följande avsnitt finns möjliga orsaker och lösningar.

Monteringsfel(2): Ingen sådan fil eller katalog

Det här felet anger att det inte finns någon anslutning mellan AKS-klustret och lagringskontot.

Inledande felsökning

Azure File förlitar sig på SMB-protokoll (port 445). Kontrollera att port 445 och/eller IP-adressen för lagringskontot inte är blockerad.

Om du vill kontrollera IP-adressen för lagringskontot kör du ett DNS-kommando (Domain Name System) som nslookup, digeller host. Till exempel:

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

Kontrollera om det finns en anslutning mellan AKS-klustret och lagringskontot genom att gå in i noden eller podden och köra följande nc eller telnet kommando:

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

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

Möjliga orsaker till monteringsfel(2)

• Orsak 1: Filresursen finns inte
• Orsak 2: NSG blockerar trafik mellan AKS och lagringskontot
• Orsak 3: Virtuell installation blockerar trafik mellan AKS och lagringskontot
• Orsak 4: FIPS-aktiverad nodpool används

Obs!

• Orsak 1, 2 och 4 gäller för scenarier med offentliga och privata lagringskonton.
• Orsak 3 gäller endast för det offentliga scenariot.

Orsak 1: Filresursen finns inte

Följ dessa steg för att kontrollera om filresursen finns:

1. Search Lagringskonton i Azure Portal och få åtkomst till ditt lagringskonto.

   

2. Välj Filresurser under Datalagring i lagringskontot och kontrollera om den associerade PersistentVolumeClaim i yaml-filen för podden, distributionen eller tillståndskänsliga enheten finns i Filresurser.

   

Lösning: Kontrollera att filresursen finns

Lös problemet genom att kontrollera att filresursen som är associerad med PV/PVC finns.

Orsak 2: Nätverkssäkerhetsgruppen blockerar trafik mellan AKS och lagringskontot

Kontrollera utdata nc för kommandot eller telnet som nämns i avsnittet Inledande felsökning . Om en timeout visas kontrollerar du nätverkssäkerhetsgruppen (NSG) och kontrollerar att IP-adressen för lagringskontot inte är blockerad.

Följ dessa steg för att kontrollera om NSG blockerar IP-adressen för lagringskontot:

1. I Azure Portal går du till Network Watcher och väljer NSG-diagnostik.

2. Fyll i fälten med hjälp av följande värden:

   • Protokoll: Alla
   • Riktning: Utgående
   • Källtyp: IPv4-adress/CIDR
   • IPv4-adress/CIDR: IP-adressen för en instans som är associerad med AKS-noden
   • Mål-IP-adress: IP-adressen för lagringskontot
   • Målport: 445

3. Välj knappen Kontrollera och kontrollera trafikstatusen .

Trafikstatusen kan vara Tillåten eller Nekad. Statusen Nekad innebär att NSG blockerar trafiken mellan AKS-klustret och lagringskontot. Om statusen är Nekad visas NSG-namnet.

Lösning: Tillåt anslutning mellan AKS och lagringskonto

Lös problemet genom att utföra ändringar på NSG-nivå för att tillåta anslutningen mellan AKS-klustret och lagringskontot på port 445.

Orsak 3: Virtuell installation blockerar trafik mellan AKS och lagringskontot

Om du använder en virtuell installation (vanligtvis en brandvägg) för att styra utgående trafik i AKS-klustret (till exempel den virtuella installationen har en routningstabell som används i AKS-klustrets undernät och routningstabellen har vägar som skickar trafik mot den virtuella installationen), kan den virtuella installationen blockera trafik mellan AKS-klustret och lagringskontot.

Om du vill isolera problemet lägger du till en väg i routningstabellen för lagringskontots IP-adress för att skicka trafiken till Internet.

Följ dessa steg för att bekräfta vilken routningstabell som styr trafiken i AKS-klustret:

1. Gå till AKS-klustret i Azure Portal och väljresursgruppenEgenskaper> infrastruktur.
2. Få åtkomst till vm-skalningsuppsättningen (VMSS) eller en virtuell dator i en tillgänglighetsuppsättning om du använder en sådan typ av VM-uppsättning.
3. VäljUndernät för virtuellt nätverk/undernät> och identifiera undernätet för AKS-klustret. Till höger ser du routningstabellen.

Om du vill lägga till vägen i routningstabellen följer du stegen i Skapa en väg och fyller i följande fält:

• Adressprefix: <storage-account's-public-IP>/32
• Nästa hopptyp:Internet

Den här vägen skickar all trafik mellan AKS-klustret och lagringskontot via det offentliga Internet.

När du har lagt till vägen testar du anslutningen med hjälp nc av kommandot eller telnet och utför monteringsåtgärden igen.

Lösning: Se till att den virtuella installationen tillåter trafik mellan AKS och lagringskontot

Om monteringen lyckas rekommenderar vi att du kontaktar nätverksteamet för att se till att den virtuella installationen kan tillåta trafik mellan AKS-klustret och lagringskontot på port 445.

Orsak 4: FIPS-aktiverad nodpool används

Om du använder en FIPS-aktiverad nodpool (Federal Information Processing Standard) misslyckas monteringsåtgärden eftersom FIPS inaktiverar vissa autentiseringsmoduler, vilket förhindrar montering av en CIFS-resurs. Det här beteendet är förväntat och inte specifikt för AKS.

Lös problemet genom att använda någon av följande lösningar:

Lösning 1: Schemalägga poddar på noder i en nodpool som inte är EN FIPS

FIPS är inaktiverat som standard i AKS-nodpooler och kan endast aktiveras när nodpoolen skapas med hjälp av parametern --enable-fips-image .

Du kan lösa felet genom att schemalägga poddarna på noder i en nodpool som inte är en FIPS-nod.

Lösning 2: Skapa en podd som kan schemaläggas på en FIPS-aktiverad nod

Så här skapar du en podd som kan schemaläggas på en FIPS-aktiverad nod:

1. Använd Azure File CSI-drivrutinen för att skapa en anpassad StorageClass som använder NFS-protokoll.

   Se följande YAML-fil som ett exempel:

   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 
   

   SKU:n är inställd på Premium_LRS i YAML-filen eftersom Premium SKU krävs för NFS. Mer information finns i Dynamisk etablering.

   På grund av Premium SKU är den minsta storleken på filresursen 100 GB. Mer information finns i Skapa en lagringsklass.

2. Skapa en PVC som refererar till den anpassade StorageClass azurefile-sc-fips.

   Se följande YAML-fil som ett exempel:

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

3. Skapa en podd som monterar PVC azurefile-pvc-fips.

   Se följande YAML-fil som ett exempel:

   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 
   

Monteringsfel(13): Behörighet nekad

Här är möjliga orsaker till det här felet:

• Orsak 1: Kubernetes-hemligheten refererar inte till rätt lagringskontonamn eller nyckel
• Orsak 2: AKS VNET och undernät tillåts inte för lagringskontot
• Orsak 3: Anslutningen sker via en privat länk, men noderna och den privata slutpunkten finns i olika virtuella nätverk
• Orsak 4: Lagringskontot är inställt på att kräva kryptering som klienten inte stöder
• Orsak 5: Minsta krypteringskrav för ett lagringskonto uppfylls inte

Obs!

• Orsak 1 gäller för offentliga och privata scenarier.
• Orsak 2 gäller endast för det offentliga scenariot.
• Orsak 3 gäller endast för det privata scenariot.
• Orsak 4 gäller för offentliga och privata scenarier.
• Orsak 5 gäller för offentliga och privata scenarier.

Orsak 1: Kubernetes-hemligheten refererar inte till rätt namn eller nyckel för lagringskontot

Om filresursen skapas dynamiskt skapas en Hemlig Kubernetes-resurs automatiskt med namnet "azure-storage-account-storage-account-name-secret<>".

Om filresursen skapas manuellt bör Kubernetes hemliga resurs skapas manuellt.

Oavsett skapandemetoden misslyckas monteringsåtgärden med felet "Nekad behörighet" om namnet på lagringskontot eller nyckeln som refereras i Kubernetes-hemligheten matchar det faktiska värdet.

Möjliga orsaker till matchningsfel

• Om Kubernetes-hemligheten skapas manuellt kan ett stavfel inträffa när den skapas.

• Om en "Rotera nyckel"-åtgärd utförs på lagringskontonivå återspeglas inte ändringarna på Kubernetes-hemlighetsnivån. Detta leder till ett matchningsfel mellan nyckelvärdet på lagringskontonivå och värdet på Kubernetes-hemlighetsnivån.

  Om åtgärden "Rotera nyckel" inträffar visas en åtgärd med namnet "Återskapa lagringskontonycklar" i aktivitetsloggen för lagringskontot. Tänk på kvarhållningsperioden på 90 dagar för aktivitetsloggen.

Verifiera matchningsfel

Följ dessa steg för att kontrollera matchningsfelet:

1. Search och komma åt lagringskontot i Azure Portal. Välj Åtkomstnycklar>Visa nycklar i lagringskontot. Du ser lagringskontots namn och associerade nycklar.

   

2. Gå till AKS-klustret, väljKonfigurationshemligheter> och sök och få åtkomst till den associerade hemligheten.

   

3. Välj Visa (ögonikonen) och jämför värdena för lagringskontots namn och tillhörande nyckel med värdena i steg 1.

   

   Innan du väljer Visa kodas värdena för lagringskontots namn och associerade nyckel i base64-strängar. När du har valt Visa avkodas värdena.

Om du inte har åtkomst till AKS-klustret i Azure Portal utför du steg 2 på kubectl-nivå:

1. Hämta YAML-filen för Kubernetes-hemligheten och kör sedan följande kommando för att hämta värdena för lagringskontots namn och nyckeln från utdata:

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

2. echo Använd kommandot för att avkoda värdena för lagringskontots namn och nyckel och jämföra dem med värdena på lagringskontonivå.

   Här är ett exempel för att avkoda lagringskontots namn:

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

   

Lösning: Justera Kubernetes-hemligheten och återskapa poddarna

Om värdet för lagringskontots namn eller nyckel i Kubernetes-hemligheten inte matchar värdet i Åtkomstnycklar i lagringskontot justerar du Kubernetes-hemligheten på Kubernetes-hemlighetsnivån genom att köra följande kommando:

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

Värdet för lagringskontots namn eller nyckeln som läggs till i Kubernetes-hemlighetskonfigurationen ska vara ett base64-kodat värde. Använd kommandot för echo att hämta det kodade värdet.

Här är ett exempel på hur du kodar lagringskontots namn:

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

Mer information finns i Hantera hemligheter med kubectl.

När Kubernetes-hemligheten azure-storage-account-<storage-account-name>-secret har rätt värden skapar du poddarna igen. Annars fortsätter poddarna att använda de gamla värdena som inte längre är giltiga.

Orsak 2: AKS virtuella nätverk och undernät tillåts inte för lagringskontot

Om lagringskontots nätverk är begränsat till valda nätverk, men det virtuella nätverket och undernätet för AKS-klustret inte läggs till i valda nätverk, misslyckas monteringsåtgärden med felet "Behörighet nekad".

Lösning: Tillåt AKS VNET och undernät för lagringskonto

1. Identifiera noden som är värd för den felaktiga podden genom att köra följande kommando:

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

   Kontrollera noden från kommandoutdata:

   

2. Gå till AKS-klustret i Azure Portal, välj Resursgrupp för egenskapsinfrastruktur>, få åtkomst till VMSS som är associerad med noden och kontrollera sedan Virtuellt nätverk/undernät för att identifiera det virtuella nätverket och undernätet.

   

3. Få åtkomst till lagringskontot i Azure Portal. Välj Nätverk. Om Tillåt åtkomst från är inställt på Valda nätverk kontrollerar du om det virtuella nätverket och undernätet för AKS-klustret har lagts till.

   

   Om det virtuella nätverket och undernätet för AKS-klustret inte läggs till väljer du Lägg till befintligt virtuellt nätverk. På sidan Lägg till nätverk skriver du det virtuella nätverket och undernätet för AKS-klustret och väljer sedan Lägg till>Spara.

   

   Det kan ta en stund innan ändringarna börjar gälla. När det virtuella nätverket och undernätet har lagts till kontrollerar du om poddstatusen ändras från ContainerSkapa till Körs.

   

Orsak 3: Anslutningen sker via privat länk, men noder och privat slutpunkt finns i olika virtuella nätverk

När AKS-klustret och lagringskontot är anslutna via en privat länk används en godkänd privat slutpunktsanslutning.

I det här scenariot kan du montera en Azure-filresurs om den privata slutpunkten och AKS-noden finns i samma virtuella nätverk.

Om den privata slutpunkten och AKS-klustret finns i olika virtuella nätverk misslyckas monteringsåtgärden med felet "Behörighet nekad".

Lösning: Skapa en virtuell nätverkslänk för VNET för AKS-kluster i en privat DNS-zon

Gå in i noden och kontrollera om det fullständigt kvalificerade domännamnet (FQDN) matchas via en offentlig eller privat IP-adress. Det gör du genom att köra följande kommando:

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

Om det fullständiga domännamnet matchas via en offentlig IP-adress (se följande skärmbild) skapar du en virtuell nätverkslänk för det virtuella nätverket för AKS-klustret på nivån för den privata DNS-zonen ("privatelink.file.core.windows.net"). Observera att en virtuell nätverkslänk redan skapas automatiskt för det virtuella nätverket för lagringskontots privata slutpunkt.

Följ dessa steg för att skapa länken för det virtuella nätverket:

1. Öppna Privat DNS-zonen och välj Länkar >för virtuellt nätverkLägg till.

   

2. Fyll i fälten och välj det virtuella nätverket för AKS-klustret för virtuella nätverk. Information om hur du identifierar det virtuella nätverket för AKS-klustret finns i avsnittet Solution: Allow AKS's VNET and subnet for storage account (Lösning: Tillåt AKS:s VNET och undernät för lagringskonto ).

   

3. Välj OK.

När länken för det virtuella nätverket har lagts till bör det fullständiga domännamnet matchas via en privat IP-adress och monteringsåtgärden ska lyckas. Se följande skärmbild för ett exempel:

Orsak 4: Lagringskontot är inställt på att kräva kryptering som klienten inte stöder

Azure Files Säkerhetsinställningar innehåller ett antal alternativ för att styra säkerhets- och krypteringsinställningarna för lagringskonton. Att begränsa tillåtna metoder och algoritmer kan hindra klienter från att ansluta.

AKS-versioner som är tidigare än 1.25 baseras på Ubuntu 18.04 LTS, som använder Linux 5.4-kerneln och endast stöder krypteringsalgoritmerna AES-128-CCM och AES-128-GCM. Den maximala säkerhetsprofilen , eller en anpassad profil som inaktiverar AES-128-GCM, orsakar resursmappningsfel.

AKS version 1.25 och senare versioner baseras på Ubuntu 22.04, som använder Linux 5.15-kerneln och har stöd för AES-256-GCM.

Lösning: Tillåt att AES-128-GCM-krypteringsalgoritmen används

Aktivera AES-128-GCM-algoritmen med hjälp av kompatibilitetsprofilen Maximum eller en anpassad profil som aktiverar AES-128-GCM. Mer information finns i Azure Files Säkerhetsinställningar.

Orsak 5: Minsta krypteringskrav för ett lagringskonto uppfylls inte

Lösning: Aktivera AES-128-GCM-krypteringsalgoritm för alla lagringskonton

För att kunna montera eller komma åt en filresurs bör AES-128-GCM-krypteringsalgoritmen vara aktiverad för alla lagringskonton.

Om du bara vill använda AES-256-GCM-kryptering, vilket är den högsta säkerheten (SMB 3.1.1), gör du följande:

Linux

Använd följande skript för att kontrollera om klienten stöder AES-256-GCM och framtvinga den endast om den gör det:

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

Använd PowerShell-kommandot Set-SmbClientConfiguration för att ange krypterings chiffer som används av SMB-klienten och önskad krypteringstyp utan användarbekräftelse:

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

Obs!

Parametern EncryptionCiphers är tillgänglig från och med den kumulativa uppdateringen 2022-06 för Windows Server version 21H2 för x64-baserade system (KB5014665) och kumulativ uppdatering för Windows 11 version 22H2 (KB5014668).

Mer information

Om du stöter på andra monteringsfel kan du läsa Felsöka Azure Files problem i Linux.

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.