Beheben von Fehlern beim Abrufen von Images aus der Azure-Containerregistrierung in Azure Kubernetes-Dienstcluster

Wenn Sie microsoft Azure Container Registry zusammen mit Azure Kubernetes Service (AKS) verwenden, muss ein Authentifizierungsmechanismus eingerichtet werden. Sie können die AKS to Container Registry-Integration mithilfe einiger einfacher Azure CLI- oder Azure PowerShell-Befehle einrichten. Diese Integration weist entweder die Rolle "Container Registry Repository Reader" (für ABAC-fähige Registrierungen) oder die Rolle "AcrPull" (für nicht ABAC-fähige Registrierungen) der kubelet-Identity zu, die dem AKS-Cluster zugeordnet ist, um Images aus einer Containerregistrierung abzurufen. Weitere Informationen zur erforderlichen ACR-Rolle, die basierend darauf zugewiesen werden soll, ob Ihre ACR-Registrierung ABAC-fähig ist, finden Sie unter Microsoft Entra-attributbasierte Zugriffssteuerung (ABAC).

In einigen Fällen schlägt das Abrufen von Images aus einer Containerregistrierung in einen AKS-Cluster fehl. Dieser Artikel enthält Anleitungen zur Problembehandlung der am häufigsten auftretenden Fehler, wenn Sie Bilder aus einer Containerregistrierung in einen AKS-Cluster abrufen.

Voraussetzungen

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:

• Wenn Sie einen AKS-Cluster benötigen, stellen Sie einen mithilfe der Azure CLI oder der Azure-Portal bereit.

• Wenn Sie eine Azure Container Registry (ACR) benötigen, erstellen Sie eine mithilfe der Azure CLI oder des Azure-Portal.

Außerdem benötigen Sie Azure CLI Version 2.0.59 oder eine höhere Version, um installiert und konfiguriert zu werden. Führen Sie az-Version aus, um die Version zu bestimmen. Wenn Sie Azure CLI installieren oder aktualisieren müssen, lesen Sie "Installieren von Azure CLI".

Symptome und erste Problembehandlung

Der Kubernetes-Pod ist "ImagePullBackOff" oder "ErrImagePull". Um detaillierte Fehlerinformationen zu erhalten, führen Sie den folgenden Befehl aus, und überprüfen Sie Ereignisse aus 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 auf die Containerregistrierung über den AKS-Cluster 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

Bei Erkennen eines Problems werden ein Fehlercode und eine Beschreibung bereitgestellt. Weitere Informationen zu den Fehlern und möglichen Lösungen finden Sie in der Fehlerreferenz zur Integritätsprüfung.

Führen Sie den folgenden Az aks Check-acr-Befehl aus, um zu überprüfen, ob auf die Containerregistrierung über den AKS-Cluster 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 Ereignissen in der Ausgabe des kubectl describe pod Befehls angezeigt werden.

Ursache 1: 401 Unauthorized Fehler

Ursache 1a: 401 Unauthorized Fehler aufgrund einer falschen Autorisierung

Ein AKS-Cluster erfordert eine Identität. Dabei kann es sich um eine verwaltete Identität oder einen Dienstprinzipal handeln. 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 eines Dienstprinzipals verwendet wird, wird der Dienstprinzipal selbst für die Authentifizierung mit ACR verwendet. Unabhängig davon, was die Identität ist, ist die richtige Autorisierung, die zum Abrufen eines Images aus einer Containerregistrierung verwendet wird, erforderlich. Andernfalls wird möglicherweise die folgende 401 Unauthorized Fehlermeldung angezeigt:

Failed to pull image "\<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

Mehrere Lösungen können Ihnen bei der Behebung dieses Fehlers helfen, vorbehaltlich der folgenden Einschränkungen:

• Lösungen 2, 3 und 5 gelten nur für AKS-Cluster, die einen Dienstprinzipal verwenden.

• Lösungen 1, 2, 3 und 4 gelten für die Azure-Methode zum Erstellen der Rollenzuweisung auf Containerregistrierungsebene für die Identität von AKS.

• Lösungen 5 und 6 gelten für die Kubernetes-Methode zum Ziehen eines Kubernetes-Geheimnis.

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

Die Integration zwischen AKS und der Containerregistrierung erstellt eine korrekte Rollenzuweisung auf der Ebene der Containerregistrierung für die Kubelet-Identität des AKS-Clusters.

Verwenden Sie eine der folgenden Methoden, um zu überprüfen, ob die richtige ACR-Rollenzuweisung vorhanden ist:

• 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 Weitere Informationen finden Sie unter Auflisten von Azure-Rollenzuweisungen mithilfe des Azure-Portal.

Neben entweder der Container Registry Repository Reader-Rolle (für ABAC-fähige Registrierungen) oder der AcrPull-Rolle (für nicht-ABAC-fähige Registrierungen) können auch einige integrierte Rollen und benutzerdefinierte Rollen die erforderlichen Microsoft Entra-Berechtigungen zum Abrufen von Images enthalten. Überprüfen Sie diese Rollen nach Bedarf.

Wenn entweder die Container Registry Repository Reader Rolle (für ABAC-aktivierte Registries) oder die AcrPull Rolle (für nicht-ABAC-aktivierte Registries) nicht vorhanden ist, können Sie die Rollenzuweisung erstellen.

Für nicht ABAC-fähige Registrierungen können Sie die AcrPull Rolle mit dem folgenden Befehl zuweisen:

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

Für ABAC-fähige Registrierungen unterstützt der az aks --attach-acr Befehl das Hinzufügen der Container Registry Repository Reader Rolle nicht. Sie müssen diese Rolle manuell der AKS Kubelet-Identität über das Azure-Portal oder die az role assignment CLI-Befehle zuweisen.

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

Stellen Sie sicher, dass der geheime Schlüssel 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 app credential list --id "SP_ID" --query "[].endDateTime" --output tsv

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

Wenn der geheime Schlüssel abgelaufen ist, aktualisieren Sie die Anmeldeinformationen für den AKS-Cluster.

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

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

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 die Containerregistrierungsrolle verweist:

   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 die Kubelet-Identität in den AKS Virtual Machine Scale Sets referenziert 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 Virtual Machine Scale Sets-Ebene zugewiesen. Wenn die Kubelet-Identität aus den AKS Virtual Machine Scale Sets entfernt wird, können die AKS-Knoten keine Bilder aus dem ACR abrufen.

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

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

Anschließend können Sie die Identitäten der AKS Virtual Machine Scale Sets auflisten, indem Sie die Skalierungsgruppen für virtuelle Maschinen aus der Knotenressourcengruppe öffnen und im Azure-Portal Identität>Benutzerdefiniert zugewiesen 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 den AKS Virtual Machine Scale Sets zugewiesen ist, weisen Sie sie erneut zu.

Da Änderungen an den Skalierungssätzen für virtuelle AKS-Computer nicht unterstützt werden, werden sie nicht auf der AKS-Ebene verteilt. Um die Kubelet-Identität den AKS Virtual Machine Scale Sets neu zuzuweisen, ist ein Abgleichsvorgang erforderlich. Führen Sie zu diesem Zweck den folgenden Befehl aus:

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

Lösung 5: Stellen Sie sicher, dass der Dienstprinzipal korrekt ist und der geheime Schlüssel gültig ist.

Wenn Sie ein Bild mithilfe eines Pullschlüssels abrufen und der geheime Kubernetes-Schlüssel mithilfe der Werte eines Dienstprinzipals erstellt wurde, stellen Sie sicher, dass der zugeordnete Dienstprinzipal korrekt ist und der geheime Schlüssel weiterhin gültig ist. Führen Sie folgende Schritte aus:

1. Führen Sie den folgenden Kubectl-Befehl undden base64-Befehl aus, um die Werte des Geheimen Kubernetes anzuzeigen:

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

2. Überprüfen Sie das Ablaufdatum, indem Sie den folgenden Az ad sp-Listenbefehl für Anmeldeinformationen ausführen. Der Benutzername ist der Dienstprinzipalwert.

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

3. Setzen Sie bei Bedarf den geheimen Schlüssel dieses Dienstprinzipals zurück, indem Sie den folgenden Az ad sp-Befehl zum Zurücksetzen von Anmeldeinformationen ausführen:

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

4. Aktualisieren oder erstellen Sie das Kubernetes Secret entsprechend neu.

Lösung 6: Stellen Sie sicher, dass der geheime Kubernetes-Schlüssel die richtigen Werte des Administratorkontos der Containerregistrierung aufweist.

Wenn Sie ein Image mithilfe eines Pullschlüssels abrufen und der geheime Kubernetes-Schlüssel mithilfe von Werten des Administratorkontos der Containerregistrierung erstellt wurde, stellen Sie sicher, dass die Werte im Geheimen Kubernetes mit den Werten des Containerregistrierungsadministratorkontos identisch sind. Führen Sie folgende Schritte aus:

1. Führen Sie den folgenden Kubectl-Befehl undden base64-Befehl aus, um die Werte des Geheimen Kubernetes anzuzeigen:

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

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

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

4. Wählen Sie im Navigationsbereich für die Containerregistrierung Die Zugriffstasten aus.

5. Vergleichen Sie auf der Seite "Zugriffstasten " für die Containerregistrierung die Containerregistrierungswerte mit den Werten im Geheimen Kubernetes.

6. Wenn die Werte nicht übereinstimmen, aktualisieren oder erstellen Sie den geheimen Kubernetes-Schlüssel entsprechend neu.

Ursache 1b: 401 Unauthorized Fehler aufgrund einer inkompatiblen Architektur

Möglicherweise tritt ein 401 Unauthorized Fehler auf, auch wenn die AKS-Clusteridentität autorisiert ist (wie in der Ursache 1a beschrieben: 401 Unauthorized Fehler aufgrund eines falschen Autorisierungsabschnitts ). Dieses Problem kann auftreten, wenn das Containerimage im ACR nicht mit der Architektur (wie ARM64 und AMD64) des Knotens übereinstimmt, auf dem der Container ausgeführt wird. Beispielsweise kann die Bereitstellung eines ARM64-Images auf einem AMD64-Knoten oder umgekehrt zu diesem Fehler führen.

Die Fehlermeldung wird wie folgt angezeigt:

Failed to pull image "\<acrname>.azurecr.io/\<repository:\tag>": [rpc error: code = NotFound desc = failed to pull and unpack image "\<acrname>.azurecr.io/\<repository:\tag>": no match for platform in manifest: not found, 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 from GET request to https://\<acrname>.azurecr.io/oauth2/token?scope=repository%3A\<repository>%3Apull&service=\<acrname>.azurecr.io: 401 Unauthorized]

Wenn Sie dieses Problem mithilfe der Azure CLI diagnostizieren, wird möglicherweise ein unerwarteter exec format Fehler angezeigt, wenn Ihr Systemknotenpool eine andere Architektur als das Image in der ACR ausführt:

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

exec /canipull: exec format error

Lösung: Pushimages mit der richtigen Architektur oder Push-Images mit mehreren Architekturen

Verwenden Sie eine der folgenden Methoden, um dieses Problem zu beheben:

• Stellen Sie sicher, dass die an ACR übertragenen Containerimages mit der Architektur Ihrer AKS-Knoten übereinstimmen (z. B. ARM64 oder AMD64).
• Erstellen und Pushen von Images mit mehreren Architekturen, die sowohl ARM64- als auch AMD64-Architekturen unterstützen.

Ursache 2: Fehler "Bild nicht gefunden"

Der Fehler "Bild nicht gefunden" wird wie folgt angezeigt:

Failed to pull image "\<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 Magiername korrekt ist.

Wenn dieser Fehler angezeigt wird, stellen Sie sicher, dass der Bildname korrekt ist. Überprüfen Sie den Registrierungsnamen, den Registrierungsanmeldungsserver, den Repositorynamen und das Tag.

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

Ursache 3: 403 forbidden Fehler

Die 403 Forbidden Fehlermeldung wird wie folgt angezeigt:

Failed to pull image "\<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

Lösung 1: Stellen Sie sicher, dass die AKS-Netzwerkverbindung in der Privaten DNS-Zone der Containerregistrierung festgelegt ist.

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

• Verwenden Sie das Azure-Portal:

1. Wählen Sie im Azure-Portal die private DNS-Zone privatelink.azurecr.io aus.
2. Wählen Sie unter "Einstellungen" die Option "Virtuelle Netzwerkverbindungen>hinzufügen" aus.
3. Wählen Sie einen Namen und das virtuelle Netzwerk des AKS-Clusters und dann "OK" aus.

• Erstellen Sie eine virtuelle Netzwerkverbindung mit der angegebenen privaten DNS-Zone mithilfe der Azure CLI.

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

Wenn der AKS-Cluster öffentlich eine Verbindung mit der Containerregistrierung herstellt (nicht über einen privaten Link oder endpunkt), und der zugriff auf das öffentliche Netzwerk der Containerregistrierung auf ausgewählte Netzwerke beschränkt ist, fügen Sie die öffentliche IP-Adresse des AKS-Lastenausgleichs dem zulässigen IP-Adressbereich der Containerregistrierung mithilfe der folgenden Schritte hinzu:

1. Stellen Sie sicher, dass der Zugriff auf das öffentliche Netzwerk auf ausgewählte Netzwerke beschränkt ist.

   1. Navigieren Sie im Azure-Portal zur Containerregistrierung.
   2. Wählen Sie unter Einstellungen die Option Netzwerk.
   3. Legen Sie auf der Registerkarte " Öffentlicher Zugriff " den Zugriff aufausgewählte Netzwerke oder "Deaktiviert" fest.

2. Rufen Sie die öffentliche IP-Adresse des AKS-Lastenausgleichs mithilfe einer der folgenden Methoden ab:

   • Verwenden Sie das Azure-Portal;

     1. Navigieren Sie im Azure-Portal zum AKS-Cluster.
     2. Wählen Sie unter Einstellungen die Option Eigenschaften aus.
     3. Wählen Sie einen der Skalierungsgruppen für virtuelle Computer in der Ressourcengruppe der Infrastruktur aus, und überprüfen Sie die öffentliche IP-Adresse des AKS-Lastenausgleichs.

   • 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. Zugriff von der öffentlichen IP-Adresse des AKS-Lastenausgleichs zulassen, indem Sie eine der folgenden Möglichkeiten verwenden:

   • Führen Sie den az acr network-rule add 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.

   • Verwenden Sie das Azure-Portal:

     1. Navigieren Sie im Azure-Portal zur Containerregistrierung.
     2. Wählen Sie unter Einstellungen die Option Netzwerk.
     3. Fügen Sie auf der Registerkarte " Öffentlicher Zugriff " in der Firewall die öffentliche IP-Adresse des AKS-Lastenausgleichs zum Adressbereich hinzu, und wählen Sie dann "Speichern" aus.

     Weitere Informationen finden Sie unter Access über ausgewähltes öffentliches Netzwerk – Portal.

     Notiz

     Wenn der Zugriff auf öffentliche Netzwerke auf "Deaktiviert" festgelegt ist, wechseln Sie zuerst zu ausgewählten Netzwerken .

     

Ursache 4: i/o timeout Fehler

Die i/o timeout Fehlermeldung wird wie folgt angezeigt:

Failed to pull image "\<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 do request: Head "https://\<acrname>.azurecr.io/v2/\<repository>/manifests/v1": dial tcp \<acrprivateipaddress>:443: i/o timeout

Lösung 1: Sicherstellen, dass virtuelle Netzwerk-Peering verwendet wird

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

Wenn das virtuelle Netzwerk-Peering für beide virtuellen Netzwerke verwendet wird, stellen Sie sicher, dass der Status "Verbunden" ist. Wenn der Status "Getrennt" lautet, löschen Sie das Peering aus beiden virtuellen Netzwerken, und erstellen Sie ihn erneut. Wenn der Status "Verbunden" lautet, lesen Sie den Leitfaden zur Problembehandlung: Der Peeringstatus ist "Verbunden".

Zur weiteren Problembehandlung stellen Sie eine Verbindung mit einem der AKS-Knoten oder Pods her, und testen Sie dann die Verbindung 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 der Azure-Firewall

Wenn sich die Netzwerkschnittstelle des privaten Endpunkts der Containerregistrierung und der AKS-Cluster in verschiedenen virtuellen Netzwerken (zusätzlich zum virtuellen Netzwerk-Peering) befinden, können Sie die Azure-Firewall 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 die 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:

Failed to pull image "\<acrname>.azurecr.io/\<repository:tag>"\:\ [\ &nbsp; rpc error:\ &nbsp; code = NotFound\ &nbsp; desc = failed to pull and unpack image "\<acrname>.azurecr.io/\<repository:tag>": **no match for platform in manifest**: not found,\ ]

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

Lösung: Konfigurieren des nodeSelector-Felds ordnungsgemäß in Ihrer Pod- oder 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. In der folgenden Tabelle wird gezeigt, wie Sie die kubernetes.io/os Einstellung in YAML festlegen:

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

Ursache 6: Kubelet überschreitet die Standardmäßige Bild-Pullrate-Grenze.

Wenn mehrere Aufträge dieselben Bilder ziehen, kann die Standardmäßige Pullrate-Grenze für Kubelet überschritten werden. In diesem Fall wird eine Fehlermeldung wie die folgende angezeigt:

Failed to pull image "acrname.azurecr.io/repo/nginx:latest": pull QPS exceeded. This occurred for pod \<podname\> at 4/22/2025, 12:48:32.000 PM UTC.

Weitere Informationen zum Grenzwert finden Sie in der RegistryPullQPS-Konfiguration.

Lösung: Ändern des Werts von imagePullPolicy in IfNotPresent

Um das Problem zu lösen, ändern Sie den Wert von imagePullPolicy von Always auf IfNotPresent in der YAML-Bereitstellungsdatei, um unnötige Pulls zu verhindern. IfNotPresent stellt sicher, dass das Bild nur dann aus der Registrierung abgerufen wird, wenn es noch nicht auf dem Knoten vorhanden ist.

Hier ist ein Beispiel für die YAML-Bereitstellungsdatei:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: myacr.azurecr.io/my-image:latest
        imagePullPolicy: IfNotPresent

Weitere Überlegungen

Wenn die Anleitung zur Problembehandlung in diesem Artikel Ihnen nicht hilft, das Problem zu beheben, sollten Sie folgendes berücksichtigen:

• Überprüfen Sie die Netzwerksicherheitsgruppen und Routentabellen, die Subnetzen zugeordnet sind (sofern sie über eines dieser Elemente verfügen).

• Wenn eine virtuelle Appliance 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, können Sie den Azure-Communitysupport stellen. Sie können auch Produktfeedback an die Azure Feedback Community senden.