Share via

Fehler beim Pullen von Images aus Azure Container Registry in Azure Kubernetes Service Cluster

  • Artikel

Hinweis

Waren diese Informationen hilfreich? Wir schätzen Ihr Feedback. Bitte verwenden Sie die Schaltfläche Feedback auf dieser Seite, um uns mitzuteilen, wie gut Ihnen dieser Artikel gefallen hat oder wie wir ihn verbessern können.

Wenn Sie Microsoft Azure Container Registry zusammen mit Azure Kubernetes Service (AKS) verwenden, muss ein Authentifizierungsmechanismus eingerichtet werden. Sie können die Integration von AKS in Container Registry mithilfe einiger einfacher Azure CLI- oder Azure PowerShell-Befehle einrichten. Diese Integration weist die AcrPull-Rolle für die Kubelet-Identität zu, die dem AKS-Cluster zugeordnet ist, um Images aus einer Containerregistrierung zu pullen.

In einigen Fällen schlägt der Versuch fehl, Images aus einer Containerregistrierung in einen AKS-Cluster zu pullen. Dieser Artikel enthält Anleitungen zur Problembehandlung der häufigsten Fehler, die beim Pullen von Images aus einer Containerregistrierung in einen AKS-Cluster auftreten.

Bevor Sie beginnen:

In diesem Artikel wird davon ausgegangen, dass Sie über einen vorhandenen AKS-Cluster und eine vorhandene Containerregistrierung verfügen. Sehen Sie sich die folgenden Schnellstarts an:

Außerdem muss die Azure CLI-Version 2.0.59 oder eine höhere Version installiert und konfiguriert sein. Führen Sie az version aus, um die Version zu bestimmen. Informationen zum Installieren oder Aktualisieren finden Sie unter Installieren der Azure CLI.

Symptome und erste Problembehandlung

Der STATUS des Kubernetes-Pods lautet ImagePullBackOff oder ErrImagePull. Um ausführliche Fehlerinformationen zu erhalten, führen Sie den folgenden Befehl aus, und überprüfen Sie Ereignisse in der Ausgabe.

kubectl describe pod <podname> -n <namespace>

Es wird empfohlen, mit der Problembehandlung zu beginnen, indem Sie die Integrität der Containerregistrierung überprüfen und überprüfen, ob über den AKS-Cluster auf die Containerregistrierung zugegriffen werden kann.

Führen Sie den folgenden Befehl aus, um die Integrität der Containerregistrierung zu überprüfen:

az acr check-health --name <myregistry> --ignore-errors --yes

Wenn ein Problem erkannt wird, wird ein Fehlercode und eine Beschreibung bereitgestellt. Weitere Informationen zu den Fehlern und möglichen Lösungen finden Sie unter Fehlerreferenz zur Integritätsprüfung.

Hinweis

Wenn Helm- oder Notarfehler auftreten, bedeutet dies nicht, dass sich ein Problem auf Container Registry oder AKS auswirkt. Es gibt nur an, dass Helm oder Notar nicht installiert ist oder dass die Azure CLI nicht mit der aktuell installierten Version von Helm oder Notar kompatibel ist usw.

Führen Sie den folgenden Befehl az aks check-acr aus, um zu überprüfen, ob über den AKS-Cluster auf die Containerregistrierung zugegriffen werden kann:

az aks check-acr --resource-group <MyResourceGroup> --name <MyManagedCluster> --acr <myacr>.azurecr.io

In den folgenden Abschnitten können Sie die häufigsten Fehler beheben, die in der Ausgabe des kubectl describe pod Befehls unter Ereignisse angezeigt werden.

Ursache 1: Fehler "401 Nicht autorisiert"

Ein AKS-Cluster erfordert eine Identität. Diese Identität kann entweder eine verwaltete Identität oder ein Dienstprinzipal sein. Wenn der AKS-Cluster eine verwaltete Identität verwendet, wird die Kubelet-Identität für die Authentifizierung mit ACR verwendet. Wenn der AKS-Cluster als Identität einen Dienstprinzipal verwendet, wird der Dienstprinzipal selbst für die Authentifizierung mit ACR verwendet. Unabhängig davon, um welche Identität es sich handelt, ist die richtige Autorisierung erforderlich, die zum Pullen eines Images aus einer Containerregistrierung verwendet wird. Andernfalls wird möglicherweise der folgende Fehler "401 Nicht autorisiert" angezeigt:

Fehler beim Pullen des Images "<acrname.azurecr.io/<> repository:tag>": [rpc error: code = Unknown desc = failed to pull and unpack image "<acrname.azurecr.io/<> repository:tag>": failed to resolve reference "<acrname.azurecr.io/>< repository:tag>": failed to authorize: failed to fetch oauth token: unexpected status: 401 Unauthorized

Verschiedene Lösungen können Ihnen helfen, diesen Fehler zu beheben, sofern die folgenden Einschränkungen gelten:

Lösung 1: Stellen Sie sicher, dass die AcrPull-Rollenzuweisung für die Identität erstellt wurde.

Die Integration zwischen AKS und Container Registry erstellt eine AcrPull-Rollenzuweisung auf Containerregistrierungsebene für die Kubelet-Identität des AKS-Clusters. Stellen Sie sicher, dass die Rollenzuweisung erstellt wurde.

Verwenden Sie eine der folgenden Methoden, um zu überprüfen, ob die AcrPull-Rollenzuweisung erstellt wurde:

  • Führen Sie den folgenden Befehl aus:

    az role assignment list --scope /subscriptions/<subscriptionID>/resourceGroups/<resourcegroupname>/providers/Microsoft.ContainerRegistry/registries/<acrname> -o table

  • Überprüfen Sie die Azure-Portal, indem Sie Azure Container Registry>Zugriffssteuerung (IAM)>Rollenzuweisungen auswählen. Weitere Informationen finden Sie unter Auflisten von Azure-Rollenzuweisungen mithilfe der Azure-Portal.

Neben der AcrPull-Rolle können einige integrierte Rollen und benutzerdefinierte Rollen auch die Aktion "Microsoft.ContainerRegistry/registries/pull/read" enthalten. Überprüfen Sie diese Rollen, wenn Sie über eine dieser Rollen verfügen.

Wenn die AcrPull-Rollenzuweisung nicht erstellt wird, erstellen Sie sie, indem Sie die Container Registry-Integration für den AKS-Cluster mit dem folgenden Befehl konfigurieren:

az aks update -n <myAKSCluster> -g <myResourceGroup> --attach-acr <acr-resource-id>

Lösung 2: Sicherstellen, dass der Dienstprinzipal nicht abgelaufen ist

Stellen Sie sicher, dass das Geheimnis des Dienstprinzipals, der dem AKS-Cluster zugeordnet ist, nicht abgelaufen ist. Führen Sie die folgenden Befehle aus, um das Ablaufdatum Ihres Dienstprinzipals zu überprüfen:

SP_ID=$(az aks show --resource-group <myResourceGroup> --name <myAKSCluster> \
    --query servicePrincipalProfile.clientId -o tsv)

az ad sp credential list --id "$SP_ID" --query "[].endDate" -o tsv

Weitere Informationen finden Sie unter Überprüfen des Ablaufdatums Ihres Dienstprinzipals.

Wenn das Geheimnis abgelaufen ist, aktualisieren Sie die Anmeldeinformationen für den AKS-Cluster.

Lösung 3: Stellen Sie sicher, dass die AcrPull-Rolle dem richtigen Dienstprinzipal zugewiesen ist.

In einigen Fällen bezieht sich die Rollenzuweisung der Containerregistrierung weiterhin auf den alten Dienstprinzipal. Beispielsweise, wenn der Dienstprinzipal des AKS-Clusters durch einen neuen ersetzt wird. Führen Sie die folgenden Schritte aus, um sicherzustellen, dass sich die Rollenzuweisung der Containerregistrierung auf den richtigen Dienstprinzipal bezieht:

  1. Führen Sie den folgenden Befehl aus, um den dienstprinzipal zu überprüfen, der vom AKS-Cluster verwendet wird:

    az aks show --resource-group <myResourceGroup> \
    --name <myAKSCluster> \
    --query servicePrincipalProfile.clientId \
    --output tsv

  2. Führen Sie den folgenden Befehl aus, um den Dienstprinzipal zu überprüfen, auf den durch die Rollenzuweisung der Containerregistrierung verwiesen wird:

    az role assignment list --scope /subscriptions/<subscriptionID>/resourceGroups/<resourcegroupname>/providers/Microsoft.ContainerRegistry/registries/<acrname> -o table

  3. Vergleichen Sie die beiden Dienstprinzipale. Wenn sie nicht übereinstimmen, integrieren Sie den AKS-Cluster erneut in die Containerregistrierung.

Lösung 4: Stellen Sie sicher, dass in der AKS-VMSS auf die Kubelet-Identität verwiesen wird.

Wenn eine verwaltete Identität für die Authentifizierung mit dem ACR verwendet wird, wird die verwaltete Identität als Kubelet-Identität bezeichnet. Standardmäßig wird die Kubelet-Identität auf der AKS-VMSS-Ebene zugewiesen. Wenn die Kubelet-Identität aus der AKS-VMSS entfernt wird, können die AKS-Knoten keine Images aus der ACR pullen.

Führen Sie den folgenden Befehl aus, um die Kubelet-Identität Ihres AKS-Clusters zu ermitteln:

az aks show --resource-group <MyResourceGroup> --name <MyManagedCluster> --query identityProfile.kubeletidentity

Anschließend können Sie die Identitäten der AKS-VMSS auflisten, indem Sie die VMSS aus der Knotenressourcengruppe öffnen undidentitätsbenutzerseitig zugewiesen im Azure-Portal auswählen> oder den folgenden Befehl ausführen:

az vmss identity show --resource-group <NodeResourceGroup> --name <AksVmssName>

Wenn die Kubelet-Identität Ihres AKS-Clusters nicht der AKS-VMSS zugewiesen ist, weisen Sie sie wieder zu.

Hinweis

Das Ändern der AKS-VMSS mithilfe der IaaS-APIs oder des Azure-Portal wird nicht unterstützt, und kein AKS-Vorgang kann die Kubelet-Identität aus der AKS-VMSS entfernen. Dies bedeutet, dass es von einem unerwarteten Element entfernt wurde, z. B. eine manuelle Entfernung, die von einem Teammitglied durchgeführt wurde. Um eine solche Entfernung oder Änderung zu verhindern, können Sie die Verwendung des NRGLockdown-Features in Betracht ziehen.

Da Änderungen an der AKS-VMSS nicht unterstützt werden, werden sie nicht auf AKS-Ebene weitergegeben. Um die Kubelet-Identität der AKS-VMSS neu zuzuweisen, ist ein Abstimmungsvorgang erforderlich. Führen Sie dazu den folgenden Befehl aus:

az aks update --resource-group <MyResourceGroup> --name <MyManagedCluster>

Lösung 5: Stellen Sie sicher, dass der Dienstprinzipal richtig und das Geheimnis gültig ist.

Wenn Sie ein Image mithilfe eines Image-Pullgeheimnisses pullen und dieses Kubernetes-Geheimnis mit den Werten eines Dienstprinzipals erstellt wurde, stellen Sie sicher, dass der zugeordnete Dienstprinzipal richtig und das Geheimnis noch gültig ist. Gehen Sie folgendermaßen vor:

  1. Führen Sie den folgenden befehl kubectl get und base64 aus, um die Werte des Kubernetes-Geheimnisses anzuzeigen:

    kubectl get secret <secret-name> --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode

  2. Überprüfen Sie das Ablaufdatum, indem Sie den folgenden Befehl az ad sp credential list ausführen. Der Benutzername ist der Dienstprinzipalwert.

    az ad sp credential list --id "<username>" --query "[].endDate" --output tsv

  3. Setzen Sie bei Bedarf das Geheimnis dieses Dienstprinzipals zurück, indem Sie den folgenden Befehl az ad sp credential reset ausführen:

    az ad sp credential reset --name "$SP_ID" --query password --output tsv

  4. Aktualisieren oder erstellen Sie das Kubernetes-Geheimnis entsprechend.

Lösung 6: Stellen Sie sicher, dass das Kubernetes-Geheimnis über die richtigen Werte des Administratorkontos der Containerregistrierung verfügt.

Wenn Sie ein Image mithilfe eines Image-Pullgeheimnisses pullen und dieses Kubernetes-Geheimnis mithilfe der Werte des Containerregistrierungsadministratorkontos erstellt wurde, stellen Sie sicher, dass die Werte im Kubernetes-Geheimnis mit den Werten des Administratorkontos der Containerregistrierung identisch sind. Gehen Sie folgendermaßen vor:

  1. Führen Sie den folgenden befehl kubectl get und base64 aus, um die Werte des Kubernetes-Geheimnisses anzuzeigen:

    kubectl get secret <secret-name> --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode

  2. Suchen Sie im Azure-Portal nach Containerregistrierungen, und wählen Sie diese Option aus.

  3. Wählen Sie in der Liste der Containerregistrierungen Ihre Containerregistrierung aus.

  4. Wählen Sie im Navigationsbereich für die Containerregistrierung Die Option Zugriffsschlüssel aus.

  5. Vergleichen Sie auf der Seite Zugriffsschlüssel für die Containerregistrierung die Containerregistrierungswerte mit den Werten im Kubernetes-Geheimnis.

  6. Wenn die Werte nicht übereinstimmen, aktualisieren oder erstellen Sie das Kubernetes-Geheimnis entsprechend neu.

Hinweis

Wenn ein Vorgang zum erneuten Generieren eines Kennworts aufgetreten ist, wird auf der Seite Aktivitätsprotokoll der Containerregistrierung ein Vorgang mit dem Namen "Anmeldeinformationen der Containerregistrierung erneut generieren" angezeigt. Das Aktivitätsprotokoll hat einen Aufbewahrungszeitraum von 90 Tagen.

Ursache 2: Fehler "Image nicht gefunden"

Fehler beim Pullen des Images "<acrname.azurecr.io/<> repository:tag>": [rpc error: code = NotFound desc = failed to pull and unpack image "<acrname.azurecr.io/>< repository:tag>": failed to resolve reference "<acrname.azurecr.io/>< repository:tag>": <acrname.azurecr.io/>< repository:tag>: not found

Lösung: Stellen Sie sicher, dass der Imagename korrekt ist.

Wenn dieser Fehler angezeigt wird, vergewissern Sie sich, dass der Imagename vollständig korrekt ist. Überprüfen Sie den Registrierungsnamen, den Anmeldeserver der Registrierung, den Repositorynamen und das Tag. Ein häufiger Fehler ist, dass der Anmeldeserver als "azureacr.io" anstelle von "azurecr.io" angegeben wird.

Wenn der Imagename nicht vollständig korrekt ist, kann der Fehler 401 Nicht autorisiert auch auftreten, weil AKS immer anonymen Pullvorgang versucht, unabhängig davon, ob die Containerregistrierung anonymen Pullzugriff aktiviert hat.

Ursache 3: Fehler "403 Verboten"

Fehler beim Pullen des Images "<acrname.azurecr.io/<> repository:tag>": rpc error: code = Unknown desc = failed to pull and unpack image "<acrname.azurecr.io/<> repository:tag>": failed to resolve reference "<acrname.azurecr.io/>< repository:tag>": failed to authorize: failed to fetch anonymous token: unexpected status: 403 Forbidden

Wenn sich die Netzwerkschnittstelle des privaten Endpunkts der Containerregistrierung und des AKS-Clusters in unterschiedlichen virtuellen Netzwerken befinden, stellen Sie sicher, dass die virtuelle Netzwerkverbindung für das virtuelle Netzwerk des AKS-Clusters in der Privates DNS Zone der Containerregistrierung festgelegt ist. (Dieser Link heißt standardmäßig "privatelink.azurecr.io".) Wenn sich die virtuelle Netzwerkverbindung nicht in der Privates DNS Zone der Containerregistrierung befindet, fügen Sie sie mithilfe einer der folgenden Methoden hinzu:

Lösung 2: Hinzufügen der öffentlichen IP-Adresse von AKS Load Balancer zum zulässigen IP-Adressbereich der Containerregistrierung

Wenn der AKS-Cluster eine öffentliche Verbindung mit der Containerregistrierung herstellt (NICHT über eine private Verbindung oder einen Endpunkt), und der Zugriff auf das öffentliche Netzwerk der Containerregistrierung auf ausgewählte Netzwerke beschränkt ist, fügen Sie die öffentliche IP-Adresse von AKS Load Balancer dem zulässigen IP-Adressbereich der Containerregistrierung hinzu:

  1. Stellen Sie sicher, dass der Öffentliche Netzwerkzugriff auf ausgewählte Netzwerke beschränkt ist.

    Navigieren Sie im Azure-Portal zur Containerregistrierung. Wählen Sie unter Einstellungen die Option Netzwerk aus. Auf der Registerkarte Öffentlicher Zugriff ist öffentlicher Netzwerkzugriff auf Ausgewählte Netzwerke oder Deaktiviert festgelegt.

  2. Rufen Sie die öffentliche IP-Adresse des AKS-Load Balancer mit einer der folgenden Methoden ab:

    • Navigieren Sie im Azure-Portal zum AKS-Cluster. Wählen Sie unter Einstellungendie Option Eigenschaften aus, wählen Sie eine der VM-Skalierungsgruppen in der Infrastrukturressourcengruppe aus, und überprüfen Sie die öffentliche IP-Adresse der AKS-Load Balancer.

    • Führen Sie den folgenden Befehl aus:

      az network public-ip show --resource-group <infrastructure-resource-group> --name <public-IP-name> --query ipAddress -o tsv

  3. Lassen Sie den Zugriff über die öffentliche IP-Adresse des AKS-Load Balancer zu, indem Sie eine der folgenden Methoden verwenden:

    • Führen Sie az acr network-rule add den Befehl wie folgt aus:

      az acr network-rule add --name acrname --ip-address <AKS-load-balancer-public-IP-address>

      Weitere Informationen finden Sie unter Hinzufügen einer Netzwerkregel zur Registrierung.

    • Navigieren Sie im Azure-Portal zur Containerregistrierung. Wählen Sie unter Einstellungen die Option Netzwerk aus. Fügen Sie auf der Registerkarte Öffentlicher Zugriff unter Firewall die öffentliche IP-Adresse des AKS-Load Balancer zum Adressbereich hinzu, und wählen Sie dann Speichern aus. Weitere Informationen finden Sie unter Zugriff über ausgewähltes öffentliches Netzwerk – Portal.

      Hinweis

      Wenn Öffentlicher Netzwerkzugriff auf Deaktiviert festgelegt ist, wechseln Sie zuerst zu Ausgewählte Netzwerke .

      Screenshot: Hinzufügen der öffentlichen IP-Adresse von AKS Load Balancer zum Adressbereich

Ursache 4: Timeoutfehler 443

Fehler beim Pullen des Images "<acrname.azurecr.io/>< repository:tag>": rpc error: code = Unknown desc = failed to pull and unpack image "<acrname.azurecr.io/>< repository:tag>": failed to resolve reference "<acrname.azurecr.io/>< repository:tag>": Fehler beim Ausführen der Anforderung: Head "https://< acrname.azurecr.io/v2/<> repository>/manifests/v1": dial tcp <acrprivateipaddress>:443: i/o timeout

Hinweis

Der Fehler "Timeout 443" tritt nur auf, wenn Sie mithilfe von Azure Private Link eine private Verbindung mit einer Containerregistrierung herstellen.

Lösung 1: Sicherstellen, dass peering virtueller Netzwerke verwendet wird

Wenn sich die Netzwerkschnittstelle des privaten Endpunkts der Containerregistrierung und des AKS-Clusters in unterschiedlichen virtuellen Netzwerken befinden, stellen Sie sicher, dass das Peering virtueller Netzwerke für beide virtuellen Netzwerke verwendet wird. Sie können das Peering virtueller Netzwerke überprüfen, indem Sie den Azure CLI-Befehl az network vnet peering list --resource-group <MyResourceGroup> --vnet-name <MyVirtualNetwork> --output table ausführen oder im Azure-Portal, indem Sie im Bereich Einstellungen die VNETs-Peerings> auswählen. Weitere Informationen zum Auflisten aller Peerings eines angegebenen virtuellen Netzwerks finden Sie unter az network vnet peering list.

Wenn das Peering virtueller Netzwerke für beide virtuellen Netzwerke verwendet wird, stellen Sie sicher, dass der status "Verbunden" lautet. Wenn der status Getrennt lautet, löschen Sie das Peering aus beiden virtuellen Netzwerken, und erstellen Sie es dann neu. Wenn der status "Verbunden" lautet, lesen Sie den Leitfaden zur Problembehandlung: Das Peering-status ist "Verbunden".

Stellen Sie zur weiteren Problembehandlung eine Verbindung mit einem der AKS-Knoten oder -Pods her, und testen Sie dann die Konnektivität mit der Containerregistrierung auf TCP-Ebene mithilfe des Telnet- oder Netcat-Hilfsprogramms. Überprüfen Sie die IP-Adresse mit dem nslookup <acrname>.azurecr.io Befehl, und führen Sie dann den telnet <ip-address-of-the-container-registry> 443 Befehl aus.

Weitere Informationen zum Herstellen einer Verbindung mit AKS-Knoten finden Sie unter Herstellen einer Verbindung mit SSH mit Azure Kubernetes Service (AKS)-Clusterknoten zur Wartung oder Problembehandlung.

Lösung 2: Verwenden von Azure Firewall Service

Wenn sich die Netzwerkschnittstelle des privaten Endpunkts der Containerregistrierung und des AKS-Clusters in unterschiedlichen virtuellen Netzwerken befinden, können Sie zusätzlich zum Peering virtueller Netzwerke Azure Firewall Service verwenden, um eine Hub-Spoke-Netzwerktopologie in Azure einzurichten. Wenn Sie die Firewallregel einrichten, müssen Sie Netzwerkregeln verwenden, um die ausgehende Verbindung mit den IP-Adressen des privaten Endpunkts der Containerregistrierung explizit zuzulassen.

Ursache 5: Keine Übereinstimmung für plattform im Manifest

Das Hostbetriebssystem (Knotenbetriebssystem) ist nicht mit dem Image kompatibel, das für den Pod oder Container verwendet wird. Wenn Sie beispielsweise einen Pod für die Ausführung eines Linux-Containers auf einem Windows-Knoten oder einen Windows-Container auf einem Linux-Knoten planen, tritt der folgende Fehler auf:

Fehler beim Pullen des Images "<acrname.azurecr.io/>< repository:tag>":
[
  RPC-Fehler:
  code = NotFound
  desc = Fehler beim Pullen und Entpacken des Images "<acrname.azurecr.io/<> repository:tag>": keine Übereinstimmung für plattform im Manifest: nicht gefunden,
]

Dieser Fehler kann für ein Image auftreten, das aus einer beliebigen Quelle abgerufen wird, solange das Image mit dem Hostbetriebssystem nicht kompatibel ist. Der Fehler ist nicht auf Images beschränkt, die aus der Containerregistrierung abgerufen werden.

Lösung: Konfigurieren Sie das Feld nodeSelector ordnungsgemäß in Ihrem Pod oder ihrer Bereitstellung.

Geben Sie das richtige nodeSelector Feld in den Konfigurationseinstellungen Ihres Pods oder Ihrer Bereitstellung an. Der richtige Wert für die Einstellung dieses Felds kubernetes.io/os stellt sicher, dass der Pod auf dem richtigen Knotentyp geplant wird. Die folgende Tabelle zeigt, wie Sie die kubernetes.io/os Einstellung in YAML festlegen:

Containertyp YAML-Einstellung
Linux-Container "kubernetes.io/os": linux
Windows-Container "kubernetes.io/os": windows

Der folgende YAML-Code beschreibt beispielsweise einen Pod, der auf einem Linux-Knoten geplant werden muss:

apiVersion: v1
kind: Pod
metadata:
  name: aspnetapp
  labels:
    app: aspnetapp
spec:
  containers:
  - image: "mcr.microsoft.com/dotnet/core/samples:aspnetapp"
    name: aspnetapp-image
    ports:
    - containerPort: 80
      protocol: TCP
  nodeSelector:
    "kubernetes.io/os": linux

Weitere Informationen

Wenn ihnen die Anleitung zur Problembehandlung in diesem Artikel nicht hilft, das Problem zu beheben, sollten Sie folgendes beachten:

  • Überprüfen Sie die Netzwerksicherheitsgruppen und Routingtabellen, die Subnetzen zugeordnet sind, wenn Sie über eines dieser Elemente verfügen.

  • Wenn ein virtueller Anwendung wie eine Firewall den Datenverkehr zwischen Subnetzen steuert, überprüfen Sie die Firewall- und Firewallzugriffsregeln.

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.