Fehler beim Abrufen von Images beheben

Wenn Container in Google Kubernetes Engine (GKE) nicht gestartet werden, sehen Sie möglicherweise Pod-Status wie ErrImagePull oder ImagePullBackOff. Die Ursache für diese Status ist häufig ein Problem beim Abrufen des Images, wenn Kubernetes versucht, das Container-Image aus einer Registry abzurufen. Ein Fehler in diesem Prozess kann dazu führen, dass Ihre Apps nicht gestartet werden oder die Bereitstellung verzögert wird.

Auf dieser Seite erfahren Sie, wie Sie die häufigsten Ursachen für Fehler beim Abrufen von Images diagnostizieren und 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 nicht in der Registry gefunden: Der angegebene Image-Name 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.

Diese Informationen sind wichtig für Anwendungsentwickler, die Bereitstellungsfehler beheben müssen, indem sie Image-Namen, Tags und Architekturen in ihren Manifesten prüfen. Außerdem können Plattformadministratoren und ‑operatoren damit Probleme auf Clusterebene beheben, z. B. das Konfigurieren von Anmeldedaten für das Abrufen von Images für private Registries oder das Beheben von Netzwerkrichtlinien, die den Zugriff auf eine Image-Registry blockieren. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir inCloud de Confiance by S3NS Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Wenn Sie bereits eine bestimmte Ereignismeldung gesehen haben, suchen Sie auf dieser Seite nach der Meldung und folgen Sie den aufgeführten Schritten zur 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-Abrufe 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. Vor dem Abrufen des Images prüft das Kubelet die Containerlaufzeit, um festzustellen, ob das Image vorhanden ist. Das Kubelet prüft auch die Image-Pull-Richtlinie des Pods. Wenn sich das Image nicht im Cache der Containerlaufzeit befindet oder wenn die Image-Abrufrichtlinie dies erfordert, weist das Kubelet die Containerlaufzeit (containerd) an, das angegebene Image aus der Registry abzurufen. Wenn das Abrufen des Images fehlschlägt, kann der Container im Pod nicht gestartet werden.

Nachdem das Image erfolgreich abgerufen wurde, entpackt die Containerlaufzeit das Image, um ein schreibgeschütztes Basisdateisystem für den Container zu erstellen. Die Container-Laufzeit speichert dieses Image und es bleibt so lange vorhanden, wie laufende Container darauf verweisen. Wenn kein laufender Container auf ein Image verweist, wird das Image für die automatische Speicherbereinigung freigegeben und schließlich vom Kubelet entfernt.

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 Cloud de Confiance 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. Ziehen Sie diese Option in Betracht, 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 des Status
3. Mit Ereignismeldungen die Ursache für das Fehlschlagen des Image-Pulls ermitteln
4. Logs im Log-Explorer ansehen

Pod-Status und ‑Ereignisse ansehen

Damit Sie leichter 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 am häufigsten verwendeten Status.

Zusätzlich zu diesen Status helfen Ihnen Kubernetes-Ereignisse, die Ursache von Fehlern beim Abrufen von Images zu finden.

Wenn Sie prüfen möchten, ob das Image-Pulling fehlschlägt, suchen Sie nach Statusmeldungen und lesen Sie dann Ereignismeldungen. Wählen Sie dazu eine der folgenden Optionen aus:

Bedeutung des Status

In den folgenden Beschreibungen erfahren Sie, was die verschiedenen Status bedeuten:

• ImagePullBackOff: Das Kubelet konnte das Image nicht abrufen, versucht es aber mit einer zunehmenden Verzögerung (oder einem Backoff) von bis zu fünf Minuten weiter.
• ErrImagePull: Ein allgemeiner, nicht behebbarer Fehler beim Abrufen des Images.
• ImageInspectError: Die Containerlaufzeit hat beim Versuch, das Container-Image zu prüfen, ein Problem festgestellt.
• InvalidImageName: Der Name des in Ihrer Pod-Definition angegebenen Container-Images ist ungültig.
• RegistryUnavailable: Die Registrierung ist nicht zugänglich. Dies 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 Abrufen von Bildern 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 dem Logeintrag zugeordnet ist. Zum Beispiel NotFound oder Unknown.

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

Logs im Log-Explorer ansehen

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

1. Rufen Sie in der Cloud de Confiance 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 untersuchen

In den folgenden Abschnitten erfahren Sie, wie Sie prüfen, ob Ihre GKE-Umgebung die richtigen Authentifizierungseinstellungen hat, um Images aus dem Repository abzurufen.

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

1. Prüfen Sie, ob Sie Zugriff auf das Bild haben.
2. Prüfen Sie die Konfiguration von imagePullSecret und die Deployment-Spezifikation.
3. Prüfen Sie den Aktivitätsstatus des Knotendienstkontos.
4. Zugriffsbereich des Knotens für das private Artifact Registry-Repository prüfen
5. Prüfen Sie die VPC Service Controls-Einstellungen für den Zugriff auf Artifact Registry.

Zugriff auf das Bild überprüfen

Wenn ein 403 Forbidden-Image-Pull-Fehler auftritt, prüfen Sie, ob die erforderlichen Komponenten auf das Container-Image zugreifen können.

Die Methode zum Prüfen und Zuweisen der erforderlichen Rollen, um den erforderlichen Zugriff zu gewähren, hängt davon ab, in welchem Repository-Typ Ihre Images gespeichert sind. Wählen Sie eine der folgenden Optionen aus, um den Zugriff zu prüfen und zu gewähren:

Konfiguration von „imagePullSecret“ und Deployment-Spezifikation prüfen

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

Aktivstatus des Dienstkontos des Knotens prüfen

Wenn der Fehler 401 Unauthorized beim Abrufen des Images auftritt, prüfen Sie, ob das Dienstkonto des Knotens aktiv ist. Selbst wenn die Berechtigungen korrekt konfiguriert sind, wird dieser Fehler bei einem deaktivierten Konto angezeigt. Wählen Sie eine der folgenden Optionen aus, um den aktiven Status des Knoten-Dienstkontos 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 überprü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 Speicherbereich 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 Pullen 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 Ihres Clusters. Geben Sie eine Region für regionale Cluster oder eine Zone für zonale Cluster 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 Ihres 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, müssen Sie dafür sorgen, 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 Pull-Vorgangs kann die Netzwerkverbindung verhindern, dass der Vorgang abgeschlossen wird.

So prüfen Sie, ob Probleme mit der Netzwerkverbindung die Ursache für ein Problem beim Abrufen von Images sind:

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

DNS-Auflösung untersuchen

Wenn der Image-Pull-Fehler server misbehaving angezeigt wird, kann die DNS-Auflösung die Ursache für den Image-Pull-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. Alle Probleme, die diesen Server betreffen, können die Namensauflösung stören, die Verbindung zum Repository verhindern und dazu führen, dass das Abrufen 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 für das vom Cluster verwendete Subnetzwerk und achten Sie darauf, dass Sie die Netzwerkanforderungen erfüllen. Wenn Sie Cloud NAT verwenden, aktiviertCloud de Confiance by S3NS den privater Google-Zugriff automatisch.

Firewallkonfiguration prüfen

Wenn ein Problem mit Ihrer Firewall dazu führt, dass das Pullen Ihres 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 Probleme beim Abrufen von Images verursacht, gehen Sie so vor:

1. Stellen Sie über SSH eine Verbindung zum Knoten her, auf 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 letzten 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 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. 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 Ihrer Firewall.

Probleme mit der Firewallkonfiguration beheben

Versuchen Sie Folgendes, um Probleme mit Ihrer Firewall zu beheben:

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

   1. Auf VPC-Flusslogs zugreifen:

      1. Rufen Sie in der Cloud de Confiance 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 Projekts in Cloud de Confiance .
         • 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 für das vom Cluster verwendete Subnetzwerk und achten Sie darauf, dass Sie die Netzwerkanforderungen erfüllen. Wenn Sie Cloud NAT verwenden, wird der privater Google-Zugriff automatisch aktiviert.Cloud de Confiance 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 beim Abrufen des Images.

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 Cloud de Confiance -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 Registry 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-Image-Pull-Fehler 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

So können Sie sicherstellen, 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 Google-Diensten zu erreichen.
2. Verwenden Sie eine unterstützte Domain.

3. Prüfen Sie Ihre Firewallrichtlinien:

   1. Rufen Sie in der Cloud de Confiance Console die Seite „Firewallrichtlinien“ 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 Google-Dienste verwendet wird, blockieren. Die IP-Adressbereiche 199.36.153.4/30 und 199.36.153.8/30 werden für den privaten bzw. eingeschränkten Google-Zugriff verwendet. TCP-Traffic auf Port 443 zu diesen Bereichen dient dem Zugriff auf Google APIs und ‑Dienste.

      Wenn Sie solche 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 Cloud de Confiance Console „VPC-Netzwerke“ auf.

      Zur Seite VPC-Netzwerke

   2. Klicken Sie in der Spalte Name auf default.

   3. Klicken Sie auf der VPC-Netzwerk-Detailseite auf den Tab Routen.

   4. Sehen Sie sich die Tabelle mit den Routen 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 Google-Dienste zuzugreifen.

      Wenn Sie eine Standardroute durch eine benutzerdefinierte Route ersetzt haben, deren nächster Hop nicht das Standard-Internetgateway ist, erfüllen Sie die Routinganforderungen für Google APIs und Google-Dienste, 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 des Images und das Image-Tag richtig geschrieben sind. Rechtschreib- oder Formatierungsfehler führen dazu, dass das Image nicht abgerufen werden kann.
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 es mit den folgenden Lösungen:
   1. Privaten Google-Zugriff aktivieren
   2. Prüfen Sie, ob Ihr Dienstperimeter 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 beim Pull-Vorgang für das Image ein Zeitüberschreitungsfehler auftreten und ein context cancelled-Fehler verursacht werden. Obwohl es für Bilder keine definierte Größenbeschränkung gibt, deutet der Fehler context cancelled oft darauf hin, dass die Größe des Bildes die Ursache ist.

Möglicherweise stellen Sie auch fest, dass das Pullen von Images nicht fehlschlägt, aber viel länger als gewöhnlich dauert. Wenn Sie eine Baseline für Ihre regulären Image-Pull-Zeiten haben 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 Bildern haben viele gemeinsame Ursachen. Versuchen Sie Folgendes, um diese Probleme zu beheben:

1. Prüfen Sie, ob Ausfälle vorliegen. Wenn Sie dieses Problem nur in einem bestimmten Zeitraum bemerkt haben, prüfen Sie, ob es Cloud de Confiance by S3NS Ausfälle gab.
2. Laufwerksleistung prüfen Langsame Laufwerk-E/A kann die Zeiten für das Pullen von Images verlängern. Erwägen Sie ein Upgrade auf nichtflüchtige Speicher mit SSDs (pd-ssd) oder die Verwendung größerer Laufwerke, um die Leistung zu verbessern. Weitere Informationen finden Sie unter Probleme mit der Laufwerksleistung beheben.
3. Bildgröße verringern Beispielsweise können Sie einige Daten aus den Container-Images in nichtflüchtige Volumes verschieben.
4. Nutzen Sie das Image-Caching, um die Startzeiten von Pods zu 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 Zeiten für das Pullen von Images 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, und kleinere Basis-Images verwenden.
5. Aktivieren Sie das Image-Streaming. Diese Funktion kann den Pod-Start und den Image-Download 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. Proxy-Konfigurationen prüfen Wenn sich zwischen Ihrem GKE-Cluster und einem nicht von Google verwalteten Repository ein Proxy befindet, kann dies zu Latenz führen.
8. Drittanbieter-Software prüfen Einige Drittanbieter-Software kann das Herunterladen von Bildern beeinträchtigen. Prüfen Sie, ob kürzlich installierte Tools Konflikte verursachen könnten.

Prüfen, ob im Bildmanifest 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-Abruf fehl.

So prüfen Sie, ob Ihr Image-Manifest die richtige Architektur verwendet:

1. Um zu prüfen, 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 Images, 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 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 Ihres 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 wurde, würde dieser Maschinentyp einen Fehler verursachen.

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-Abrufe 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 die Ursache für den Fehler beim Image-Abruf 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 gemäß 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, können Sie Support anfordern. Dort erhalten Sie unter anderem Hilfe zu den folgenden Themen:

  • Supportanfrage stellen, 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 Probleme oder Feature Requests über die öffentliche Problemverfolgung melden.