Probleme beim Abrufen von Bildern beheben

Auf dieser Seite wird beschrieben, wie Sie Probleme beim Abrufen von Images in Google Kubernetes Engine (GKE) beheben. Wenn Sie Image-Streaming verwenden, finden Sie stattdessen unter Fehlerbehebung beim Image-Streaming weitere Informationen. Auf dieser Seite geht es um das Standard-Pulling von Images.

Diese Seite richtet sich an Anwendungsentwickler, 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 Trusted Cloud by S3NS -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Beim Image-Pull-Prozess ruft Kubernetes und damit GKE Container-Images aus einer Registry ab. Wenn das Abrufen eines Bildes fehlschlägt, kann es sein, dass Ihre App langsam ist oder überhaupt nicht funktioniert.

Auf dieser Seite erfahren Sie, wie Sie Fehler beim Abrufen von Images diagnostizieren können, indem Sie relevante Fehlermeldungen suchen und verstehen. So können Sie feststellen, ob das Abrufen von Images die Ursache dafür ist, dass Ihre App nicht funktioniert. 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, die Netzwerkisolation verwenden, keine Verbindung zur Registry herstellen.
• Image not found in registry (Image nicht in der Registry gefunden): Der angegebene Imagename oder das Tag ist falsch, das Image wurde gelöscht oder die Registry ist nicht verfügbar.
• Leistungseinschränkungen: Eine große Bildgröße, langsame Laufwerks-E/A oder Netzwerküberlastung können zu langsamen Pulls oder Zeitüberschreitungen führen.
• Inkompatible 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 Anleitung zur Fehlerbehebung. Wenn Sie keine Nachricht erhalten haben, arbeiten Sie die folgenden Abschnitte der Reihe nach durch. Wenn das Problem weiterhin besteht, wenden Sie sich an Cloud Customer Care.

Image-Pulls verstehen

Bevor Sie mit der Fehlerbehebung beginnen, sollten Sie sich mit dem Lebenszyklus eines Bildes und den Hosting-Optionen vertraut machen.

Image-Lebenszyklus

Wenn Sie einen Pod erstellen, empfängt 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 Container-Laufzeit, ob das Image vorhanden ist. Das Kubelet prüft auch die Image-Pull-Richtlinie des Pods. Wenn sich das Image nicht im Cache der Container-Laufzeit befindet oder die Image-Pull-Richtlinie dies erfordert, weist das Kubelet die Container-Laufzeit (containerd) an, das angegebene Image aus der Registry abzurufen. Wenn ein Image nicht abgerufen werden kann, kann der Container im Pod nicht gestartet werden.

Nach einem erfolgreichen Image-Pull-Vorgang entpackt die Container-Laufzeit das Image, um ein schreibgeschütztes Basisdateisystem für den Container zu erstellen. Die Containerlaufzeit speichert dieses Image und es bleibt so lange vorhanden, wie darauf verwiesen wird. Wenn keine laufenden Container auf ein Image verweisen, kommt das Image für die Garbage Collection infrage und das Kubelet entfernt es schließlich.

Optionen für das Bild-Hosting

Wir empfehlen, Ihre Bilder mit einer der folgenden Optionen zu hosten:

• Artifact Registry: Artifact Registry ist der vollständig verwaltete Paketmanager von Google. Artifact Registry ist eng in andere Trusted Cloud by S3NS-Dienste eingebunden 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, erfordert aber auch, dass Sie die Registry verwalten. Diese Option ist sinnvoll, 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 Untersuchungen durch, um Fehler beim Abrufen von Images zu diagnostizieren:

1. Pod-Status und ‑Ereignisse ansehen
2. Bedeutung der Statusangaben
3. Mithilfe von Ereignismeldungen können Sie die Ursache für das Fehlschlagen des Image-Pulls ermitteln.
4. Logs im Log-Explorer ansehen

Pod-Status und ‑Ereignisse ansehen

Damit Sie leichter feststellen 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 können Sie mit Kubernetes-Ereignissen die Ursache von Fehlern beim Abrufen von Images ermitteln.

Wenn Sie prüfen möchten, ob Ihr Image-Pull-Vorgang fehlgeschlagen ist, suchen Sie nach Statusmeldungen und lesen Sie dann Ereignismeldungen, indem Sie eine der folgenden Optionen auswählen:

Bedeutung der Status

Die verschiedenen Status werden im Folgenden beschrieben:

• ImagePullBackOff: Das Kubelet konnte das Image nicht abrufen, versucht es aber weiterhin mit einer zunehmenden Verzögerung (oder Backoff) von bis zu fünf Minuten.
• ErrImagePull: Ein allgemeiner, nicht behebbarer Fehler während des Image-Pull-Vorgangs.
• ImageInspectError: Bei der Container-Laufzeit ist ein Problem aufgetreten, als versucht wurde, das Container-Image zu prüfen.
• InvalidImageName: Der Name des in Ihrer Pod-Definition angegebenen Container-Images ist ungültig.
• RegistryUnavailable: Die Registrierung ist nicht zugänglich. Das ist in der Regel ein Problem mit der Netzwerkverbindung.
• SignatureValidationFailed: Die digitale Signatur des Container-Images konnte nicht überprüft werden.

Ereignismeldungen verwenden, um die Ursache für das Fehlschlagen des Image-Pulls zu ermitteln

In der folgenden Tabelle sind Ereignismeldungen aufgeführt, die sich auf Fehler beim Abrufen von Images beziehen, sowie die Schritte zur Fehlerbehebung, die Sie ausführen sollten, wenn eine dieser Meldungen angezeigt wird.

Nachrichten, die sich auf Fehler beim Pullen von Images beziehen, 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 Log-Nachricht 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 Images haben, empfehlen wir Ihnen, den Rest der Seite zu lesen.

Logs im Log-Explorer ansehen

Wenn Sie frühere Ereignisse zum Abrufen von Images untersuchen oder Fehler beim Abrufen von Images mit anderen Komponentenaktivitäten korrelieren möchten, können Sie Logs mit dem Log-Explorer ansehen:

1. Rufen Sie in der Trusted 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, auf dem der Pod mit Image-Pull-Fehlern 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 überprüfen, ob Ihre GKE-Umgebung die richtigen Authentifizierungseinstellungen hat, um Images aus dem Repository abzurufen.

So prüfen Sie, ob Authentifizierungsprobleme das Problem beim Abrufen von Images verursachen:

1. Prüfen Sie, ob Sie Zugriff auf das Bild haben.
2. Prüfen Sie die imagePullSecret-Konfiguration und die Deployment-Spezifikation.
3. Prüfen Sie, ob das Dienstkonto des Knotens aktiv ist.
4. Zugriffsbereich des Knotens für das private Artifact Registry-Repository prüfen
5. Überprüfen Sie die VPC Service Controls-Einstellungen, um auf Artifact Registry zuzugreifen.

Zugriff auf das Bild überprüfen

Wenn ein 403 Forbidden-Fehler beim Abrufen des 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-Typ 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 Authentifizierungsanmeldedaten zum Abrufen von Images erstellen und in allen Bereitstellungen das von Ihnen definierte Secret angeben. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter imagePullSecrets für einen Pod angeben.

Aktivstatus des Knotendienstkontos prüfen

Wenn der Fehler 401 Unauthorized beim Abrufen von Images auftritt, prüfen Sie, ob das Dienstkonto des Knotens aktiv ist. Auch wenn die Berechtigungen richtig konfiguriert sind, wird dieser Fehler angezeigt, wenn das Konto deaktiviert ist. Wählen Sie eine der folgenden Optionen aus, um den aktiven Status des Knotendienstkontos zu prüfen:

Wenn das Dienstkonto deaktiviert ist, aktivieren Sie das Knotendienstkonto.

Zugriffsbereich des Knotens für das private 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 wird möglicherweise ein 401 Unauthorized-Fehler beim Abrufen des Images angezeigt.

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

1. Ermitteln 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 Fehler beim Abrufen des Images aufgetreten ist.

2. Prüfen Sie, ob der im vorherigen Schritt identifizierte Knoten den richtigen Speicherkontext 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 das Abrufen des Images fehl.

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

   Wir empfehlen, den Knotenpool mit dem Bereich 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 den Zugriff auf Lesedaten ermöglicht.

   gke-default

   Erstellen Sie einen Knotenpool mit dem Bereich gke-default:

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --scopes="gke-default"
   

   Ersetzen Sie Folgendes:

   • NODE_POOL_NAME: der Name des neuen Knotenpools.
   • CLUSTER_NAME ist der Name Ihres vorhandenen Clusters.
   • CONTROL_PLANE_LOCATION: Der Compute Engine-Standort der Steuerungsebene des Clusters. Geben Sie für regionale Cluster eine Region und für zonale Cluster eine Zone an.

   devstorage.read_only

   Erstellen Sie einen Knotenpool mit dem Bereich devstorage.read_only:

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --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.
   • CONTROL_PLANE_LOCATION: Der Compute Engine-Standort der Steuerungsebene des Clusters. Geben Sie für regionale Cluster eine Region und für zonale Cluster eine Zone an.

VPC Service Controls-Einstellungen prüfen, um auf Artifact Registry zuzugreifen

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

Netzwerkverbindung untersuchen

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

So prüfen Sie, ob Netzwerkverbindungsprobleme die Ursache für ein Problem beim Abrufen von Images sind:

1. DNS-Auflösung untersuchen
2. Überprüfen Sie die Firewallkonfiguration.
3. Untersuchen Sie die Internetverbindung von externen Registry-Endpunkten.
4. Prüfen Sie, ob die Verbindung zu Google APIs eine Zeitüberschreitung auslöst.

DNS-Auflösung untersuchen

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

Wenn Sie Probleme mit der DNS-Auflösung untersuchen möchten, versuchen Sie Folgendes:

1. Fehlerbehebung bei Metadatenserver Der Metadatenserver des Knotens löst alle DNS-Abfragen auf. Alle Probleme, die diesen Server betreffen, können die Namensauflösung stören, die Verbindung zum Repository verhindern und dazu führen, dass das Pullen des Images fehlschlägt.
2. Wenn Sie Cloud DNS für die DNS-Auflösung verwenden, müssen Sie darauf achten, dass Ihre von Cloud DNS verwalteten privaten Zonen, Weiterleitungszonen, Peering-Zonen und Antwortrichtlinien richtig konfiguriert sind. Fehlkonfigurationen in diesen Bereichen können die DNS-Auflösung stören. 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, prüfen Sie, ob es richtig funktioniert. Hinweise 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 häufig der Fall ist, wenn Sie Netzwerkisolation verwenden), aktivieren Sie privaten Google-Zugriff im vom Cluster verwendeten Subnetzwerk und achten Sie darauf, dass Sie die Netzwerkanforderungen erfüllen. Wenn Sie Cloud NAT verwenden, wird der privater Google-Zugriff automatisch aktiviert.Trusted Cloud by S3NS

Firewallkonfiguration untersuchen

Wenn ein Problem mit Ihrer Firewall dazu führt, dass der Image-Pull 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 Probleme beim Abrufen von Images verursacht, 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 Logs 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 Logs keine Informationen dazu enthalten, wann der Image-Pull fehlgeschlagen ist, erstellen Sie eine vollständige Kopie der Logs:

   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. Sehen Sie sich den Inhalt der Dateien kube-node-installation_status.txt und kube-node-configuration_status.txt an. Wenn in der Ausgabe i/o timeout angezeigt wird, liegt das Problem wahrscheinlich an Ihrer Firewall.

Probleme mit der Firewallkonfiguration beheben

So beheben Sie Probleme mit Ihrer Firewall:

1. Ermitteln und beheben Sie alle Firewallregeln, die den Netzwerkverkehr blockieren. Möglicherweise haben Sie beispielsweise eine Regel, die den Zugriff auf die Registry blockiert, in der Ihr Image gespeichert ist.

   1. VPC-Flusslogs aufrufen:

      1. Rufen Sie in der Trusted 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: die ID Ihres Trusted Cloud Projekts.
         • SUBNET_NAME: Der Name Ihres Subnetzwerks.

         Weitere Informationen finden Sie in der VPC-Dokumentation unter Mit Abfragen auf Flusslogs 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 häufig der Fall ist, wenn Sie Netzwerkisolation verwenden), aktivieren Sie privaten Google-Zugriff im vom Cluster verwendeten Subnetzwerk und achten Sie darauf, dass Sie die Netzwerkanforderungen erfüllen. Wenn Sie Cloud NAT verwenden, wird der privater Google-Zugriff automatisch aktiviert.Trusted Cloud by S3NS

Internetverbindung von externen Registry-Endpunkten untersuchen

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 das Abrufen des Images möglicherweise fehl und Sie sehen einen i/o timeout-Fehler.

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 feststellen, prüfen Sie die VPC-Routen:

1. Rufen Sie in der Trusted Cloud -Console Routen auf.

   Zur Seite „Routes“

2. Sehen Sie sich die Spalte Priorität an und prüfen Sie, ob die Route mit der höchsten Priorität zu einer Quelle führt, die Zugriff auf die Registrierung hat. Routen mit niedrigeren Werten haben Vorrang.

Prüfen, ob die Verbindung zu Google-APIs eine Zeitüberschreitung auslöst

Wenn Sie Netzwerkisolation verwenden, kann es zu einem Fehler kommen, bei dem die Verbindung zu Google APIs und Google-Diensten Zeitüberschreitungen verursacht, was zu einem i/o timeout-Fehler beim Abrufen von Images führt.

Dieser Fehler tritt auf, weil Ihre Knoten beim Versuch, Images aus der Registry abzurufen, keine Verbindung zu einer der folgenden APIs herstellen konnten:

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

Versuchen Sie Folgendes, um sicherzustellen, dass Sie eine Verbindung zu den erforderlichen APIs herstellen können:

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

3. Firewallrichtlinien prüfen:

   1. Rufen Sie in der Trusted Cloud Console die Firewall-Richtlinien auf.

      Zu den Firewall-Richtlinien

   2. Prüfen Sie, ob Sie Regeln haben, die ausgehenden TCP-Traffic an Port 443 zu 199.36.153.4/30, 199.36.153.8/30 oder einem IP-Adressbereich, der von Ihrer ausgewählten Domain für Google APIs und Dienste verwendet wird, blockieren. Die IP-Adressbereiche 199.36.153.4/30 und 199.36.153.8/30 werden für den privater Google-Zugriff bzw. den eingeschränkten Google-Zugriff verwendet. TCP-Traffic auf Port 443 zu diesen Bereichen dient dem Zugriff auf Google APIs und Google-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 Trusted Cloud -Console „VPC-Netzwerke“ auf.

      Zur Seite VPC-Netzwerke

   2. Klicken Sie in der Spalte Name auf default.

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

   4. Sehen Sie sich die Routentabelle 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 (Standardnetzwerk) ist, verwenden Sie diese Route für die VIPs, um auf Google APIs und Google-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.

Untersuchen, 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.

Damit das Kubelet Ihr Image finden kann, versuchen Sie Folgendes:

1. Prüfen Sie das Manifest Ihres Pods und achten Sie darauf, dass der Name Ihres Images und das Image-Tag richtig geschrieben sind. Rechtschreib- oder Formatierungsfehler führen dazu, dass das Abrufen 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, prüfen Sie, 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 Netzwerkisolation verwendet wird, versuchen Sie Folgendes:
   1. Privaten Google-Zugriff aktivieren.
   2. Prüfen Sie, ob Ihr Service-Perimeter richtig konfiguriert ist.

Untersuchen, warum es bei Image-Pulls zu Zeitüberschreitungen oder langsamen Image-Pulls kommt

Wenn Sie ein sehr großes Image für Ihre GKE-Arbeitslast verwenden, kann das Abrufen des Images zu einem Zeitüberschreitungsfehler führen und den Fehler context cancelled verursachen. Bilder haben zwar kein definiertes Größenlimit, der Fehler context cancelled deutet jedoch häufig darauf hin, dass die Größe des Bildes die Ursache ist.

Möglicherweise stellen Sie auch fest, dass das Abrufen von Bildern nicht fehlschlägt, aber viel länger als gewöhnlich dauert. Wenn Sie eine Baseline für Ihre regulären Image-Pull-Zeiten erstellen möchten, sehen Sie sich den Successfully pulled image-Logeintrag an. Die folgende Logmeldung zeigt beispielsweise, dass das Pullen des Images 30,313387996 Sekunden gedauert hat:

Successfully pulled image "IMAGE_ADDRESS" in 30.313387996s.

Timeouts und langsames Abrufen von Images haben viele gemeinsame Ursachen. Versuchen Sie Folgendes, um diese Probleme zu beheben:

1. Auf Probleme mit der Netzabdeckung prüfen Wenn Sie dieses Problem nur in einem bestimmten Zeitraum bemerkt haben, prüfen Sie, ob es Trusted Cloud by S3NS Ausfälle gab.
2. Laufwerksleistung prüfen Langsame Laufwerk-E/A kann die Pull-Zeiten von Images verlängern. Erwägen Sie ein Upgrade auf nichtflüchtige Speicher mit SSDs (pd-ssd) oder die Verwendung größerer Festplatten, um die Leistung zu verbessern. Weitere Informationen finden Sie unter Fehlerbehebung bei Problemen mit der Laufwerksleistung.
3. Verkleinern Sie das Bild. Sie können beispielsweise einige Daten aus den Container-Images in Persistent Volumes verschieben.
4. Nutzen Sie das Image-Caching, um schnelle Pod-Startzeiten zu erzielen. 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 Image-Pull-Zeiten zu minimieren, sollten Sie Ihr Dockerfile so strukturieren, dass häufig geänderte Teile des Images (z. B. Ihr Anwendungscode) am Ende der Datei stehen. Verwenden Sie außerdem kleinere Basis-Images.
5. Aktivieren Sie das Image-Streaming. Diese Funktion kann den Pod-Start und das Herunterladen von Images beschleunigen. Weitere Informationen finden Sie unter Container-Images mithilfe von Image-Streaming abrufen.
6. Prüfen Sie, ob das Standarddienstkonto die erforderlichen Berechtigungen hat. Wenn Sie Rollen ändern, die dem Standarddienstkonto zugewiesen sind, kann dies zu Störungen bei Arbeitslasten führen, einschließlich des Abrufens von Images. Weitere Informationen finden Sie unter Cluster mit Knotendienstkonten identifizieren, denen wichtige Berechtigungen fehlen.
7. Proxykonfigurationen prüfen Wenn ein Proxy zwischen Ihrem GKE-Cluster und einem nicht von Google verwalteten Repository vorhanden ist, kann dies zu Latenz führen.
8. Drittanbietersoftware prüfen Einige Drittanbieter-Software kann das Abrufen von Bildern beeinträchtigen. Prüfen Sie, ob kürzlich installierte Tools Konflikte verursachen.

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

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

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

1. Wenn Sie herausfinden möchten, welche Architektur Ihr Image verwendet, sehen Sie sich das Manifest für Ihr Image an. 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. Prüfen Sie den Maschinentyp, der von Ihren Knotenpools verwendet wird:

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

   Ersetzen Sie Folgendes:

   • CLUSTER_NAME: Der Name des Clusters, auf dem der Pod mit Image-Pull-Fehlern ausgeführt wird.
   • CONTROL_PLANE_LOCATION: Der Compute Engine-Standort der Steuerungsebene des Clusters. Geben Sie für regionale Cluster eine Region und für zonale Cluster eine Zone an.

   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 im Knotenpool jedoch t2a-standard-1 (ein ARM-basierter Maschinentyp) verwendet wird, 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 die erforderliche Architektur zu verwenden.

Kompatibilität der Bildschemaversion prüfen

Wenn Sie containerd 2.0 mit einem Docker-Schema-Image der Version 1 verwenden, schlagen Image-Pulls fehl, da in containerd 2.0 die Unterstützung für das Pullen von Docker-Schema 1-Images in GKE 1.33 entfernt wurde. Wenn dieses Problem die Ursache für den Fehler beim Pullen 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, müssen Sie diese Images identifizieren und migrieren. Folgen Sie dazu der Anleitung unter Von Docker-Schema 1-Images migrieren.

Nächste Schritte

• Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Hilfe, z. B. zu den folgenden Themen:

  • Sie können eine Supportanfrage erstellen, indem Sie sich an Cloud Customer Care wenden.
  • Support von der Community erhalten, indem Sie Fragen auf Stack Overflow stellen und mit dem Tag google-kubernetes-engine nach ähnlichen Problemen suchen. Sie können auch dem #kubernetes-engine-Slack-Kanal beitreten, um weiteren Community-Support zu erhalten.
  • Sie können Fehler melden oder Funktionsanfragen stellen, indem Sie die öffentliche Problemverfolgung verwenden.