Delen via

Fouten bij het koppelen van een Azure-bestandsshare

  • Artikel

Dit artikel bevat mogelijke oorzaken en oplossingen voor fouten waardoor het koppelen van een Azure-bestandsshare mislukt.

Symptomen

U implementeert een Kubernetes-resource, zoals een implementatie of een StatefulSet, in een AKS-omgeving (Azure Kubernetes Service). Tijdens de implementatie wordt een pod gemaakt waarmee een PersistentVolumeClaim (PVC) wordt gekoppeld die verwijst naar een Azure-bestandsshare.

De pod houdt echter de status ContainerCreating. Wanneer u de kubectl describe pods opdracht uitvoert, ziet u mogelijk een van de volgende fouten in de uitvoer van de opdracht, waardoor de koppelingsbewerking mislukt:

Raadpleeg de volgende uitvoer als voorbeeld:

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)

Notitie

  • Als het opslagaccount openbaar toegankelijk is, wordt de hostnaam die in de uitvoer wordt weergegeven, opslagaccount-name.file.core.windows.net>.<
  • Als het opslagaccount privé is geconfigureerd met een privékoppeling, eindpunt of DNS-zone, is de hostnaam storage-account-name.privatelink.file.core.windows.net>.<

Voordat u problemen gaat oplossen

Identificeer op basis van het bericht in de uitvoer, zoals weergegeven in het volgende voorbeeld, het opslagaccount en de bestandsshare. De waarden worden gebruikt in latere probleemoplossingsstappen.

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

Zie de volgende secties voor mogelijke oorzaken en oplossingen.

Fout bij koppelen (2): Een dergelijk(e) bestand of map bestaat niet

Deze fout geeft aan dat er geen verbinding is tussen het AKS-cluster en het opslagaccount.

Eerste probleemoplossing

Azure File is afhankelijk van het SMB-protocol (poort 445). Zorg ervoor dat poort 445 en/of het IP-adres van het opslagaccount niet worden geblokkeerd.

Om het IP-adres van het opslagaccount te controleren, voert u een DNS-opdracht (Domain Name System) uit, zoals nslookup, dig of host. Bijvoorbeeld:

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

Om te controleren of er verbinding is tussen het AKS-cluster en het opslagaccount, gaat u naar het knooppunt of de pod en voert u de volgende opdracht nc of telnet uit:

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

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

Mogelijke oorzaken voor koppelingsfout (2)

Notitie

  • Oorzaak 1, 2 en 4 zijn van toepassing op scenario's met openbare en privéopslagaccounts.
  • Oorzaak 3 is alleen van toepassing op het openbare scenario.

Oorzaak 1: bestandsshare bestaat niet

Voer de volgende stappen uit om te controleren of de bestandsshare bestaat:

  1. Zoek opslagaccounts in Azure Portal en open uw opslagaccount.

    Schermopname van de lijst met opslagaccounts in Azure Portal.

  2. Selecteer bestandsshares onder Gegevensopslag in het opslagaccount en controleer of de bijbehorende PersistentVolumeClaim in het yaml-bestand van de pod, implementatie of statefulset bestaat in bestandsshares.

    Schermopname van het selecteren van bestandsshares in het opslagaccount.

Oplossing: zorg ervoor dat de bestandsshare bestaat

U kunt dit probleem oplossen door ervoor te zorgen dat de bestandsshare die is gekoppeld aan de PV/PVC bestaat.

Oorzaak 2: netwerkbeveiligingsgroep blokkeert verkeer tussen AKS en het opslagaccount

Controleer de uitvoer van de nc of telnet opdracht die wordt vermeld in de sectie Eerste probleemoplossing . Als er een time-out wordt weergegeven, controleert u de netwerkbeveiligingsgroep (NSG) en of het IP-adres van het opslagaccount niet is geblokkeerd.

Voer de volgende stappen uit om te controleren of de NSG het IP-adres van het opslagaccount blokkeert:

  1. Ga in Azure Portal naar Network Watcher en selecteer NSG diagnostic.

  2. Vul de velden in met de volgende waarden:

    • Protocol: Elke
    • Richting: Uitgaand
    • Brontype: IPv4-adres/CIDR
    • IPv4-adres/CIDR: het IP-adres van een exemplaar dat is gekoppeld aan het AKS-knooppunt
    • Doel-IP-adres: het IP-adres van het opslagaccount
    • Doelpoort: 445

  3. Selecteer de knop Controleren en controleer de verkeersstatus .

De verkeersstatus kan worden toegestaan of geweigerd. De status Geweigerd betekent dat de NSG het verkeer tussen het AKS-cluster en het opslagaccount blokkeert. Als de status wordt geweigerd, wordt de naam van de NSG weergegeven.

Oplossing: sta connectiviteit tussen AKS en het opslagaccount toe

U kunt dit probleem oplossen door dienovereenkomstig wijzigingen uit te voeren op NSG-niveau om de connectiviteit tussen het AKS-cluster en het opslagaccount op poort 445 toe te staan.

Oorzaak 3: virtueel apparaat blokkeert verkeer tussen AKS en het opslagaccount

Als u een virtueel apparaat (meestal een firewall) gebruikt om uitgaand verkeer van het AKS-cluster te beheren (op het virtuele apparaat is bijvoorbeeld een routetabel toegepast op het subnet van het AKS-cluster en de routetabel bevat routes die verkeer naar het virtuele apparaat verzenden), kan het virtuele apparaat verkeer tussen het AKS-cluster en het opslagaccount blokkeren.

Als u het probleem wilt isoleren, voegt u een route toe in de routetabel voor het IP-adres van het opslagaccount om het verkeer naar het internet te verzenden.

Voer deze stappen uit om te controleren welke routetabel het verkeer van het AKS-cluster beheert:

  1. Ga naar het AKS-cluster in Azure Portal en selecteer de resourcegroep Eigenschappeninfrastructuur>.
  2. Open de virtuele-machineschaalset (VMSS) of een VM in een beschikbaarheidsset als u een dergelijk type VM-set gebruikt.
  3. Selecteer Subnetten voor virtueel netwerk/subnet>en identificeer het subnet van het AKS-cluster. Aan de rechterkant ziet u de routetabel.

Als u de route wilt toevoegen aan de routetabel, volgt u de stappen in Een route maken en vult u de volgende velden in:

  • Adresvoorvoegsel: <het openbare IP-adres> van het opslagaccount/32
  • Volgend hoptype:Internet

Deze route verstuurt al het verkeer tussen het AKS-cluster en het opslagaccount via het openbare internet.

Nadat u de route hebt toegevoegd, test u de connectiviteit met behulp van de opdracht nc of telnet en voert u de koppelingsbewerking opnieuw uit.

Oplossing: zorg ervoor dat het virtuele apparaat verkeer toestaat tussen AKS en het opslagaccount

Als de koppelingsbewerking is geslaagd, raden we u aan uw netwerkteam te raadplegen om ervoor te zorgen dat het virtuele apparaat verkeer kan toestaan tussen het AKS-cluster en het opslagaccount op poort 445.

Oorzaak 4: ingeschakelde FIPS-knooppuntpool wordt gebruikt

Als u een ingeschakelde FIPS-knooppuntpool (Federal Information Processing Standard) gebruikt, mislukt de koppelingsbewerking omdat de FIPS bepaalde verificatiemodules uitschakelt, waardoor het koppelen van een CIFS-share niet mogelijk is. Dit gedrag is verwacht en niet specifiek voor AKS.

Gebruik een van de volgende oplossingen om het probleem op te lossen:

Oplossing 1: plan pods op knooppunten in een niet-FIPS-knooppuntpool

FIPS is standaard uitgeschakeld voor AKS-knooppuntpools en kan alleen worden ingeschakeld tijdens het maken van de knooppuntpool met behulp van de parameter --enable-fips-image.

U kunt de fout oplossen door de pods op knooppunten in een niet-FIPS-knooppuntpool te plannen.

Oplossing 2: maak een pod die kan worden gepland op een ingeschakeld FIPS-knooppunt

Volg deze volgende stappen om een pod te maken die kan worden gepland op een FIPS-knooppunt:

  1. Gebruik het Azure File CSI-stuurprogramma om een aangepaste StorageClass te maken die het NFS-protocol gebruikt.

    Raadpleeg het volgende YAML-bestand als voorbeeld:

    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

    De SKU is ingesteld op Premium_LRS in het YAML-bestand, omdat een premium-SKU vereist is voor NFS. Zie Dynamische inrichting voor meer informatie.

    Vanwege de premium-SKU is de minimale grootte van de bestandsshare 100 GB. Zie Een opslagklasse maken voor meer informatie.

  2. Maak een PVC dat verwijst naar de aangepaste StorageClass azurefile-sc-fips.

    Raadpleeg het volgende YAML-bestand als voorbeeld:

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

  3. Maak een pod die de PVC azurefile-pvc-fips koppelt.

    Raadpleeg het volgende YAML-bestand als voorbeeld:

    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

Fout bij koppelen (13): Machtiging is geweigerd

Dit zijn de mogelijke oorzaken voor deze fout:

Notitie

  • Oorzaak 1 is van toepassing op openbare en privéscenario's.
  • Oorzaak 2 is alleen van toepassing op het openbare scenario.
  • Oorzaak 3 is alleen van toepassing op het privéscenario.
  • Oorzaak 4 is van toepassing op openbare en privéscenario's.
  • Oorzaak 5 is van toepassing op openbare en privéscenario's.
  • Oorzaak 6 is van toepassing op openbare en privéscenario's.

Oorzaak 1: Kubernetes-geheim verwijst niet naar de juiste naam of sleutel van het opslagaccount

Als de bestandsshare dynamisch wordt gemaakt, wordt automatisch een Kubernetes-geheime resource gemaakt met de naam 'azure-storage-account-account-name-secret><'.

Als de bestandsshare handmatig wordt gemaakt, moet de Kubernetes-geheimresource handmatig worden gemaakt.

Ongeacht de methode voor het maken, als de naam van het opslagaccount of de sleutel waarnaar wordt verwezen in het Kubernetes-geheim niet overeenkomt met de werkelijke waarde, mislukt de koppelingsbewerking met de fout "Machtiging geweigerd".

Mogelijke oorzaken voor de onjuiste overeenkomst

  • Als het Kubernetes-geheim handmatig wordt gemaakt, kan er een typefout optreden tijdens het maken.

  • Als een bewerking "Sleutel draaien" wordt uitgevoerd op het niveau van het opslagaccount, worden de wijzigingen niet weergegeven op het Kubernetes-geheimniveau. Dit leidt tot een niet-overeenkomende sleutelwaarde op het niveau van het opslagaccount en de waarde op het niveau van het Kubernetes-geheim.

    Als een bewerking "Sleutel draaien" plaatsvindt, wordt een bewerking met de naam "Opslagaccountsleutels opnieuw genereren" weergegeven in het activiteitenlogboek van het opslagaccount. Houd rekening met de retentieperiode van 90 dagen voor het activiteitenlogboek.

De onjuiste overeenkomst controleren

Volg deze stappen om de onjuiste overeenkomst te verifiëren:

  1. Zoek naar en open het opslagaccount in Azure Portal. Selecteer Toegangssleutels>Weergeven sleutels in het opslagaccount. U ziet de naam van het opslagaccount en de bijbehorende sleutels.

    Schermopname van de naam en sleutels van het opslagaccount.

  2. Ga naar het AKS-cluster, selecteer Configuratiegeheimen> en zoek en open het bijbehorende geheim.

    Schermopname van het zoeken en selecteren van een opslagaccount.

  3. Selecteer Weergeven (het oogpictogram) en vergelijk de waarden van de naam van het opslagaccount en de bijbehorende sleutel met de waarden in stap 1.

    Schermopname van de naam en sleutel van het opslagaccount in een geheim.

    Voordat u Weergeven selecteert, worden de waarden van de naam van het opslagaccount en de bijbehorende sleutel gecodeerd in base64-tekenreeksen. Nadat u Weergeven hebt geselecteerd, worden de waarden gedecodeerd.

Als u geen toegang hebt tot het AKS-cluster in Azure Portal, voert u stap 2 uit op kubectl-niveau:

  1. Haal het YAML-bestand van het Kubernetes-geheim op en voer vervolgens de volgende opdracht uit om de waarden van de naam van het opslagaccount en de sleutel op te halen uit de uitvoer:

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

  2. Gebruik de opdracht echo om de waarden van de naam van het opslagaccount en de sleutel te decoderen en deze te vergelijken met de waarden op het niveau van het opslagaccount.

    Hier volgt een voorbeeld van het decoderen van de naam van het opslagaccount:

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

    Schermopname van de opdracht waarmee de naam van het opslagaccount wordt ontsleuteld.

Oplossing: pas het Kubernetes-geheim aan en maak de pods opnieuw

Als de waarde van de naam of sleutel van het opslagaccount in het Kubernetes-geheim niet overeenkomt met de waarde in Toegangssleutels in het opslagaccount, past u het Kubernetes-geheim aan op het kubernetes-geheimniveau door de volgende opdracht uit te voeren:

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

De waarde van de naam van het opslagaccount of de sleutel die is toegevoegd in de configuratie van het Kubernetes-geheim, moet een base64-gecodeerde waarde zijn. Gebruik de opdracht echo om de gecodeerde waarde op te halen.

Hier volgt een voorbeeld voor het encoderen van de naam van het opslagaccount:

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

Zie Geheimen beheren met kubectl voor meer informatie.

Nadat het Kubernetes-geheim azure-storage-account-<storage-account-name>-secret de juiste waarden heeft, maakt u de pods opnieuw. Anders blijven deze pods de oude waarden gebruiken die niet meer geldig zijn.

Oorzaak 2: het VNET en subnet van AKS zijn niet toegestaan voor het opslagaccount

Als het netwerk van het opslagaccount is beperkt tot geselecteerde netwerken, maar het VNET en subnet van het AKS-cluster niet zijn toegevoegd aan geselecteerde netwerken, mislukt de koppelingsbewerking met de fout "Machtiging geweigerd".

Oplossing: sta het VNET en subnet van AKS toe voor het opslagaccount

  1. Identificeer het knooppunt dat als host fungeert voor de defecte pod door de volgende opdracht uit te voeren:

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

    Controleer het knooppunt in de uitvoer van de opdracht:

    Schermopname van de opdracht die het identiteitsknooppunt en de uitvoer kan knooppunten.

  2. Ga naar het AKS-cluster in Azure Portal, selecteer de resourcegroep Eigenschappeninfrastructuur>, open de VMSS die aan het knooppunt zijn gekoppeld en controleer vervolgens het virtuele netwerk/subnet om het VNET en subnet te identificeren.

    Schermopname van de waarde van het virtuele netwerk/subnet.

  3. Zoek en open het opslagaccount in Azure Portal. Selecteer Netwerken. Als Toegang toestaan is ingesteld op Geselecteerde netwerken, controleert u of het VNET en het subnet van het AKS-cluster zijn toegevoegd.

    Schermopname van een lege lijst met geselecteerde netwerken.

    Als het VNET en het subnet van het AKS-cluster niet worden toegevoegd, selecteert u Bestaand virtueel netwerk toevoegen. Typ op de pagina Netwerken toevoegen het VNET en subnet van het AKS-cluster en selecteer Opslaan toevoegen>.

    Schermopname van het toevoegen van netwerken aan het opslagaccount.

    Het kan even duren voordat de wijzigingen zijn doorgevoerd. Nadat het VNET en het subnet zijn toegevoegd, controleert u of de podstatus verandert van ContainerCreating in Running.

    Schermopname van de uitvoer van de opdracht met de huidige podstatus.

Oorzaak 3: de connectiviteit verloopt via een privékoppeling, maar de knooppunten en het privé-eindpunt bevinden zich in verschillende VNET's

Wanneer het AKS-cluster en het opslagaccount zijn verbonden via een privékoppeling, wordt een goedgekeurde privé-eindpuntverbinding gebruikt.

Schermopname van een privé-eindpuntverbinding.

Als in dit scenario het privé-eindpunt en het AKS-knooppunt zich in hetzelfde VNET bevinden, kunt u een Azure-bestandsshare koppelen.

Als het privé-eindpunt en uw AKS-cluster zich in verschillende VNET's bevinden, mislukt de koppelingsbewerking met de fout "Machtiging geweigerd".

Ga naar het knooppunt en controleer of de FQDN (Fully Qualified Domain Name) wordt omgezet via een openbaar of privé-IP-adres. Voer hiervoor de volgende opdracht uit:

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

Als de FQDN wordt omgezet via een openbaar IP-adres (zie de volgende schermopname), maakt u een virtuele netwerkkoppeling voor het VNET van het AKS-cluster op het niveau van de privé-DNS-zone ("privatelink.file.core.windows.net"). Houd er rekening mee dat er al automatisch een virtuele netwerkkoppeling wordt gemaakt voor het VNET van het privé-eindpunt van het opslagaccount.

Schermopname van de FQDN wordt omgezet door een openbaar IP-adres.

Volg deze stappen om de virtuele netwerkkoppeling te maken:

  1. Open de Privé-DNS zone en selecteer Virtuele netwerkkoppelingen>toevoegen.

    Schermopname van een koppeling naar een virtueel netwerk dat is toegevoegd aan het opslagaccount.

  2. Vul de velden in en selecteer het VNET van het AKS-cluster voor virtuele netwerken. Zie de sectie Oplossing: sta het VNET en subnet van AKS toe voor het opslagaccount voor het identificeren van het VNET van het AKS-cluster.

    Schermopname die laat zien hoe u een koppeling naar een virtueel netwerk toevoegt.

  3. Selecteer OK.

Nadat de virtuele netwerkkoppeling is toegevoegd, moet de FQDN worden omgezet via een privé-IP-adres en moet de koppelingsbewerking lukken. Zie de volgende schermopname voor een voorbeeld:

Schermopname van het opgeloste privé-IP-adres.

Oorzaak 4: het opslagaccount is ingesteld op versleuteling die niet door de client wordt ondersteund

Azure Files-beveiligingsinstellingen bevat een aantal opties voor het beheren van de beveiligings- en versleutelingsinstellingen voor opslagaccounts. Het beperken van toegestane methoden en algoritmen kan voorkomen dat clients verbinding maken.

AKS-versies ouder dan 1.25 zijn gebaseerd op Ubuntu 18.04 LTS, dat de Linux 5.4-kernel gebruikt en alleen de versleutelingsalgoritmen AES-128-CCM en AES-128-GCM ondersteunt. Het profiel Maximale beveiliging of een profiel Aangepast waarmee AES-128-GCM wordt uitgeschakeld, veroorzaakt fouten bij het toewijzen van shares.

AKS-versies 1.25 en latere versies zijn gebaseerd op Ubuntu 22.04, dat de Linux 5.15-kernel gebruikt en ondersteuning biedt voor AES-256-GCM.

Oplossing: sta het gebruik van het versleutelingsalgoritme AES-128-GCM toe

Schakel het algoritme AES-128-GCM in met behulp van het profiel Maximale compatibiliteit of een profiel Aangepast waarmee AES-128-GCM wordt ingeschakeld. Zie Azure Files-veveiligingsinstellingen voor meer informatie.

Oorzaak 5: Aan de minimale versleutelingsvereiste voor een opslagaccount wordt niet voldaan

Oplossing: AES-128-GCM-versleutelingsalgoritmen inschakelen voor alle opslagaccounts

Als u een bestandsshare wilt koppelen of openen, moet het AES-128-GCM-versleutelingsalgoritmen zijn ingeschakeld voor alle opslagaccounts.

Als u alleen de AES-256-GCM-versleuteling wilt gebruiken, gaat u als volgt te werk:

Linux

Gebruik het volgende script om te controleren of de client AES-256-GCM ondersteunt en dit alleen afdwingen als dit het geval is:

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

U kunt ook een Kubernetes DaemonSet gebruiken om AES-256 af te dwingen op elk knooppunt. Zie het volgende voorbeeld:

support-cifs-aes-256-gcm.yaml

Windows

Gebruik de PowerShell-opdracht Set-SmbClientConfiguration om de versleutelingscoderingen op te geven die door de SMB-client worden gebruikt en het gewenste versleutelingstype zonder bevestiging van de gebruiker:

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

Notitie

De EncryptionCiphers parameter is beschikbaar vanaf de cumulatieve update van 2022-06 voor Windows Server versie 21H2 voor x64-systemen (KB5014665) en de cumulatieve update voor Windows 11, versie 22H2 (KB5014668).

Oorzaak 6: Beveiligingsprofiel wordt gebruikt zonder dat NTLM v2-verificatie is ingeschakeld

Wanneer u het maximale beveiligingsprofiel of een aangepast beveiligingsprofiel gebruikt zonder het verificatiemechanisme NTLM v2 ingeschakeld, mislukt de koppelingsbewerking met de fout 'Koppelingsfout(13): Machtiging geweigerd'.

Oplossing: Schakel de NTLM v2-verificatie in of gebruik het profiel Maximale compatibiliteit

Als u deze correct wilt koppelen in AKS, moet u het NTLM v2-verificatiemechanisme voor het aangepaste beveiligingsprofiel inschakelen of het beveiligingsprofiel voor maximale compatibiliteit gebruiken.

Meer informatie

Als u andere koppelingsfouten ondervindt, raadpleegt u Problemen met Azure Files in Linux oplossen.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.