Probleme mit Cloud Run beheben

Auf dieser Seite wird beschrieben, wie Sie Fehler beheben können, die bei der Verwendung von Cloud Run auftreten können. Personalized Service Health veröffentlicht alle Cloud Run-Vorfälle, die auf der zugrunde liegenden Google Cloud Infrastruktur beruhen, um Google Cloud Dienstunterbrechungen zu erkennen, die sich auf Ihre Projekte auswirken. Sie sollten auch Benachrichtigungen für Personalized Service Health-Ereignisse einrichten. Informationen zu Vorfällen, die alle Google Cloud Dienste betreffen, finden Sie im Google Cloud Service Health-Dashboard.

Prüfen Sie, ob Probleme vorhanden sind, oder eröffnen Sie neue Probleme in der öffentlichen Problemverfolgung.

Informationen zu anderen Fehlermeldungen, die auf dieser Seite nicht aufgeführt sind, finden Sie unter Bekannte Probleme in Cloud Run. Wenn Sie auch nach dem Befolgen der Schritte in diesem Leitfaden weiterhin Fehler erhalten, wenden Sie sich an den Support.

In den folgenden Abschnitten finden Sie Informationen zur Behebung von Problemen in Cloud Run:

Bereitstellungsfehler

In diesem Abschnitt werden die häufigsten Bereitstellungsfehler in Cloud Run und Methoden zur Fehlerbehebung beschrieben.

Container konnte nicht gestartet werden

Der folgende Fehler tritt auf, wenn Sie versuchen, die Bereitstellung durchzuführen:

Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Prüfen Sie, ob Sie Ihr Container-Image lokal ausführen können. Wenn Ihr Container-Image nicht lokal ausgeführt werden kann, müssen Sie das Problem zuerst lokal diagnostizieren und beheben.

  2. Prüfen Sie, ob Ihr Container Anfragen auf dem richtigen Port überwacht. Ihr Container muss eingehende Anfragen auf dem Port überwachen, der von Cloud Run definiert und in der Umgebungsvariable PORT angegeben ist. Eine Anleitung zum Angeben des Ports finden Sie unter Container für Dienste konfigurieren.

  3. Prüfen Sie, ob Ihr Container alle Netzwerkschnittstellen überwacht, die in der Regel als 0.0.0.0 angezeigt werden. Ihr Container sollte nicht 127.0.0.1 überwachen.

  4. Prüfen Sie, ob Ihr Container-Image für den 64-Bit-Linux kompiliert wird, wie gemäß dem Containerlaufzeitvertrag erforderlich.

  5. Verwenden Sie Cloud Logging, um in stdout- oder stderr-Logs nach Anwendungsfehlern zu suchen. Sie können auch nach Abstürzen suchen, die in Stackdriver Error Reporting erfasst wurden.

    Möglicherweise müssen Sie den Code oder die Überarbeitungseinstellungen aktualisieren, um Fehler oder Abstürze zu beheben. Sie können auch Probleme mit Ihrem Dienst lokal beheben.

Fehler beim Containerimport

Der folgende Fehler tritt auf, wenn Sie versuchen, die Bereitstellung durchzuführen:

The service has encountered an error during container import. Please try again later. Resource readiness deadline exceeded.

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Das Dateisystem des Containers darf keine Nicht-UTF8-Zeichen enthalten.

  2. Einige Windows-basierte Docker-Images verwenden Fremdebenen. Die Steuerungsebene von Cloud Run unterstützt keine fremden Ebenen. Zur Behebung des Fehlers können Sie versuchen, das Flag --allow-nondistributable-artifacts im Docker-Daemon festzulegen.

Die Funktion wird nicht unterstützt

Der folgende Fehler tritt auf, wenn Sie die Cloud Run Admin API aufrufen:

The feature is not supported in the declared launch stage

Dieser Fehler tritt auf, wenn Sie die Cloud Run Admin API direkt aufrufen und ein Betafeature ohne Angabe einer Startphasenannotation oder -feld verwenden.

Fügen Sie das Feld „launch_stage“ in die Anfragen ein, um dieses Problem zu beheben.

In den folgenden Beispielen wird gezeigt, wie Sie beim Verwenden der REST API v1 oder v2 Referenzen für die Einführungsphase hinzufügen:

Nutzer root nicht gefunden

Der folgende Fehler tritt auf, wenn die vom Kunden verwalteten Verschlüsselungsschlüssel mit einem --key-Parameter angegeben werden:

ERROR: "User \"root\""not found in /etc/passwd

Geben Sie im Dockerfile USER 0 anstelle von USER root an, um dieses Problem zu beheben.

Compute Engine-Standarddienstkonto wurde gelöscht

Der folgende Fehler tritt während der Bereitstellung auf:

ERROR: (gcloud.run.deploy) User EMAIL_ADDRESS does not have permission to access namespace NAMESPACE_NAME (or it may not exist): Permission 'iam.serviceaccounts.actAs' denied on service account PROJECT_NUMBER-compute@developer.gserviceaccount.com (or it may not exist).

Dieses Problem tritt in einem der folgenden Szenarien auf:

  • Das Standard-Compute Engine-Dienstkonto ist im Projekt nicht vorhanden und mit dem Flag --service-account wurde kein Dienstkonto angegeben.

  • Der Entwickler oder das Hauptkonto, der den Dienst bereitstellt, hat nicht die erforderlichen Berechtigungen für das Standarddienstkonto von Compute Engine für die Bereitstellung.

So lösen Sie dieses Problem:

  1. Geben Sie mit dem Flag --service-account ein Dienstkonto an:

    gcloud run services update SERVICE_NAME --service-account SERVICE_ACCOUNT

  2. Prüfen Sie, ob das von Ihnen angegebene Dienstkonto die Berechtigungen nötig für die Bereitstellung hat.

So prüfen Sie, ob der Compute Engine-Standarddienstagent in Ihrem Google Cloud -Projekt vorhanden ist:

  1. Rufen Sie in der Google Cloud Console die Seite Berechtigungen für die Identitäts- und Zugriffsverwaltung auf:

    Zur Seite "Berechtigungen"

  2. Klicken Sie auf das Kästchen Von Google bereitgestellte Rollenzuweisungen einschließen.

  3. Suchen Sie in der Liste Hauptkonten die ID des Compute Engine-Dienst-Agents, der das Format PROJECT_NUMBER-compute@developer.gserviceaccount.com verwendet.

Probleme mit dem Cloud Build-Dienstkonto

Der folgende Fehler tritt bei Quellbereitstellungen auf, wenn das Cloud Build-Dienstkonto nicht die erforderlichen Berechtigungen hat oder deaktiviert ist:

ERROR: (gcloud.run.deploy) NOT_FOUND: Build failed. The service has encountered an internal error. Please try again later. This command is authenticated as EMAIL_ADDRESS which is the active account specified by the [core/account] property.

Cloud Build hat das Standardverhalten für die Verwendung von Dienstkonten durch Cloud Build in neuen Projekten geändert. Weitere Informationen finden Sie unter Änderung des Cloud Build-Standarddienstkontos. Aufgrund dieser Änderung verwenden neue Projekte, die zum ersten Mal aus Quellcode in Cloud Run bereitgestellt werden, möglicherweise ein Cloud Build-Standarddienstkonto mit unzureichenden Berechtigungen für die Bereitstellung aus Quellcode.

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

Cloud Run-Dienst-Agent fehlt die Berechtigung zum Lesen des Images

Der folgende Fehler tritt auf, wenn Sie versuchen, aus einem Projekt mit einem in der Artifact Registry gespeicherten Image bereitzustellen und dabei die gcr.io-Domain in einem anderen Projekt verwenden:

Google Cloud Run Service Agent must have permission to read the image, gcr.io/PROJECT-ID/IMAGE-NAME. Ensure that the provided container image URL is correct and that above account has permission to access the image. If you just enabled the Cloud Run API, the permissions might take a few minutes to propagate. Note that PROJECT-ID/IMAGE-NAME is not in project PROJECT-ID-2. Permission must be granted to the Google Cloud Run Service Agent from this project.

Möglicherweise wird auch der folgende Fehler angezeigt, wenn Sie versuchen, aus einem Projekt mit einem Image bereitzustellen, das in der Artifact Registry in einem anderen Projekt gespeichert ist:

ERROR: (gcloud.run.deploy) PERMISSION_DENIED: User must have permission to read
the image, REGION.pkg.dev/PROJECT_ID/ARTIFACT_REGISTRY_REPO/IMAGE:latest. Ensure that the provided container image URL is correct
and that the above account has permission to access the image. If you just enabled
the Cloud Run API, the permissions might take a few minutes to propagate. Note
that the image is from project PROJECT_ID, which is not the same as
this project PROJECT_ID.

Führen Sie die folgenden Empfehlungen zur Problembehebung aus, um das Problem zu beheben:

  • Folgen Sie der Anleitung zum Bereitstellen von Container-Images aus anderen Google Cloud -Projekten, damit Ihre Hauptkonten die erforderlichen Berechtigungen haben.

  • Dieses Problem kann auch auftreten, wenn sich das Projekt in einem VPC Service Controls-Perimeter mit einer Einschränkung für die Cloud Storage API befindet, die Anfragen vom Cloud Run-Dienst-Agent verbietet. So lösen Sie das Problem:

    1. Öffnen Sie den Log-Explorer in der Google Cloud -Console. (Verwenden Sie nicht die Seite Logs auf der Cloud Run-Seite):

      Zum Log-Explorer

    2. Geben Sie in das Abfragefeld den folgenden Text ein:

      protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
severity=ERROR
protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"
protoPayload.authenticationInfo.principalEmail="service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com"

    3. Wenn Sie nach der Verwendung dieser Abfrage Logeinträge sehen, prüfen Sie die Logeinträge, um festzustellen, ob Sie Ihre VPC Service Controls-Richtlinien aktualisieren müssen. Dies kann darauf hinweisen, dass Sie service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com einer vorhandenen Zugriffsrichtlinie hinzufügen müssen.

Fehlende Berechtigungen für Quelldeployments

Bei der Bereitstellung aus der Quelle können die folgenden Fehler auftreten:

ERROR: (gcloud.run.deploy) EMAIL_ADDRESS does not have permission
to access namespaces instance PROJECT_ID (or it may not exist): Google
Cloud Run Service Agent does not have permission to get access tokens for
the service account SERVICE_ACCOUNT. Please give SERVICE_ACCOUNT
permission iam.serviceAccounts.getAccessToken on the service account.

Alternatively, if the service account is unspecified or in the same project you
are deploying in, ensure that the Service Agent is assigned the Google
Cloud Run Service Agent role roles/run.serviceAgent. This
command is authenticated as EMAIL_ADDRESS, which is the active account
specified by the [core/account] property.

Jeder Cloud Run-Dienst ist mit einem Dienstkonto verknüpft, das als Identität dient, wenn der Dienst auf andere Ressourcen zugreift. Dieses Dienstkonto kann das Standarddienstkonto (PROJECT_NUMBER-compute@developer.gserviceaccount.com) oder ein vom Nutzer verwaltetes Dienstkonto sein.

In Umgebungen, in denen mehrere Dienste auf verschiedene Ressourcen zugreifen, können Sie anstelle des Standarddienstkontos dienstspezifische Identitäten mit verschiedenen nutzerverwalteten Dienstkonten verwenden.

Um dieses Problem zu beheben, weisen Sie dem Bereitstellerkonto die Rolle Dienstkontonutzer (roles/iam.serviceAccountUser) für das Dienstkonto zu, das als Dienstidentität verwendet wird. Diese vordefinierte Rolle enthält die Berechtigung iam.serviceAccounts.actAs, die zum Anhängen eines Dienstkontos an den Dienst oder die Überarbeitung erforderlich ist. Ein Nutzer, der ein vom Nutzer verwaltetes Dienstkonto erstellt, erhält automatisch die Berechtigung iam.serviceAccounts.actAs. Anderen Bereitstellern muss diese Berechtigung jedoch von dem Nutzer gewährt werden, der das vom Nutzer verwaltete Dienstkonto erstellt.

Weitere Informationen zu den Zugriffsanforderungen für neu erstellte Dienstkonten finden Sie unter Empfehlungen zum Erstellen dedizierter Dienstkonten erhalten.

Der Nutzer hat nicht die erforderlichen Berechtigungen, um Quellbereitstellungen abzuschließen.

Der folgende Fehler tritt auf, wenn dem Konto des Bereitstellers die erforderlichen Berechtigungen für Ihr Projekt fehlen:

ERROR: (gcloud.run.deploy) 403 Could not upload file EMAIL_ADDRESS does
not have storage.objects.create access to the Google Cloud Storage object. Permission storage.objects.create denied on resource (or it may not exist). This
command is authenticated as EMAIL_ADDRESS which is the active account.

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen (Identity and Access Management) zuzuweisen, um diesen Fehler zu beheben:

Fehler beim Bereitstellen eines Cloud Run-Dienstes aus anderen Google Cloud Projekten

Der folgende Fehler tritt auf, wenn Sie einen Cloud Run-Dienst aus einem Quellprojekt in einem Zielprojekt bereitstellen:

Failed to create service.
Operation failed due to missing permissions.

Google Cloud Run Service Agent does not have permission to get access
tokens for the service account SERVICE_ACCOUNT. Please give
SERVICE_ACCOUNT permission iam.serviceAccounts.getAccessToken
on the service account. Alternatively, if the service account is unspecified or
in the same project you are deploying in, ensure that the Service Agent is
assigned the Google Cloud Run Service Agent role roles/run.serviceAgent.

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Weisen Sie die Rolle Dienstkontonutzer (roles/iam.serviceAccountUser) für das Dienstkonto zu, das Sie als Dienstidentität in Ihrem Zielprojekt verwenden.

  2. Weisen Sie dem Cloud Run-Dienstkonto im Zielprojekt die Rolle Ersteller von Dienstkonto-Tokens (roles/iam.serviceAccountTokenCreator) zu. Fügen Sie die E-Mail-Adresse des Cloud Run-Dienst-Agents (service-PROJECT_NUMBER@SERVICE_DOMAIN.iam.gserviceaccount.com) als Hauptkonto aus dem Quellprojekt hinzu.

  3. Deaktivieren Sie die Organisationsrichtlinie iam.disableCrossProjectServiceAccountUsage.

Eine ausführliche Anleitung finden Sie unter Dienstidentität für Dienste konfigurieren.

Fehler beim Bereitstellen von Python-Quellcode in Cloud Run

Wenn Sie einen Cloud Run-Dienst aus dem Quellcode mit der Python-Laufzeit bereitstellen, tritt einer der folgenden Fehler auf:

  • Revision REVISION_NAME is not ready and cannot serve traffic.
The user provided container failed to start and listen on port defined by PORT=8080
environment variable within the allocated timeout. This can happen if the port is
misconfigured or if the timeout is too short. The healthcheck timeout can be extended.
  • Die Bereitstellung wird mit HTTP 500-Fehlercodes in den Logs abgeschlossen.

Das Python-Buildpack legt den Standard-Einstiegspunkt für Cloud Run-Quellbereitstellungen fest. Für Python-Version 3.13 und höher legt das Python-Buildpack den Einstiegspunkt basierend auf der Webdienstkonfiguration in Ihrer requirements.txt-Datei fest. Wenn Sie in der Datei requirements.txt keinen Webserver oder kein Framework angeben oder Python-Version 3.12 oder früher verwenden, legt das Python-Buildpack den Standard-Einstiegspunkt auf gunicorn -b :8080 main:app fest. Weitere Informationen finden Sie unter Python-Anwendung erstellen.

Sie haben mehrere Möglichkeiten, dieses Problem zu beheben. Sie können beispielsweise einen der folgenden Webserver in Ihrer requirements.txt-Datei angeben:

  • gunicorn:

      # https://pypi.org/project/gunicorn/
  gunicorn==21.2.0

  • fastapi und uvicorn:

    
# https://pypi.org/project/fastapi
fastapi[standard]==0.116.1

# https://pypi.org/project/uvicorn
uvicorn==0.35.0

Alternativ können Sie einen der folgenden Schritte ausführen, um Bereitstellungsfehler zu beheben:

  • Geben Sie den Einstiegspunkt mit dem folgenden Befehl zum Bereitstellen der Quelle an:

    gcloud run deploy SERVICE --source .  --set-build-env-vars GOOGLE_ENTRYPOINT="ENTRYPOINT"

    Ersetzen Sie Folgendes:

    • SERVICE: Der Name des Dienstes, für den Sie die Bereitstellung ausführen möchten.
    • ENTRYPOINT: Der Standardeinstiegspunkt, den Sie für Ihren Quellcode verwenden möchten.

  • Verwenden Sie eine Procfile, um einen Einstiegspunkt festzulegen.

Schaltungsfehler

In diesem Abschnitt sind mögliche Probleme mit Schaltung sowie Vorschläge zu deren Behebung aufgeführt.

HTTP 404: Nicht gefunden

Das folgende Problem tritt während der Schaltung auf:

`HTTP 404`:Not found

HTTP 404-Fehler können in den folgenden Szenarien auftreten:

  1. Bei einer falschen Anfrage-URL oder einem falschen Anwendungscode werden 404-Fehler zurückgegeben. So beheben Sie das Problem:

    1. Prüfen Sie, ob die angeforderte URL korrekt ist. Sie können die URL entweder auf der Dienstdetailseite in der Google Cloud -Konsole oder durch Ausführen des folgenden Befehls überprüfen:

      gcloud run services describe SERVICE_NAME | grep URL

    2. Prüfen Sie, wo Ihre App 404-Fehlercodes zurückgibt. Wenn Ihre Anwendung 404 zurückgibt, finden Sie das in Cloud Logging. Achten Sie außerdem darauf, dass die App bei lokaler Ausführung keinen 404-Fehlercode zurückgibt.

    3. Achten Sie darauf, dass Ihre App den konfigurierten Port nicht überwacht, bevor sie Anfragen empfangen kann.

  2. Die Anfrage erreicht den Container nicht, was in den folgenden Szenarien zu einem 404-Fehler führt:

    In beiden Szenarien finden Sie den Fehler 404 nicht in Cloud Logging, auch wenn Sie den folgenden Filter anwenden:

    resource.type="cloud_run_revision"
log_name="projects/PROJECT_ID/logs/run.googleapis.com%2Frequests"
httpRequest.status=404

  3. Bei den gleichen Einstellungen für eingehenden Traffic kann die Anfrage von VPC Service Controls basierend auf dem Kontext des Aufrufers einschließlich Projekt und IP-Adresse blockiert werden. So prüfen Sie einen VPC Service Controls-Richtlinienverstoß:

    1. Öffnen Sie den Log-Explorer in der Google Cloud Console:

      Zum Log-Explorer

    2. Geben Sie in das Abfragefeld den folgenden Text ein:

      resource.type="audited_resource"
log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy"
resource.labels.method="run.googleapis.com/HttpIngress"

    3. Wenn Sie nach der Verwendung dieser Abfrage Logeinträge sehen, prüfen Sie die Logeinträge, um festzustellen, ob Sie Ihre VPC Service Controls-Richtlinien aktualisieren müssen.

  4. Mit einem Load Balancer über die Python-Laufzeit auf Ihren Dienstendpunkt zugreifen. Um dieses Problem zu beheben, prüfen Sie die URL-Maske für Ihren Load Balancer und achten Sie darauf, dass der URL-Pfad, den Sie für den Load Balancer angeben, mit dem Pfad in Ihrem Python-Quellcode übereinstimmt.

Keine verfügbaren Containerinstanzen

Der folgende Fehler tritt während der Schaltung auf:

HTTP 429
The request was aborted because there was no available instance.
The Cloud Run service might have reached its maximum container instance
limit or the service was otherwise not able to scale to incoming requests.
This might be caused by a sudden increase in traffic, a long container startup time or a long request processing time.

Um dieses Problem zu beheben, überprüfen Sie den Messwert Anzahl der Container-Instanzen für Ihren Dienst und ziehen Sie eine Erhöhung dieses Limits in Betracht, wenn sich Ihre Nutzung dem Maximum nähert. Weitere Informationen finden Sie unter Maximale Anzahl von Instanzen für Dienste festlegen. Wenn Sie weitere Instanzen benötigen, fordern Sie eine Kontingenterhöhung an.

Cloud Run konnte die Trafficrate nicht verwalten

Der folgende Fehler tritt entweder während der Bereitstellung oder auf, wenn der Dienst das maximale Limit für Containerinstanzen noch nicht erreicht hat:

HTTP 500
The request was aborted because there was no available instance

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Gehen Sie die folgenden möglichen Ursachen durch:

    • Ein starker Anstieg des Traffics.
    • Eine lange Kaltstartzeit.
    • Eine lange Verarbeitungszeit für Anfragen oder eine plötzliche Erhöhung der Verarbeitungszeit für Anfragen.
    • Der Dienst erreicht das maximale Limit für Containerinstanzen (HTTP 429).
    • Temporäre Faktoren, die dem Cloud Run-Dienst zugeordnet sind.

  2. Implementieren Sie exponentiellen Backoff und Wiederholungsversuche für Anfragen, die der Client nicht verwerfen darf. Eine kurze und plötzliche Erhöhung des Traffics oder der Verarbeitungszeit für Anfragen ist möglicherweise nur in Cloud Monitoring sichtbar, wenn Sie die Auflösung auf 10 Sekunden heranzoomen.

  3. Wenn die Ursache des Problems ein Zeitraum erhöhter vorübergehender Fehler ist, der ausschließlich Cloud Run zugeordnet ist, wenden Sie sich an den Support.

Cloud Run-Instanz kann nicht gestartet werden

Der folgende Fehler tritt während der Schaltung auf:

HTTP 500
The request failed because the instance could not start successfully.

Dieser Fehler tritt auf, wenn der Container nicht innerhalb des konfigurierten Zeitraums gestartet werden kann und den Status „Healthy“ erreicht. Dafür kann es mehrere Ursachen geben. Ein häufiger Grund ist, dass der Container nicht auf ein erforderliches Secret aus Secret Manager zugreifen kann.

Beachten Sie bei der Fehlerbehebung Folgendes:

  1. IAM-Berechtigungen prüfen: Prüfen Sie, ob Ihr Cloud Run-Dienstkonto die Rolle Zugriffsperson für Secret Manager-Secret (roles/secretmanager.secretAccessor) für das Secret hat, auf das Sie zugreifen möchten.

  2. Prüfen Sie den Secret-Pfad: Achten Sie darauf, dass Sie in der Konfiguration Ihrer Anwendung den richtigen Secret-Namen und die richtige Version angeben.

  3. Netzwerkkonfiguration prüfen: Wenn Sie einen VPC Service Controls-Perimeter oder Firewallregeln verwenden, achten Sie darauf, dass Sie ausgehenden Traffic zu secretmanager.googleapis.com zulassen.

  4. Effektive Logs ausgeben: Fügen Sie dem Startprozess Ihrer Anwendung Logging hinzu, insbesondere beim Abrufen von Secrets, um bestimmte Fehler zu diagnostizieren.

Vorgang nicht implementiert

Der folgende Fehler tritt auf, wenn Sie beim Aufrufen Ihres Cloud Run-Jobs eine falsche REGION angeben, z. B. wenn Sie einen Job in der Region asia-southeast1 bereitstellen und ihn mit southeast1-asia oder asia-southeast aufrufen:

HTTP 501
Operation is not implemented, or supported, or enabled.

Eine Liste der unterstützten Regionen finden Sie unter Cloud Run-Standorte.

Standardanmeldedaten nicht gefunden

Der folgende Fehler tritt auf, wenn Ihre Anwendung aufgrund fehlender Dateien, ungültiger Anmeldedatenpfade oder falscher Zuweisungen von Umgebungsvariablen nicht richtig authentifiziert wird:

HTTP 503: System.InvalidOperationException System.InvalidOperationException your Default
credentials were not found.

So lösen Sie dieses Problem:

  1. Installieren und initialisieren Sie die gcloud CLI.

  2. Richten Sie Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) mit den Anmeldedaten ein, die mit Ihrem Google-Konto verknüpft sind. ADC konfigurieren mit:

      gcloud auth application-default login

    Ein Anmeldebildschirm wird angezeigt. Nach der Anmeldung werden Ihre Anmeldedaten in der lokalen Anmeldedatendatei für ADC gespeichert.

  3. Verwenden Sie die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS, um den Speicherort einer JSON-Datei mit Anmeldedaten in Ihrem Google Cloud -Projekt anzugeben.

    Weitere Informationen finden Sie unter Standardanmeldedaten für Anwendungen einrichten.

Containerinstanzen überschreiten die Speicherlimits

Der folgende HTTP 500- oder HTTP 503-Fehler tritt während der Schaltung in Cloud Logging auf:

While handling this request, the container instance was found to be using too much memory and was terminated. This is likely to cause a new container instance to be used for the next request to this revision. If you see this message frequently, you may have a memory leak in your code or may need more memory. Consider creating a new revision with more memory.

So lösen Sie dieses Problem:

  1. Ermitteln Sie, ob Ihre Containerinstanzen den verfügbaren Arbeitsspeicher überschreiten. Suchen Sie in den varlog/system-Logs nach ähnlichen Fehlern.
  2. Wenn die Instanzen zu groß für den verfügbaren Speicher sind, sollten Sie vielleicht das Speicherlimit erhöhen.

In Cloud Run werden auf das lokale Dateisystem geschriebene Dateien auf den verfügbaren Speicher angerechnet. Dies gilt auch für alle Logdateien, die in andere Speicherorte als /var/log/* und /dev/log geschrieben werden.

Einige Anfragen können aufgrund der hohen Gleichzeitigkeitseinstellung nicht verarbeitet werden

Der folgende Fehler tritt auf, wenn Ihre Containerinstanzen eine hohe CPU-Auslastung zum Verarbeiten von Anfragen verwenden und daher nicht alle Anfragen verarbeiten können:

HTTP 503
The Cloud Run service probably has reached its maximum container instance limit. Consider increasing this limit.

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Erhöhen Sie die maximale Anzahl von Containerinstanzen für Ihren Dienst.

  2. Verringern Sie die Gleichzeitigkeit des Dienstes. Weitere Informationen finden Sie unter Maximale Anzahl gleichzeitiger Anfragen pro Instanz festlegen.

Cloud Logging-Fehler im Zusammenhang mit abgebrochenen ausstehenden Warteschlangenanfragen

Einer der folgenden Fehler tritt auf, wenn Cloud Run nicht schnell genug skaliert wird, um den Traffic zu verwalten:

  • The request was aborted because there was no available instance:
severity=WARNING ( Response code: 429 ) Cloud Run cannot
scale due to the max-instances limit you set
during configuration.

  • severity=ERROR ( Response code: 500 ) Cloud Run intrinsically
cannot manage the rate of traffic.

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Beheben Sie die Ursachen, die zu Skalierungsfehlern führen können, z. B.:

    • Ein starker Anstieg des Traffics.
    • Lange Kaltstartzeit.
    • Lange Verarbeitungszeit für Anfragen.
    • Hohe Fehlerrate im Quellcode.
    • Das maximale Instanzlimit wird erreicht. Das System kann daher nicht weiter skaliert werden.
    • Temporäre Faktoren, die dem Cloud Run-Dienst zugeordnet sind.

    Weitere Informationen zum Beheben von Skalierungsproblemen und zur Leistungsoptimierung finden Sie unter Allgemeine Entwicklungstipps.

  2. Lassen Sie bei HTTP-Trigger-basierten Diensten oder Funktionen den Client exponentiellen Backoff und Wiederholungen für Anfragen implementieren, die nicht verworfen werden dürfen. Wenn Sie Dienste über Workflows auslösen, können Sie dafür die try/retry-Syntax verwenden.

  3. Für Hintergrund- oder ereignisgesteuerte Dienste oder Funktionen unterstützt Cloud Run mindestens einmalige Übermittlung. Auch wenn die Wiederholung nicht explizit aktiviert wird, wird das Ereignis von Cloud Run automatisch noch einmal gesendet und die Ausführung wird wiederholt. Weitere Informationen finden Sie unter Ereignisgesteuerte Funktionen wiederholen.

  4. Bei Problemen mit Kaltstarts können Sie Mindestinstanzen konfigurieren, um die Anzahl der Kaltstarts zu reduzieren. Dies hat jedoch höhere Abrechnungskosten zur Folge.

  5. Wenden Sie sich an den Support, wenn die Ursache des Problems eine Periode erhöhter transienter Fehler ist, die ausschließlich Cloud Run zugeschrieben werden, oder wenn Sie Unterstützung bei Ihrem Problem benötigen.

Von Google entfernte Identitätstokensignatur

Der folgende Fehler tritt während der Entwicklungs- und Testphasen auf:

SIGNATURE_REMOVED_BY_GOOGLE

Dieser Fehler kann in den folgenden Szenarien auftreten:

  • Der Nutzer meldet sich über die Google Cloud CLI oder Cloud Shell an.

  • Der Nutzer generiert ein ID-Token mit gcloud-Befehlen.

  • Der Nutzer versucht, das ID-Token zu verwenden, um einen nicht öffentlichen Cloud Run-Dienst aufzurufen.

Das ist das erwartete Standardverhalten. Google entfernt die Tokensignatur aus Sicherheitsgründen, um zu verhindern, dass ein nicht öffentlicher Cloud Run-Dienst ID-Tokens wiedergibt, die auf diese Weise generiert wurden.

Rufen Sie zur Behebung dieses Problems Ihren privaten Dienst mit einem neuen ID-Token auf. Weitere Informationen finden Sie unter Privaten Dienst testen.

OpenBLAS-Warnung in Logs

Wenn Sie OpenBLAS-basierte Bibliotheken wie NumPy mit der Ausführungsumgebung der ersten Generation verwenden, wird in Ihren Logs möglicherweise die folgende Warnung angezeigt:

OpenBLAS WARNING - could not determine the L2 cache size on this system,
assuming 256k`

Die OpenBLAS-Warnung wird angezeigt, weil die von der Ausführungsumgebung der ersten Generation verwendete Container-Sandbox keine Hardwarefunktionen auf niedriger Ebene zur Verfügung stellt. Diese Warnung hat keine Auswirkungen auf Ihren Dienst. Wenn Sie OpenBLAS-Warnungen in Logeinträgen vermeiden möchten, wechseln Sie zur Ausführungsumgebung der zweiten Generation.

Spark scheitert beim Abrufen der IP-Adresse des Rechners, an den gebunden werden soll

Wenn Spark beim Abrufen der IP-Adresse des Bindungscomputers fehlschlägt, tritt einer der folgenden Fehler auf:

assertion failed: Expected hostname (not IP) but got <IPv6 ADDRESS>
 
assertion failed: Expected hostname or IPv6 IP enclosed in [] but got <IPv6 ADDRESS>

Um dieses Problem zu beheben, legen Sie die Umgebungsvariable SPARK_LOCAL_IP in Ihrem Dockerfile auf 127.0.0.1 fest, z. B. ENV SPARK_LOCAL_IP="127.0.0.1". Wenn Sie die Umgebungsvariable SPARK_LOCAL_IP nicht festlegen, wird standardmäßig ihr IPv6-Pendant anstelle von localhost verwendet. Außerdem wird die Umgebungsvariable, die als RUN export SPARK_LOCAL_IP="127.0.0.1" festgelegt ist, von Spark nicht erkannt.

Zugriff auf Dateien über NFS nicht möglich

Fehler Empfohlene Lösung
mount.nfs: Protocol not supported In einigen Basis-Images wie debian und adoptopenjdk/openjdk11 fehlt die Abhängigkeit nfs-kernel-server.
mount.nfs: Connection timed out Wenn die Verbindung überschreitet, müssen Sie die richtige IP-Adresse der Filestore-Instanz angeben.
mount.nfs: access denied by server while mounting IP_ADDRESS:/FILESHARE Wenn der Zugriff vom Server verweigert wurde, prüfen Sie, ob der Name der Dateifreigabe korrekt ist.

Zugriff auf Dateien über Cloud Storage FUSE nicht möglich

Weitere Informationen finden Sie in der Anleitung zur Fehlerbehebung für Cloud Storage FUSE.

Hohe Latenz bei niedriger CPU-Auslastung

Bei Ihrem Dienst kann es zu hohen Anfragelatenzen kommen oder er kann unter Last nicht skaliert werden, obwohl die durchschnittliche CPU-Auslastung in Cloud Monitoring deutlich unter dem typischen Skalierungsziel von 60% liegt.

Mögliche Ursache:

Das kann passieren, wenn Ihre Anwendung für CPU-intensive Aufgaben Single-Threaded ist, aber auf einer Instanz mit mehreren vCPUs bereitgestellt wird. Ihre Anwendung kann einen vCPU-Kern maximal auslasten, während andere Kerne größtenteils im Leerlauf bleiben. Der Cloud Run-Autoscaler verwendet die durchschnittliche CPU-Auslastung aller vCPUs. Dieser Durchschnitt kann in diesen Fällen niedrig sein, was ein CPU-basiertes Skalieren verhindert.

Lösungen:

  • Bei Single-Threaded-Anwendungen:
    • Konfigurieren Sie Ihren Dienst mit 1 vCPU, wenn seine Speicheranforderungen erfüllt werden können (siehe Speicherlimits und CPU-Mindestwerte). So spiegeln die Messwerte zur CPU-Auslastung die Last genau wider.
    • Wenn aufgrund eines hohen Arbeitsspeicherbedarfs, der die 1-vCPU-Grenzwerte überschreitet, mehrere vCPUs erforderlich sind, ist das CPU-basierte Autoscaling wahrscheinlich weniger effektiv. In diesem Szenario sollten Sie die Einstellung für die maximale Nebenläufigkeit senken, damit die Skalierung basierend auf dem Anfragendurchsatz früher erfolgt. Siehe Konfiguration der Parallelität.
  • Konfigurationen mit mehreren vCPUs: Achten Sie darauf, dass Ihre Anwendung so konzipiert ist, dass alle zugewiesenen vCPUs effektiv genutzt werden (z. B. durch die Verwendung mehrerer Worker-Prozesse oder Threads).

Verbindungs- und Sicherheitsfehler

In diesem Abschnitt werden die häufigsten Verbindungs- und Sicherheitsfehler in Cloud Run sowie Methoden zur Fehlerbehebung beschrieben.

Client ist nicht ordnungsgemäß authentifiziert

Der folgende Fehler tritt während der Schaltung auf:

HTTP 401: The request was not authorized to invoke this service

So lösen Sie dieses Problem:

  1. Wenn ein Dienstkonto Ihren Cloud Run-Dienst aufruft, legen Sie die Zielgruppenanforderung (aud) des von Google signierten ID-Tokens auf Folgendes fest:

    • Wenn Sie aud auf die URL des empfangenden Dienstes im Format https://SERVICE.run.app oder https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION festlegen, muss für Ihren Dienst eine Authentifizierung erforderlich sein. Rufen Sie Ihren Cloud Run-Dienst über die Cloud Run-URL oder über eine Load-Balancer-URL auf. Beispiele zum Senden authentifizierter Anfragen finden Sie unter Mit einer HTTPS-Anfrage aufrufen.

    • Wenn Sie aud auf die Client-ID einer OAuth 2.0-Client-ID mit dem Typ Webanwendung im Format nnn-xyz.apps.googleusercontent.com festlegen, können Sie Ihren Cloud Run-Dienst über einen HTTPS-Load-Balancer, der durch IAP geschützt ist, aufrufen. Wir empfehlen diesen Ansatz für einen Application Load Balancer, der von mehreren Cloud Run-Diensten in verschiedenen Regionen unterstützt wird.

    • Wenn Sie aud auf eine konfigurierte benutzerdefinierte Zielgruppe festlegen, verwenden Sie die genauen Werte. Wenn die benutzerdefinierte Zielgruppe beispielsweise https://service.example.com ist, muss der Wert des Zielgruppenanspruchs ebenfalls https://service.example.com sein.

  2. Achten Sie darauf, dass Ihre Anfragen einen Authorization: Bearer ID_TOKEN-Header oder einen X-Serverless-Authorization: Bearer ID_TOKEN-Header für die benutzerdefinierte Autorisierung enthalten und dass das Token ein ID-Token und kein Zugriffs- oder Aktualisierungstoken ist. Ein 401-Fehler kann in den folgenden Szenarien aufgrund eines falschen Autorisierungsformats auftreten:

    • Das Autorisierungstoken hat ein ungültiges Format.

    • Der Autorisierungsheader ist kein JSON Web Token (JWT) mit einer gültigen Signatur.

    • Der Autorisierungsheader enthält mehrere JWTs.

    • Die Anfrage enthält mehrere Autorisierungsheader.

    Verwenden Sie das Tool jwt.io, um Anforderungen in einem JWT zu prüfen.

  3. Wenn Sie ungültige Tokens erhalten, wenn Sie den Metadatenserver zum Abrufen von ID- und Zugriffstokens verwenden, um Anfragen beim Cloud Run-Dienst oder der Jobidentität mit einem HTTP-Proxy zu authentifizieren, um ausgehenden Traffic weiterzuleiten, fügen Sie die folgenden Hosts zu den HTTP-Proxy-Ausnahmen hinzu:

    • 169.254.* oder 169.254.0.0/16

    • *.google.internal

  4. Ein 401-Fehler tritt häufig auf, wenn Cloud-Clientbibliotheken den Metadatenserver verwenden, um Standardanmeldedaten für Anwendungen abzurufen und REST- oder gRPC-Aufrufe zu authentifizieren. Wenn Sie die HTTP-Proxy-Ausnahmen nicht definieren, führt dies zu folgendem Verhalten:

    • Wenn verschiedene Google Cloud Arbeitslasten einen Cloud Run-Dienst oder -Job und den HTTP-Proxy hosten, werden die Tokens vom Dienstkonto generiert, das der HTTP-Proxy-Arbeitslast zugewiesen ist, auch wenn die Cloud-Clientbibliotheken die Anmeldedaten abrufen. Die Tokens haben möglicherweise nicht die erforderlichen Berechtigungen, um die beabsichtigten Google Cloud API-Vorgänge auszuführen. Das liegt daran, dass das Dienstkonto die Tokens vom Metadatenserver der HTTP-Proxy-Arbeitslast abruft und nicht vom Cloud Run-Dienst oder -Job.

    • Wenn der HTTP-Proxy nicht in Google Cloudgehostet wird und Sie Metadatenserveranfragen über den Proxy weiterleiten, schlagen die Tokenanfragen fehl und die Vorgänge der Google Cloud APIs werden nicht authentifiziert.

  5. Stellen Sie den Dienst noch einmal bereit, um öffentlichen Zugriff zuzulassen, wenn dies von Ihrer Organisation unterstützt wird. Dies ist zum Testen nützlich.

Der Client ist nicht berechtigt, den Dienst aufzurufen

Beim Aufrufen Ihres Dienstes tritt einer der folgenden Fehler auf:

HTTP 403: The request was not authenticated. Either allow public access or set the proper Authorization header
 
HTTP 403: Forbidden: Your client does not have permission to get URL from this server.

Ein 403-Fehler kann auftreten, wenn dem IAM-Mitglied, das zum Generieren des Autorisierungstokens verwendet wurde, die Berechtigung run.routes.invoke fehlt. Erteilen Sie dem Nutzer, der das Token generiert, diese Berechtigung.

Wenn in Cloud Logging ein Eintrag für den Fehler im Format resource.type = "cloud_run_revision" vorhanden ist, führen Sie die folgenden Schritte aus, um den Fehler zu beheben:

  1. Wenn Ihr Dienst für jeden Nutzer abrufbar sein soll, aktualisieren Sie die IAM-Einstellungen und machen Sie den Dienst öffentlich.

  2. Wenn Ihr Dienst nur für bestimmte Identitäten aufrufbar sein soll, rufen Sie ihn mit dem richtigen Autorisierungstoken auf:

    • Wenn ein Entwickler oder ein Endnutzer Ihren Dienst aufruft, gewähren Sie die Berechtigung run.routes.invoke. Sie können diese Berechtigung über die Rollen „Cloud Run-Administrator“ (roles/run.admin) und „Cloud Run-Aufrufer“ (roles/run.invoker) bereitstellen.

    • Wenn ein Dienstkonto Ihren Dienst aufruft, prüfen Sie, ob das Dienstkonto Mitglied des Cloud Run-Dienstes ist, und weisen Sie die Rolle „Cloud Run Invoker“ (roles/run.invoker) zu.

    • Bei Aufrufen, bei denen ein Authentifizierungstoken fehlt, kann der Fehler 403 auftreten. Wenn Aufrufe mit einem gültigen Authentifizierungstoken weiterhin zum Fehler 403 führen, erteilen Sie dem IAM-Mitglied, das das Token generiert, die Berechtigung run.routes.invoke.

Wenn Sie auf einen 403-Fehler stoßen und den Logeintrag resource.type = "cloud_run_revision" nicht finden, liegt das möglicherweise daran, dass VPC Service Controls einen Cloud Run-Dienst blockiert, der für eingehenden Traffic auf All konfiguriert ist. Weitere Informationen zur Fehlerbehebung bei VPC Service Controls-Ablehnungen finden Sie unter 404-Fehler.

Fehler beim Zugriff auf den Dienst über einen Webbrowser

Das folgende Problem tritt auf, wenn Sie über einen Webbrowser auf einen Cloud Run-Dienst zugreifen:

403 Forbidden
Your client does not have permission to get URL from this server.

Wenn Sie einen Cloud Run-Dienst über einen Webbrowser aufrufen, sendet der Browser eine GET-Anfrage an den Dienst. Die Anfrage enthält jedoch nicht das Autorisierungstoken des aufrufenden Nutzers. So beheben Sie das Problem:

  1. Identity-Aware Proxy (IAP) mit Cloud Run verwenden Mit IAP können Sie eine zentrale Autorisierungsebene für Anwendungen einrichten, auf die über HTTPS zugegriffen wird. Mit IAP können Sie ein Zugriffssteuerungsmodell auf Anwendungsebene anstelle von Firewalls auf Netzwerkebene verwenden. Weitere Informationen zum Konfigurieren von Cloud Run mit IAP finden Sie unter Identity-Aware Proxy für Cloud Run aktivieren.

  2. Als vorübergehende Problemumgehung können Sie über einen Webbrowser mit dem Cloud Run-Proxy in der Google Cloud CLI auf Ihren Dienst zugreifen. Führen Sie den folgenden Befehl aus, um einen Dienst lokal zu proxen:

    gcloud run services proxy SERVICE --project PROJECT-ID

    Cloud Run leitet den privaten Dienst per Proxy an http://localhost:8080 weiter (oder an den mit --port angegebenen Port), sodass eine Bereitstellung des Tokens des aktiven Kontos oder eines anderen von Ihnen angegebenen Tokens stattfindet. Dies ist die empfohlene Methode zum privaten Testen einer Website oder API in Ihrem Browser. Weitere Informationen finden Sie unter Private Dienste testen.

  3. Öffentlichen Zugriff auf Ihren Dienst zulassen Dies ist hilfreich für Tests oder wenn es sich bei Ihrem Dienst um eine öffentliche API oder Website handelt.

Verbindung wurde von einem anderen Computer zurückgesetzt

Einer der folgenden Fehler tritt auf, wenn ein Peer im Netzwerk die von der Anwendung hergestellte TCP-Verbindung unerwartet schließt:

Connection reset by peer
 
asyncpg.exceptions.ConnectionDoesNotExistError: connection was closed in the middle of operation
 
grpc.StatusRuntimeException: UNAVAILABLE: io exception
 
psycopg.OperationalError: the connection is closed
 
ECONNRESET

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  • Wenn Sie versuchen, Hintergrundarbeit mit CPU-Drosselung durchzuführen, verwenden Sie die Einstellung instanzbasierte Abrechnung.

  • Achten Sie darauf, dass das Zeitlimits für ausgehende Anfragen eingehalten wird. Wenn Ihre Anwendung eine Verbindung im inaktiven Zustand hält, der über diesen Schwellenwert hinausgeht, muss das Gateway die Verbindung nutzen.

  • Standardmäßig ist die TCP-Socket-Option keepalive für Cloud Run deaktiviert. Es gibt keine direkte Möglichkeit, die Option keepalive auf Dienstebene zu konfigurieren. Wenn Sie die Option keepalive für jede Socketverbindung aktivieren möchten, geben Sie die erforderlichen Socketoptionen an, wenn Sie eine neue TCP-Socketverbindung öffnen. Das hängt von der Clientbibliothek ab, die Sie für diese Verbindung in Ihrer Anwendung verwenden.

  • Gelegentlich werden ausgehende Verbindungen aufgrund von Aktualisierungen der Infrastruktur zurückgesetzt. Wenn Ihre Anwendung langlebige Verbindungen wiederverwendet, sollten Sie Ihre Anwendung so konfigurieren, dass Verbindungen wiederhergestellt werden, um eine Wiederverwendung einer inaktiven Verbindung zu vermeiden.

  • Wenn Sie einen HTTP-Proxy zum Weiterleiten Ihres Cloud Run-Dienstes oder des ausgehenden Traffics von Cloud Run-Jobs verwenden und der Proxy die maximale Verbindungsdauer erzwingt, kann der Proxy lang andauernde TCP-Verbindungen wie z. B. solche, die mithilfe von Verbindungs-Pooling aufgebaut wurden, stillschweigend abbrechen. Dies führt dazu, dass HTTP-Clients fehlschlagen, wenn sie eine bereits geschlossene Verbindung wiederverwenden. Wenn Sie ausgehenden Traffic über einen HTTP-Proxy weiterleiten möchten, müssen Sie die Verbindungsvalidierung, Wiederholungsversuche und exponentiellen Backoff implementieren. Konfigurieren Sie für Verbindungspools Maximalwerte für das Alter von Verbindungen, inaktive Verbindungen und das Zeitlimit bei Inaktivität von Verbindungen.

Zeitlimits für Verbindungen

Die folgenden Fehler treten auf, wenn eine Anwendung versucht, eine neue TCP-Verbindung zu einem Remote-Host herzustellen, und die Verbindung zu lange dauert:

java.io.IOException: Connection timed out
 
ConnectionError: HTTPSConnectionPool
 
dial tcp REMOTE_HOST:REMOTE_PORT: i/o timeout / context error
 
Error: 4 DEADLINE_EXCEEDED: Deadline exceeded

So beheben Sie Probleme mit Zeitüberschreitungen bei Verbindungen:

  1. Wenn Sie den gesamten ausgehenden Traffic über ein VPC-Netzwerk weiterleiten, entweder über VPC-Connectors oder ausgehenden Direct VPC-Traffic, gehen Sie so vor:

    • Definieren Sie alle erforderlichen Firewallregeln, um eingehenden Traffic für die VPC-Connectors zuzulassen.

    • VPC-Firewallregeln müssen eingehenden Traffic zulassen, damit der Traffic von den VPC-Connectors oder dem Subnetz für ausgehenden Direct-VPC-Traffic den Zielhost oder das Zielsubnetz erreichen kann.

    • Achten Sie darauf, dass Sie alle erforderlichen Routen haben, damit der Traffic korrekt zu den Zielhosts und zurück geleitet werden kann. Das ist wichtig, wenn Sie den ausgehenden Traffic über VPC-Netzwerk-Peering oder Hybrid Cloud-Verbindungen weiterleiten, da Pakete mehrere Netzwerke durchlaufen, bevor sie den Remote-Host erreichen.

  2. Wenn Sie einen HTTP-Proxy zum Weiterleiten des gesamten ausgehenden Traffics Ihrer Cloud Run-Dienste oder -Jobs verwenden, müssen die Remotehosts über den Proxy erreichbar sein.

    Traffic, der über einen HTTP-Proxy weitergeleitet wird, kann sich je nach Ressourcenauslastung des Proxys verzögern. Wenn Sie HTTP-Ausgangstraffic über einen Proxy weiterleiten, implementieren Sie Wiederholungsversuche, exponentielles Backoff oder Circuit Breakers.

HTTP-Proxy-Ausnahmen konfigurieren

Wenn Sie einen HTTP-Proxy zum Weiterleiten des ausgehenden Traffics von Cloud Run-Diensten oder Jobs verwenden, müssen Sie Ausnahmen für Cloud APIs und andere Hosts und Subnetze ohne Proxy hinzufügen, um Latenz, Verbindungszeitüberschreitungen, Verbindungszurücksetzungen und Authentifizierungsfehler zu verhindern.

Nicht über einen Proxy geleitete Hosts und Subnetze müssen mindestens Folgendes enthalten:

  • 127.0.0.1
  • 169.254.* oder 169.254.0.0/16
  • localhost
  • *.google.internal
  • *.googleapis.com

Optional können nicht über einen Proxy geleitete Hosts Folgendes umfassen:

  • *.appspot.com
  • *.run.app
  • *.cloudfunctions.net
  • *.gateway.dev
  • *.googleusercontent.com
  • *.pkg.dev
  • *.gcr.io

So legen Sie HTTP-Proxy-Ausnahmen für das Egress-Netzwerk fest:

  • Umgebungsvariablen: NO_PROXY oder no_proxy.

  • Java Virtual Machine-Flag http.nonProxyHosts:

    • Die Systemeigenschaft https.nonProxyHosts ist nicht definiert. Dieses Systemattribut gilt sowohl für HTTP als auch für HTTPS.

    • Die System-Property http.nonProxyHosts unterstützt keine CIDR-Notation. Sie müssen Musterabgleichsausdrücke verwenden.

Fehlerhafte Antwort oder Problem mit Containerinstanzverbindung

Der folgende Fehler tritt auf, wenn ein Problem mit der Verbindung zu einer Containerinstanz vorliegt:

HTTP 503
The request failed because either the HTTP response was malformed or connection to the instance had an error.

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1.  Prüfen Sie Cloud Logging auf die folgenden Fehler:

    • Fehler aufgrund fehlenden Speichers Wenn die Logs Fehlermeldungen in Bezug auf die Containerinstanzen enthalten, die Speicherlimits überschreiten, lesen Sie die Empfehlungen im Abschnitt Containerinstanzen überschreiten Speicherlimits.

    • Fehler bei der Aktivitätsprüfung mit dem folgenden Fehler in den Logs:

      LIVENESS HTTP probe failed 1 time consecutively for container CONTAINER_NAME on port 8080. The instance has been shut down.

      Wenn Ihre Instanz innerhalb des Zeitlimits nicht erfolgreich auf den Probe reagiert, führen Sie die folgenden Schritte aus:

  2. Wenn Anfragen mit dem Fehlercode 503 beendet werden, bevor die in Cloud Run festgelegte Zeitüberschreitung für Anfragen erreicht ist, müssen Sie möglicherweise die Zeitüberschreitungseinstellung für Anfragen für Ihr Sprach-Framework aktualisieren:

  3. In einigen Fällen kann ein 503-Fehlercode aufgrund eines nachgelagerten Netzwerkengpasses auftreten, z. B. bei Lasttests. Wenn Ihr Dienst beispielsweise Traffic über einen Connector für serverlosen VPC-Zugriff weiterleitet, prüfen Sie, ob der Connector seinen Durchsatzschwellenwert überschritten hat. Gehen Sie dazu so vor:

    1. Öffnen Sie den serverlosen VPC-Zugriff in der Google Cloud Console:

      Zur Seite "Serverloser VPC-Zugriff"

    2. Prüfen Sie, ob im Histogramm des Durchsatzdiagramms rote Balken zu sehen sind. Wenn ein roter Balken angezeigt wird, sollten Sie die maximale Anzahl der von Ihrem Connector verwendeten Instanzen oder Instanztypen erhöhen Alternativ können Sie den über einen Connector für serverlosen VPC-Zugriff gesendeten Traffic komprimieren.

  4. Wenn eine Containerinstanz mehr als 800 Anfragen pro Sekunde empfängt, können die verfügbaren TCP-Sockets aufgebraucht sein. Um dieses Problem zu beheben, aktivieren Sie HTTP/2 für Ihren Dienst und nehmen Sie die erforderlichen Änderungen an Ihrem Dienst vor, um HTTP/2 zu unterstützen.

Gateway-Zeitüberschreitungsfehler

Der folgende Fehler tritt auf, wenn Ihr Dienst innerhalb eines bestimmten Zeitraums keine Antwort zurückgibt und die Anfrage endet:

HTTP 504
The request has been terminated because it has reached the maximum request timeout.

Weitere Informationen zu diesem Fehler finden Sie im Containerlaufzeitvertrag.

Gehen Sie so vor, um das Problem zu beheben:

  • Wenn Ihr Dienst lange Anfragen verarbeitet, erhöhen Sie das Zeitlimit für Anfragen.

  • Instrumentieren Sie das Logging und Tracing, um zu verstehen, wo Ihre Anwendung Zeit aufnimmt, bevor Sie das konfigurierte Anfragezeitlimit überschreiten.

  • Ausgehende Verbindungen werden aufgrund von Aktualisierungen der Infrastruktur gelegentlich zurückgesetzt. Wenn Ihre Anwendung langlebige Verbindungen wiederverwendet, sollten Sie Ihre Anwendung so konfigurieren, dass Verbindungen wiederhergestellt werden, um eine Wiederverwendung einer inaktiven Verbindung zu vermeiden.

    Abhängig von der Logik Ihrer Anwendung oder der Fehlerbehandlung kann ein 504-Fehler ein Signal dafür sein, dass Ihre Anwendung versucht, eine tote Verbindung wiederzuverwenden, und die Anfrage wird blockiert, bis das konfigurierte Anfragezeitlimit erreicht ist. Verwenden Sie eine Aktivitätsprüfung, um eine Instanz zu beenden, die persistente Fehler zurückgibt.

  • Aufgrund von Speicherfehlern, die im Code der Anwendung auftreten (z. B. java.lang.OutOfMemoryError), wird eine Containerinstanz nicht unbedingt beendet. Wenn die Speichernutzung das Containerspeicherlimit nicht überschreitet, wird die Instanz von Cloud Run nicht beendet. Je nachdem, wie die App aufgrund von Speicherfehlern auf Anwendungsebene umgeht, können Anfragen hängen bleiben, bis sie das konfigurierte Zeitlimit für Anfragen überschreiten.

    So beenden Sie die Containerinstanz:

    • Konfigurieren Sie das Speicherlimit auf Anwendungsebene höher als Ihr Containerspeicherlimit.

    • Mit einer Aktivitätsprüfung können Sie eine Instanz beenden, die persistente Fehler zurückgibt.

Benutzerdefinierte Domain hängt bei der Bereitstellung des Zertifikats fest

Einer der folgenden Fehler tritt auf, wenn Sie eine benutzerdefinierte Domain zuordnen:

The domain is available over HTTP.  Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin and to accept HTTP traffic.
 
Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin.

So lösen Sie dieses Problem:

  1. Warten Sie mindestens 24 Stunden. Das Bereitstellen des SSL-Zertifikats dauert in der Regel etwa 15 Minuten, kann jedoch bis zu 24 Stunden in Anspruch nehmen.

  2. Prüfen Sie mit dem Dig-Tool der Google Admin Toolbox, ob Sie Ihre DNS-Einträge bei Ihrem Domain-Registrator ordnungsgemäß aktualisiert haben. Die DNS-Einträge in Ihrem Domain-Registrator müssen mit den Daten übereinstimmen, für die Sie dieGoogle Cloud -Konsole zum Hinzufügen auffordert.

  3. Bestätigen Sie das Stammverzeichnis der Domain unter Ihrem Konto mit einer der folgenden Methoden:

  4. Bestätigen Sie, dass das Zertifikat für die Domain nicht abgelaufen ist. Verwenden Sie den folgenden Befehl, um die Ablaufgrenzen zu ermitteln:

    echo | openssl s_client -servername 'ROOT_DOMAIN' -connect 'ROOT_DOMAIN:443' 2>/dev/null | openssl x509 -startdate -enddate -noout

Die Verbindungstrennung des Clients wird nicht an Cloud Run weitergegeben

Wenn Sie HTTP/1.1 in Cloud Run verwenden, werden Ereignisse zur Verbindungstrennung des Clients nicht an den Cloud Run-Container weitergegeben.

Verwenden Sie zur Behebung dieses Problems Websockets oder HTTP/2.0, die die Trennung von Clients propagieren.