Probleme beim Abrufen von Bildern beheben

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Auf dieser Seite erfahren Sie, wie Sie Probleme beim Abrufen von Images in der Google Kubernetes Engine (GKE) beheben. Wenn Sie Image-Streaming verwenden, finden Sie unter Fehlerbehebung bei Image-Streaming entsprechende Informationen. Auf dieser Seite geht es um das Standard-Abrufen von Bildern.

Diese Seite richtet sich an App-Entwickler, die dafür sorgen möchten, dass ihre Apps erfolgreich bereitgestellt werden, sowie an Plattformadministratoren und ‑betreiber, die die Ursache von Fehlern beim Abrufen von Images ermitteln und die Plattformkonfiguration überprüfen möchten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und ‑Aufgaben.

Über den Image-Pull-Vorgang ruft Kubernetes und damit GKE Container-Images aus einer Registry ab. Wenn der Abruf eines Bildes fehlschlägt, kann es sein, dass Ihre App langsam läuft oder gar nicht funktioniert.

Auf dieser Seite erfahren Sie, wie Sie feststellen können, ob das Abrufen von Bildern die Ursache für die Funktionsstörung Ihrer App ist. Dazu müssen Sie relevante Fehlermeldungen finden und verstehen. Anschließend erfahren Sie, wie Sie die folgenden häufigen Ursachen für Fehler beim Abrufen von Bildern beheben:

• Authentifizierungseinstellungen: Ihrem Cluster fehlen die erforderlichen Berechtigungen für den Zugriff auf die Container-Image-Registry.
• Netzwerkverbindung: Ihr Cluster kann aufgrund von DNS-Problemen, Firewallregeln oder fehlendem Internetzugriff in Clustern mit Netzwerkisolation keine Verbindung zur Registry herstellen.
• Image not found in registry (Image nicht in der Registry gefunden): Der angegebene Bildname oder das angegebene Bild-Tag ist falsch, das Bild wurde gelöscht oder die Registry ist nicht verfügbar.
• Leistungseinschränkungen: Eine große Bildgröße, eine langsame Laufwerks-E/A oder eine Netzwerküberlastung können zu langsamen Abrufen oder Zeitüberschreitungen führen.
• Nicht kompatible Image-Architektur: Das Image wurde für eine andere CPU-Architektur als Ihr GKE-Knotenpool erstellt.
• Inkompatible Schemaversionen: Möglicherweise verwenden Sie containerd 2.0 oder höher mit einem Docker-Schema der Version 1, was nicht unterstützt wird.

Wenn Sie bereits eine bestimmte Ereignisnachricht gesehen haben, suchen Sie auf dieser Seite nach der Nachricht und folgen Sie der aufgeführten Fehlerbehebung. Wenn Sie keine Nachricht erhalten haben, gehen Sie die folgenden Abschnitte der Reihe nach durch. Wenn das Problem weiterhin besteht, wenden Sie sich an Cloud Customer Care.

Image-Pulls

Bevor Sie mit der Fehlerbehebung beginnen, sollten Sie sich mit dem Lebenszyklus eines Bildes und den Möglichkeiten zum Hosten von Bildern vertraut machen.

Image-Lebenszyklus

Wenn Sie einen Pod erstellen, erhält das kubelet die Pod-Definition, die die Spezifikation für das Image enthält. Das Kubelet benötigt dieses Image, um einen Container basierend auf dem Image ausführen zu können. Bevor das Image abgerufen wird, prüft das kubelet in der Containerlaufzeit, ob das Image vorhanden ist. Außerdem prüft der kubelet die Image-Pull-Richtlinie des Pods. Wenn sich das Image nicht im Cache der Containerlaufzeit befindet oder dies von der Image-Pull-Richtlinie gefordert wird, weist Kubelet die Containerlaufzeit (containerd) an, das angegebene Image aus der Registry abzurufen. Ein fehlgeschlagener Image-Pull verhindert, dass der Container im Pod gestartet wird.

Nach einem erfolgreichen Image-Pull packt die Containerlaufzeit das Image aus, um ein schreibgeschütztes Basisdateisystem für den Container zu erstellen. Die Containerlaufzeit speichert dieses Image. Es bleibt so lange vorhanden, wie laufende Container darauf verweisen. Wenn keine laufenden Container auf ein Image verweisen, kann es durch die Garbage Collection entfernt werden.

Optionen für das Bildhosting

Wir empfehlen, eine der folgenden Optionen zum Hosten Ihrer Bilder zu verwenden:

• Artifact Registry: Artifact Registry ist der vollständig verwaltete Paketmanager von Google. Artifact Registry lässt sich nahtlos in andere Google Cloud Dienste einbinden und bietet eine detaillierte Zugriffssteuerung. Weitere Informationen finden Sie in der Artifact Registry-Dokumentation unter Mit Container-Images arbeiten.

• Selbst gehostete Registry: Eine selbst gehostete Registry bietet Ihnen mehr Kontrolle, Sie müssen sie aber auch selbst verwalten. Diese Option sollten Sie in Betracht ziehen, wenn Sie bestimmte Compliance- oder Sicherheitsanforderungen haben, die Artifact Registry nicht erfüllen kann.

Fehler beim Abrufen des Images diagnostizieren

Führen Sie die in den folgenden Abschnitten beschriebenen Schritte aus, um Fehler beim Abrufen von Images zu diagnostizieren:

1. Pod-Status und -Ereignisse aufrufen
2. Bedeutung des Status
3. Anhand von Ereignismeldungen können Sie die Ursache für den Fehler beim Bildabruf ermitteln.
4. Logs im Log-Explorer ansehen

Pod-Status und -Ereignisse ansehen

Damit Sie prüfen können, ob ein Image-Pull fehlgeschlagen ist, zeichnet GKE die folgenden Status für Pods auf:

• ImagePullBackOff
• ErrImagePull
• ImageInspectError
• InvalidImageName
• RegistryUnavailable
• SignatureValidationFailed

ImagePullBackOff und ErrImagePull sind die häufigsten dieser Status.

Zusätzlich zu diesen Status helfen Ihnen Kubernetes-Ereignisse, die Ursache für Fehler beim Abrufen von Images zu ermitteln.

Wenn Sie prüfen möchten, ob der Abruf des Bildes fehlgeschlagen ist, sehen Sie nach, ob Statusmeldungen vorliegen. Wählen Sie dann eine der folgenden Optionen aus, um Ereignismeldungen zu lesen:

Bedeutung des Status

In den folgenden Beschreibungen erfahren Sie mehr über die Bedeutung der verschiedenen Status:

• ImagePullBackOff: Das kubelet konnte das Image nicht abrufen, versucht es aber immer wieder mit einer zunehmenden Verzögerung (oder Backoff) von bis zu fünf Minuten.
• ErrImagePull: Ein allgemeiner, nicht wiederherstellbarer Fehler beim Abrufen des Images.
• ImageInspectError: Bei der Prüfung des Container-Images ist ein Problem aufgetreten.
• InvalidImageName: Der Name des in Ihrer Pod-Definition angegebenen Container-Images ist ungültig.
• RegistryUnavailable: Die Registry ist nicht zugänglich. In der Regel liegt ein Problem mit der Netzwerkverbindung vor.
• SignatureValidationFailed: Die digitale Signatur des Container-Images konnte nicht überprüft werden.

Ereignismeldungen verwenden, um die Ursache für den Fehler beim Abrufen von Bildern zu ermitteln

In der folgenden Tabelle sind Ereignismeldungen zu Abrufen von Bildern aufgeführt, die fehlgeschlagen sind, sowie die Schritte zur Fehlerbehebung, die Sie ausführen sollten, wenn eine dieser Meldungen angezeigt wird.

Nachrichten im Zusammenhang mit fehlgeschlagenen Bildabrufen haben oft das folgende Präfix:

Failed to pull image "IMAGE_ADDRESS": rpc error: code = CODE = failed to pull and unpack image "IMAGE_ADDRESS": failed to resolve reference "IMAGE_ADDRESS":

Diese Nachricht enthält die folgenden Werte:

• IMAGE_ADDRESS: die vollständige Adresse des Bildes. Beispiel: us-west1-docker.pkg.dev/my-project/my-repo/test:staging
• CODE: ein Fehlercode, der mit der Protokollmeldung verknüpft ist. Beispiel: NotFound oder Unknown.

Für einige Ursachen von Image-Pull-Fehlern gibt es keine zugehörige Ereignismeldung. Wenn Sie keine der Ereignismeldungen in der folgenden Tabelle sehen, aber weiterhin Probleme beim Abrufen von Bildern auftreten, empfehlen wir Ihnen, den Rest der Seite zu lesen.

Logs im Log-Explorer ansehen

Wenn Sie bisherige Ereignisse zum Abrufen von Images prüfen oder Fehler beim Abrufen von Images mit anderen Komponentenaktivitäten in Beziehung setzen möchten, können Sie Logs im Log-Explorer aufrufen:

1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

   Zum Log-Explorer

2. Geben Sie im Bereich „Abfrage“ die folgende Abfrage ein:

   log_id("events")
   resource.type="k8s_pod"
   resource.labels.cluster_name="CLUSTER_NAME"
   jsonPayload.message=~"Failed to pull image"
   

   Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters, in dem der Pod mit den Fehlern beim Abrufen von Images ausgeführt wird.

3. Klicken Sie auf Abfrage ausführen und sehen Sie sich die Ergebnisse an.

Authentifizierungseinstellungen prüfen

In den folgenden Abschnitten erfahren Sie, wie Sie prüfen, ob Ihre GKE-Umgebung die richtigen Authentifizierungseinstellungen für das Abrufen von Images aus dem Repository hat.

Führen Sie die folgenden Schritte aus, um zu prüfen, ob Authentifizierungsprobleme zu Problemen beim Abrufen von Bildern führen:

1. Prüfen Sie den Zugriff auf das Bild.
2. Prüfen Sie die Konfiguration von „imagePullSecret“ und die Bereitstellungsspezifikation.
3. Zugriffsbereich des Knotens für privates Artifact Registry-Repository prüfen
4. Prüfen Sie die VPC Service Controls-Einstellungen für den Zugriff auf Artifact Registry.

Zugriff auf das Bild überprüfen

Wenn der Fehler 403 Forbidden beim Pullen eines Images auftritt, prüfen Sie, ob die erforderlichen Komponenten auf das Container-Image zugreifen können.

Die Methode zum Überprüfen und Anwenden der erforderlichen Rollen, um den erforderlichen Zugriff zu gewähren, hängt davon ab, in welchem Repository Ihre Bilder gespeichert sind. Wählen Sie eine der folgenden Optionen aus, um den Zugriff zu bestätigen und zu gewähren:

Konfiguration von imagePullSecret und Deployment-Spezifikation prüfen

Wenn Sie ein „imagePullSecret“ verwenden, müssen Sie ein Secret mit den Anmeldedaten für das Abrufen von Images erstellen und für alle Bereitstellungen das von Ihnen definierte Secret angeben. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter imagePullSecrets für einen Pod angeben.

Zugriffsbereich des Knotens für privates Artifact Registry-Repository prüfen

Wenn Sie Ihr Container-Image in einem privaten Artifact Registry-Repository speichern, hat Ihr Knoten möglicherweise nicht den richtigen Zugriffsbereich. In diesem Fall kann ein 401 Unauthorized-Bildabruffehler auftreten.

So überprüfen Sie den Zugriffsbereich und gewähren ihn bei Bedarf:

1. Identifizieren Sie den Knoten, auf dem der Pod ausgeführt wird:

   kubectl describe pod POD_NAME | grep "Node:"
   

   Ersetzen Sie POD_NAME durch den Namen des Pods, bei dem ein Image-Pull-Fehler auftritt.

2. Prüfen Sie, ob der im vorherigen Schritt identifizierte Knoten den richtigen Speicherumfang hat:

   gcloud compute instances describe NODE_NAME \
       --zone="COMPUTE_ZONE \
       --format="flattened(serviceAccounts[].scopes)"
   

   Ersetzen Sie Folgendes:

   • NODE_NAME: der Name des Knotens, den Sie im vorherigen Schritt identifiziert haben.
   • COMPUTE_ZONE: die Compute Engine-Zone, zu der der Knoten gehört.

   Die Ausgabe sollte mindestens einen der folgenden Zugriffsbereiche enthalten:

   • serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/devstorage.read_only
   • serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/cloud-platform

   Wenn der Knoten keinen dieser Bereiche enthält, schlägt der Abruf des Bildes fehl.

3. Erstellen Sie den Knotenpool, zu dem der Knoten gehört, mit ausreichendem Umfang neu. Da vorhandene Knoten nicht geändert werden können, müssen Sie den Knoten mit dem richtigen Umfang neu erstellen.

   Wir empfehlen, den Knotenpool mit dem Umfang gke-default zu erstellen. Dieser Bereich bietet Zugriff auf die folgenden Bereiche:

   • https://www.googleapis.com/auth/devstorage.read_only
   • https://www.googleapis.com/auth/logging.write
   • https://www.googleapis.com/auth/monitoring
   • https://www.googleapis.com/auth/service.management.readonly
   • https://www.googleapis.com/auth/servicecontrol
   • https://www.googleapis.com/auth/trace.append

   Wenn der Bereich gke-default nicht geeignet ist, gewähren Sie dem Knotenpool den Bereich devstorage.read_only, der nur Lesezugriff auf Daten ermöglicht.

   gke-default

   Erstellen Sie einen Knotenpool mit dem Bereich gke-default:

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --zone=COMPUTE_ZONE \
       --scopes="gke-default"
   

   Ersetzen Sie Folgendes:

   • NODE_POOL_NAME: der Name des neuen Knotenpools.
   • CLUSTER_NAME ist der Name Ihres vorhandenen Clusters.
   • COMPUTE_ZONE: die Compute Engine-Zone, zu der der neue Knotenpool gehören soll.

   devstorage.read_only

   Erstellen Sie einen Knotenpool mit dem Bereich devstorage.read_only:

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --zone=COMPUTE_ZONE \
       --scopes="https://www.googleapis.com/auth/devstorage.read_only"
   

   Ersetzen Sie Folgendes:

   • NODE_POOL_NAME: der Name des neuen Knotenpools.
   • CLUSTER_NAME ist der Name Ihres vorhandenen Clusters.
   • COMPUTE_ZONE: die Compute Engine-Zone, zu der der neue Knotenpool gehören soll.

VPC Service Controls-Einstellungen für den Zugriff auf Artifact Registry prüfen

Wenn Sie VPC Service Controls verwenden, achten Sie darauf, dass Dienstperimente den Zugriff auf Artifact Registry zulassen. Weitere Informationen finden Sie in der Artifact Registry-Dokumentation unter Repositories in einem Dienstperimeter schützen.

Netzwerkverbindung prüfen

Während des Abrufens eines Images kann die Netzwerkverbindung verhindern, dass der Vorgang abgeschlossen wird.

Führen Sie die in den folgenden Abschnitten beschriebenen Prüfungen durch, um festzustellen, ob Netzwerkverbindungsprobleme das Problem beim Abrufen von Images verursachen:

1. DNS-Auflösung untersuchen
2. Prüfen Sie Ihre Firewallkonfiguration.
3. Internetverbindung externer Registry-Endpunkte prüfen
4. Prüfen Sie, ob die Verbindung zu Google APIs eine Zeitüberschreitung auslöst.

DNS-Auflösung untersuchen

Wenn Sie einen server misbehaving-Bildabruffehler sehen, kann die DNS-Auflösung die Ursache für den Fehler sein.

Versuchen Sie Folgendes, um Probleme mit der DNS-Auflösung zu untersuchen:

1. Fehlerbehebung beim Metadatenserver Der Metadatenserver des Knotens löst alle DNS-Abfragen auf. Probleme mit diesem Server können die Namensauflösung stören, die Verbindung zum Repository verhindern und dazu führen, dass der Abruf des Images fehlschlägt.
2. Wenn Sie Cloud DNS für die DNS-Auflösung verwenden, müssen Ihre von Cloud DNS verwalteten privaten Zonen, Weiterleitungszonen, Peering-Zonen und Antwortrichtlinien richtig konfiguriert sein. Fehlkonfigurationen in diesen Bereichen können die DNS-Auflösung beeinträchtigen. Weitere Informationen zu Cloud DNS finden Sie unter Cloud DNS für GKE verwenden. Informationen zur Fehlerbehebung bei Cloud DNS in GKE finden Sie unter Fehlerbehebung bei Cloud DNS in GKE.
3. Wenn Sie kube-dns für die DNS-Auflösung verwenden, achten Sie darauf, dass es richtig funktioniert. Informationen zur Fehlerbehebung bei kube-dns finden Sie unter Fehlerbehebung bei kube-dns in GKE.
4. Wenn die Knoten des Clusters keine externen IP-Adressen haben (was bei der Verwendung der Netzwerkisolierung häufig der Fall ist), aktivieren Sie den privaten Google-Zugriff im vom Cluster verwendeten Subnetz und achten Sie darauf, die Netzwerkanforderungen zu erfüllen. Wenn Sie Cloud NAT verwenden, wird der private Google-Zugriff vonGoogle Cloud automatisch aktiviert.

Firewallkonfiguration prüfen

Wenn ein Problem mit Ihrer Firewall dazu führt, dass der Abruf des Images fehlschlägt, wird möglicherweise die folgende Fehlermeldung angezeigt:

Failed to start Download and install k8s binaries and configurations

Probleme mit der Firewall diagnostizieren

Wenn Sie einen Standardcluster verwenden und prüfen möchten, ob ein Problem mit Ihrer Firewall zu Problemen beim Abrufen von Bildern führt, gehen Sie so vor:

1. Stellen Sie über SSH eine Verbindung zum Knoten her, bei dem Probleme auftreten:

   gcloud compute ssh NODE_NAME --zone=ZONE_NAME
   

   Ersetzen Sie Folgendes:

   • NODE_NAME ist der Name des Knotens.
   • ZONE_NAME: die Compute Engine-Zone, in der der Knoten erstellt wurde.

2. Senden Sie die neuesten Protokolle für die Dienste kube-node-installation.service und kube-node-configuration.service an Textdateien mit den Namen kube-node-installation_status.txt und kube-node-configuration_status.txt:

   systemctl status kube-node-installation.service > kube-node-installation_status.txt
   systemctl status kube-node-configuration.service > kube-node-configuration_status.txt
   

   Wenn diese Protokolle keine Informationen zum fehlgeschlagenen Abrufen des Bildes enthalten, generieren Sie eine vollständige Kopie der Protokolle:

   sudo journalctl -u kube-node-installation.service > kube-node-installation_logs.txt
   sudo journalctl -u kube-node-configuration.service > kube-node-configuration_logs.txt
   

3. Prüfen Sie den Inhalt der Dateien kube-node-installation_status.txt und kube-node-configuration_status.txt. Wenn in der Ausgabe i/o timeout angezeigt wird, liegt das Problem wahrscheinlich an der Firewall.

Probleme mit der Firewallkonfiguration beheben

So beheben Sie Probleme mit der Firewall:

1. Identifizieren und beheben Sie alle Firewallregeln, die den Netzwerkverkehr blockieren. Beispielsweise haben Sie eine Regel, die den Traffic zur Registry blockiert, in der Ihr Bild gespeichert ist.

   1. So greifen Sie auf VPC-Flusslogs zu:

      1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

         Zum Log-Explorer

      2. Geben Sie im Bereich „Abfrage“ die folgende Abfrage ein:

         resource.type="gce_subnetwork"
         logName="projects/PROJECT_ID/logs/[compute.googleapis.com%2Fvpc_flows](http://compute.googleapis.com%2Fvpc_flows)"
         resource.labels.subnetwork_name="SUBNET_NAME",
         

         Ersetzen Sie Folgendes:

         • PROJECT_ID ist die ID Ihres Google Cloud-Projekts.
         • SUBNET_NAME: der Name Ihres Subnetzes.

         Weitere Informationen finden Sie in der VPC-Dokumentation unter Über Abfragen auf Flussprotokolle zugreifen.

   2. Wenn Sie Firewallregeln finden, die erforderlichen Traffic blockieren, aktualisieren Sie sie.

2. Wenn die Knoten des Clusters keine externen IP-Adressen haben (was bei der Verwendung der Netzwerkisolierung häufig der Fall ist), aktivieren Sie den privaten Google-Zugriff im vom Cluster verwendeten Subnetz und achten Sie darauf, die Netzwerkanforderungen zu erfüllen. Wenn Sie Cloud NAT verwenden, wird der private Google-Zugriff vonGoogle Cloud automatisch aktiviert.

Internetverbindung externer Registry-Endpunkte prüfen

Wenn Ihre Netzwerkkonfiguration den Traffic über einen externen Registry-Endpunkt leitet, hat dieser Endpunkt möglicherweise keine Internetverbindung. Wenn der Endpunkt keinen Zugriff hat, schlägt der Image-Pull möglicherweise fehl und Sie sehen einen i/o timeout-Fehler beim Image-Pull.

Verwenden Sie ping oder traceroute, um die Netzwerkverbindung vom externen Registry-Endpunkt zur Registry zu prüfen:

ping REGISTRY_ENDPOINT

Oder

traceroute REGISTRY_ENDPOINT

Ersetzen Sie REGISTRY_ENDPOINT durch den Registry-Endpunkt. Dieser Wert kann ein Hostname oder eine IP-Adresse sein.

Wenn Sie einen Fehler bei der Verbindung finden, prüfen Sie die VPC-Routen:

1. Rufen Sie in der Google Cloud Console Routen auf.

   Zur Seite „Routes“

2. Prüfen Sie die Spalte Priority und achten Sie darauf, dass die Route mit der höchsten Priorität zu einer Quelle führt, die Zugriff auf die Registry hat. Routen mit niedrigeren Werten haben Vorrang.

Prüfen, ob die Verbindung zu Google APIs eine Zeitüberschreitung verursacht

Wenn Sie die Netzwerkisolation verwenden, kann es zu einem Fehler kommen, bei dem die Verbindung zu Google APIs und ‑Diensten ein Zeitlimit überschreitet, was zu einem i/o timeout-Bildabruffehler führt.

Dieser Fehler tritt auf, weil Ihre Knoten beim Abrufen von Images aus der Registry keine der folgenden APIs erreichen konnten:

• containerregistry.googleapis.com
• artifactregistry.googleapis.com

Probieren Sie die folgenden Lösungen aus, um eine Verbindung zu den erforderlichen APIs herzustellen:

1. Aktivieren Sie den privaten Google-Zugriff. Knoten ohne externe IP-Adressen benötigen den privaten Google-Zugriff, um die externen IP-Adressen von Google APIs und Diensten zu erreichen.
2. Verwenden Sie eine unterstützte Domain.

3. Prüfen Sie Ihre Firewallrichtlinien:

   1. Rufen Sie in der Google Cloud Console die Seite „Firewall-Richtlinien“ auf.

      Zu den Firewall-Richtlinien

   2. Prüfen Sie, ob es Regeln gibt, die ausgehenden TCP-Traffic an den Ports 443 bis 199.36.153.4/30, 199.36.153.8/30 oder an einem IP-Adressbereich blockieren, der von Ihrer ausgewählten Domain für Google APIs und Dienste verwendet wird. Die IP-Adressbereiche 199.36.153.4/30 und 199.36.153.8/30 werden jeweils für den privaten Google-Zugriff und den eingeschränkten privaten Google-Zugriff verwendet. TCP-Traffic auf Port 443 an diese Bereiche dient dem Zugriff auf Google APIs und -Dienste.

      Wenn Sie eine dieser Regeln finden, erstellen Sie eine Firewallregel für ausgehenden Traffic, um diesen Traffic zuzulassen.

4. Wenn Sie Artifact Registry verwenden, muss Ihre Umgebung die Anforderungen für die Verwendung von Artifact Registry mit Netzwerkisolation erfüllen.

5. Prüfen Sie, ob für virtuelle IP-Adressen (VIPs) (199.36.153.4/30 oder 199.36.153.8/30) VPC-Routen konfiguriert sind:

   1. Rufen Sie in der Google Cloud Console „VPC-Netzwerke“ auf.

      Zur Seite VPC-Netzwerke

   2. Klicken Sie in der Spalte Name auf standard.

   3. Klicken Sie auf der Seite mit den VPC-Netzwerkdetails auf den Tab Routen.

   4. Sehen Sie sich die Tabelle „routes“ an.

      Wenn Ihr VPC-Netzwerk eine Standardroute (Ziel 0.0.0.0/0 oder ::0/0) enthält und der nächste Hop für diese Route das Standard-Internetgateway (Netzwerkstandard) ist, verwenden Sie diese Route für die VIPs, um auf Google APIs und ‑Dienste zuzugreifen.

      Wenn Sie eine Standardroute durch eine benutzerdefinierte Route ersetzt haben, deren nächster Hop nicht das Standard-Internetgateway ist, können Sie die Routinganforderungen für Google APIs und -Dienste erfüllen, indem Sie benutzerdefiniertes Routing verwenden.

Herausfinden, warum das kubelet Ihr Image nicht finden kann

Wenn das kubelet Ihr Image nicht finden kann, wird möglicherweise ein image not found-Fehler angezeigt und das Abrufen des Images schlägt fehl.

Sie können versuchen, das Problem mithilfe der folgenden Lösungen zu beheben:

1. Prüfen Sie das Manifest Ihres Pods und achten Sie darauf, dass der Name des Images und das Bild-Tag richtig geschrieben sind. Rechtschreib- oder Formatierungsfehler führen dazu, dass der Abruf des Bildes fehlschlägt.
2. Prüfen Sie, ob das Image noch in der Registry vorhanden ist, in der Sie es gespeichert haben. Wenn das Image einen vollständigen Registry-Pfad hat, schauen Sie nach, ob es in der von Ihnen verwendeten Docker-Registry vorhanden ist. Falls Sie nur den Image-Namen angegeben haben, prüfen Sie die Docker Hub-Registry.
3. Wenn in Ihrem Cluster die Netzwerkisolation verwendet wird, versuchen Sie Folgendes:
   1. Privaten Google-Zugriff aktivieren
   2. Prüfen Sie, ob Ihr Dienstperimeter richtig konfiguriert ist.

Herausfinden, warum es Zeitüberschreitungen oder Verzögerungen beim Abrufen von Bildern gibt

Wenn Sie ein sehr großes Image für Ihre GKE-Arbeitslast verwenden, tritt möglicherweise ein Zeitüberschreitungsfehler beim Abrufen des Images auf, was einen context cancelled-Fehler verursacht. Für Bilder gibt es zwar keine definierte Größenbeschränkung, der Fehler context cancelled weist jedoch oft darauf hin, dass die Größe des Bildes die Ursache ist.

Möglicherweise stellen Sie auch fest, dass Bildabrufe zwar nicht fehlschlagen, aber viel länger als gewöhnlich dauern. Wenn Sie einen Vergleichswert für die regulären Abrufzeiten von Images haben möchten, sehen Sie sich den Successfully pulled image-Logeintrag an. Die folgende Protokollmeldung zeigt beispielsweise, dass der Abruf des Images 30,313387996 Sekunden gedauert hat:

Successfully pulled image "IMAGE_ADDRESS" in 30.313387996s.

Für Zeitüberschreitungen und langsame Bildabrufe gibt es viele gemeinsame Ursachen. Versuchen Sie Folgendes, um diese Probleme zu beheben:

1. Prüfen Sie, ob es Probleme mit der Netzabdeckung gibt. Wenn Sie dieses Problem nur in einem bestimmten Zeitraum festgestellt haben, prüfen Sie, ob es zu Google Cloud Ausfallzeiten gekommen ist.
2. Prüfen Sie die Laufwerksleistung. Langsame Laufwerk-E/A-Vorgänge können die Pull-Zeiten von Images verlängern. Sie können auf nichtflüchtige Speicher mit SSDs (pd-ssd) umstellen oder größere Laufwerke verwenden, um die Leistung zu verbessern. Weitere Informationen finden Sie unter Fehlerbehebung bei Problemen mit der Laufwerksleistung.
3. Verringern Sie die Bildgröße. Sie können beispielsweise einige Daten aus den Container-Images in persistente Volumes verschieben.
4. Mithilfe von Image-Caching können Sie die Pod-Startzeit verkürzen. GKE speichert Images auf Knoten im Cache. Beim Abrufen eines Images lädt die Containerlaufzeit nur Ebenen herunter, die noch nicht im Cache vorhanden sind. Um die Effektivität dieses Caching-Mechanismus zu maximieren und die Zeit für das Abrufen von Images zu minimieren, sollten Sie Ihr Dockerfile so strukturieren, dass sich häufig ändernde Teile des Images (z. B. der Anwendungscode) gegen Ende der Datei befinden. Außerdem sollten Sie kleinere Basis-Images verwenden.
5. Aktivieren Sie das Image-Streaming. Mit dieser Funktion können der Pod-Start und der Image-Download beschleunigt werden. Weitere Informationen finden Sie unter Container-Images mithilfe von Image-Streaming abrufen.
6. Das Standarddienstkonto muss die erforderlichen Berechtigungen haben. Wenn Sie Rollen ändern, die dem Standarddienstkonto zugewiesen sind, kann dies zu Unterbrechungen bei Arbeitslasten führen, einschließlich Image-Pulls. Weitere Informationen finden Sie unter Cluster mit Knotendienstkonten ermitteln, denen wichtige Berechtigungen fehlen.
7. Proxykonfigurationen prüfen Wenn zwischen Ihrem GKE-Cluster und einem nicht von Google verwalteten Repository ein Proxy vorhanden ist, kann es zu Latenzen kommen.
8. Prüfen Sie die Drittanbietersoftware. Einige Drittanbietersoftware kann die Bildabrufe beeinträchtigen. Prüfen Sie, ob kürzlich installierte Tools Konflikte verursachen könnten.

Prüfen, ob im Image-Manifest die richtige Architektur verwendet wird

Wenn das Image, das Sie herunterladen möchten, für eine andere Computerarchitektur als die von Ihren Knotenpools verwendete erstellt wurde, schlägt der Image-Pull fehl.

So prüfen Sie, ob in Ihrem Image-Manifest die richtige Architektur verwendet wird:

1. Im Manifest Ihres Images können Sie nachsehen, welche Architektur verwendet wird. Wenn Sie sich beispielsweise ein Docker-Image ansehen möchten, führen Sie den folgenden Befehl aus:

   docker manifest inspect --verbose IMAGE_NAME
   

   Ersetzen Sie IMAGE_NAME durch den Namen des Bildes, das Sie sich ansehen möchten.

   Die Ausgabe sieht etwa so aus:

   ...
   "Platform": {
             "architecture": "amd64",
             "os": "linux"
     }
   ...
   

   In diesem Beispiel ist die unterstützte Architektur amd64.

2. Sehen Sie sich den Maschinentyp an, der für Ihre Knotenpools verwendet wird:

   gcloud container node-pools list --cluster CLUSTER_NAME --location LOCATION
   

   Ersetzen Sie Folgendes:

   • CLUSTER_NAME: Der Name des Clusters, in dem der Pod mit den Fehlern beim Abrufen von Bildern ausgeführt wird.
   • LOCATION: die Compute Engine-Zone oder -Region, in der der Knoten erstellt wurde. Beispiel: us-central1-a oder us-central1.

   Die Ausgabe sieht etwa so aus:

   NAME: example-node-pool
   MACHINE_TYPE: e2-standard-2
   DISK_SIZE_GB: 100
   NODE_VERSION: 1.30.8-gke.1162000
   

   In diesem Beispiel ist der Maschinentyp e2-standard-2.

3. Vergleichen Sie die Werte in den Feldern architecture und MACHINE_TYPE und achten Sie darauf, dass beide Werte kompatibel sind. Wenn das Image beispielsweise die Architektur amd64 hat, ist es mit einem Knotenpool kompatibel, der e2-standard-2 als Maschinentyp verwendet. Wenn der Knotenpool jedoch t2a-standard-1 (einen ARM-basierten Maschinentyp) verwendet, führt dieser Maschinentyp zu einem Fehler.

4. Wenn die Architektur des Images nicht mit dem Maschinentyp des Knotenpools kompatibel ist, erstellen Sie das Image neu, um es auf die erforderliche Architektur auszurichten.

Kompatibilität der Bildschemaversion prüfen

Wenn Sie containerd 2.0 mit einem Docker-Schema-Image der Version 1 verwenden, schlägt das Abrufen von Images fehl, da in containerd 2.0 die Unterstützung für das Abrufen von Docker-Schema 1-Images in GKE 1.33 entfernt wurde. Wenn dieses Problem der Grund für den fehlgeschlagenen Abruf des Images ist, wird möglicherweise die folgende Fehlermeldung angezeigt:

Failed to get converter for "IMAGE_ADDRESS": Pulling Schema 1 images have been deprecated and disabled by default since containerd v2.0. As a workaround you may set an environment variable `CONTAINERD_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE=1`, but this will be completely removed in containerd v2.1.

Um dieses Problem zu beheben, identifizieren und migrieren Sie diese Images. Folgen Sie dazu der Anleitung unter Von Docker-Schema 1-Images migrieren.

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.