Probleme mit Cloud Run beheben

Auf dieser Seite wird beschrieben, wie Sie Fehlermeldungen und Probleme bei der Verwendung von Cloud Run beheben.

Außerdem können Sie in der öffentlichen Problemverfolgung prüfen, ob Probleme vorhanden sind, und neue Probleme eröffnen.

Informationen zu anderen Fehlermeldungen, die auf dieser Seite nicht aufgeführt sind, finden Sie auf der Seite Bekannte Probleme.

Bereitstellungsfehler

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

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.

Schließen Sie die folgenden möglichen Ursachen aus, um dieses 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 den erwarteten Port auf Anfragen überwacht, wie im Containerlaufzeitvertrag dokumentiert. 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 konfigurieren.

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

  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.

Interner Fehler, Frist für Ressourcenbereitschaft überschritten

Der folgende Fehler tritt auf, wenn Sie versuchen, eine andere Google Cloud API bereitzustellen oder aufzurufen:

The server has encountered an internal error. Please try again later. Resource readiness deadline exceeded.

Dieses Problem kann auftreten, wenn der Cloud Run-Dienst-Agent nicht vorhanden ist oder wenn er nicht die Rolle des Cloud Run-Dienst-Agents (roles/run.serviceAgent) hat.

So prüfen Sie, ob der Cloud Run-Dienst-Agent in Ihrem Google Cloud-Projekt vorhanden ist und die erforderliche Rolle hat:

  1. Öffnen Sie die Google Cloud Console:

    Zur Seite "Berechtigungen"

  2. Klicken Sie rechts oben auf der Seite Berechtigungen das Kästchen Von Google bereitgestellte Rollenzuweisungen einschließen an.

  3. Suchen Sie in der Liste Hauptkonten nach der ID des Cloud Run-Dienst-Agents, der die ID
    service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com verwendet.

  4. Prüfen Sie, ob der Dienst-Agent die Rolle Cloud Run Service Agent hat. Wenn der Dienst-Agent nicht über die Rolle verfügt, gewähren Sie sie.

Fehlernutzer "root" wurde in /etc/passwd nicht gefunden

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

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

Das Problem tritt auf, wenn vom Kunden verwaltete Verschlüsselungsschlüssel mit einem --key-Parameter angegeben werden

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 auf, wenn Sie versuchen, die Bereitstellung durchzuführen:

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 den folgenden Situationen auf:

So beheben Sie das Problem:

  1. Geben Sie mit dem Flag --service-account gcloud ein Dienstkonto an.
  2. Prüfen Sie, ob das von Ihnen angegebene Dienstkonto die Berechtigungen nötig für die Bereitstellung hat.

Wenn Sie prüfen möchten, ob der Compute Engine-Standarddienstagent in Ihrem Google Cloud-Projekt vorhanden ist, führen Sie die folgenden Schritte aus:

  1. Öffnen Sie die Google Cloud Console:

    Zur Seite "Berechtigungen"

  2. Klicken Sie rechts oben auf der Seite Berechtigungen das Kästchen Von Google bereitgestellte Rollenzuweisungen einschließen an.

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

Cloud Run-Dienst-Agent ist nicht berechtigt, das Image zu lesen

Der folgende Fehler tritt auf, wenn Sie versuchen, aus PROJECT-ID mit einem in Container Registry in PROJECT-ID-2 gespeicherten Image bereitzustellen:

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.

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.

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.

Schließen Sie die folgenden möglichen Ursachen aus, um dieses Problem zu beheben:

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

  2. Einige Windows-basierte Docker-Images verwenden Fremdebenen. Obwohl Container Registry keinen Fehler ausgibt, wenn fremde Ebenen vorhanden sind, unterstützt sie die Cloud Run-Steuerungsebene nicht. Zur Behebung des Fehlers können Sie versuchen, das Flag --allow-nondistributable-artifacts im Docker-Daemon festzulegen.

Schaltungsfehler

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

HTTP 401: Client ist nicht ordnungsgemäß authentifiziert

Der folgende Fehler tritt während der Schaltung auf:

The request was not authorized to invoke this service

So beheben Sie das Problem:

  • Wenn sie von einem Dienstkonto aufgerufen wird, muss die Zielgruppenanforderung (aud) des von Google signierten ID-Tokens so festgelegt werden:

    • Die Cloud Run-URL des empfangenden Dienstes im Format https://service-xyz.run.app.
      • Der Cloud Run-Dienst muss eine Authentifizierung erfordern.
      • Der Cloud Run-Dienst kann über die Cloud Run-URL oder über eine Load-Balancer-URL aufgerufen werden.
    • Die Client-ID einer OAuth 2.0-Client-ID mit dem Typ Webanwendung im Format nnn-xyz.apps.googleusercontent.com.
    • Eine konfigurierte benutzerdefinierte Zielgruppe, die die genauen Werte verwendet. Wenn die benutzerdefinierte Zielgruppe beispielsweise service.example.com ist, muss der Wert der Zielgruppenanforderung (aud) ebenfalls service.example.com sein. Wenn die benutzerdefinierte Zielgruppe https://service.example.com ist, muss der Wert der Zielgruppenanforderung ebenfalls https://service.example.com sein.

  • Das Tool jwt.io eignet sich zur Prüfung von Anforderungen in einem JWT.

  • Wenn das Format des Authentifizierungstokens ungültig ist, tritt ein 401-Fehler auf. Wenn das Token ein gültiges Format hat und dem IAM-Mitglied, das zum Generieren des Tokens verwendet wurde, die Berechtigung run.routes.invoke fehlt, tritt ein 403-Fehler auf.

  • 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, und Sie erhalten ungültige Tokens, fügen Sie die folgenden Hosts zu den HTTP-Proxy-Ausnahmen hinzu:

    • 169.254.* oder 169.254.0.0/16
    • *.google.internal

    Dieser Fehler tritt häufig auf, wenn die Cloud-Clientbibliotheken den Metadatenserver verwenden, um Standardanmeldedaten für Anwendungen zur Authentifizierung von REST- oder gRPC-Aufrufen abzurufen. Wenn Sie die HTTP-Proxy-Ausnahmen nicht definieren, führt dies zu folgendem Verhalten:

    • Wenn der Cloud Run-Dienst oder -Job und der HTTP-Proxy in verschiedenen Google Cloud-Arbeitslasten gehostet werden, auch wenn Google Cloud-Clientbibliotheken Anmeldedaten abrufen können, werden die Tokens für das Dienstkonto generiert, das der HTTP-Proxy-Arbeitslast zugewiesen ist und das möglicherweise nicht über die erforderlichen Berechtigungen zum Ausführen der gewünschten Google Cloud API-Vorgänge verfügt. In diesem Fall werden die Tokens aus der Ansicht des Metadatenservers der HTTP-Proxy-Arbeitslast abgerufen und nicht aus der Cloud Run-Arbeitslast.

    • Wenn der HTTP-Proxy nicht in Google Cloud gehostet wird und Metadatenserver-Anfragen über den Proxy weitergeleitet werden, schlagen Tokenanfragen fehl und die Google Cloud APIs-Vorgänge werden nicht authentifiziert.

HTTP 403: Der Client ist nicht berechtigt, den Dienst aufzurufen

Der folgende Fehler kann in Cloud Logging mit resource.type = "cloud_run_revision" vorliegen oder nicht:

The request was not authenticated. Either allow unauthenticated invocations or set the proper Authorization header

Der folgende Fehler ist in der HTTP-Antwort vorhanden, die an den Client zurückgegeben wird:

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

Um dieses Problem zu beheben, wenn der Cloud Logging-Fehler resource.type = "cloud_run_revision" vorhanden ist:

  • Wenn der Dienst für jeden Nutzer abrufbar ist, aktualisieren Sie die IAM-Einstellungen, um den Dienst öffentlich zu machen.
  • Wenn der Dienst nur für bestimmte Identitäten aufrufbar sein soll, sollten Sie ihn mit dem richtigen Autorisierungstoken aufrufen.
    • Wenn von einem Entwickler aufgerufen oder von einem Endnutzer aufgerufen wird: Prüfen Sie, ob der Entwickler oder Nutzer die Berechtigung run.routes.invoke hat, die Sie über die Rollen „Cloud Run-Administrator“ (roles/run.admin) und „Cloud Run-Aufrufer“ (roles/run.invoker) bereitstellen können.
    • Wenn von einem Dienstkonto aufgerufen wird: Prüfen Sie, ob das Dienstkonto Mitglied des Cloud Run-Dienstes ist und die Rolle „Cloud Run-Aufrufer“ (roles/run.invoker) hat.
    • Bei Aufrufen, bei denen ein Authentifizierungstoken fehlt oder bei denen das Format des Authentifizierungstokens zwar gültig ist, aber dem IAM-Mitglied, das zur Generierung des Tokens verwendet wurde, die run.routes.invoke-Berechtigung fehlt, tritt dieser 403-Fehler auf.

Zum Beheben dieses Problems, wenn der Cloud Logging-Fehler resource.type = "cloud_run_revision" nicht vorhanden ist:

  • Ein 403-Statuscode kann zurückgegeben werden, wenn ein Dienst für eingehenden Traffic All konfiguriert hat, dieser aber aufgrund von VPC Service Controls blockiert wurde. Weitere Informationen zur Fehlerbehebung bei VPC Service Controls-Ablehnungen finden Sie im nächsten Abschnitt zu 404-Fehlern.

HTTP 403: 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. Wählen Sie eine der folgenden Lösungen, um dieses Problem zu beheben:

  • 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.

  • Als temporäre Problemumgehung greifen Sie mit dem Cloud Run-Proxy in der Google Cloud CLI über einen Webbrowser auf Ihren Dienst zu. So können Sie einen Dienst lokal weiterleiten:

    gcloud run services proxy SERVICE --project PROJECT-ID

    Nachdem Sie diesen Befehl ausgeführt haben, leitet Cloud Run den privaten Dienst an http://localhost:8080 (oder an den mit --port angegebenen Port) weiter und stellt das Token des aktiven Kontos oder ein anderes von Ihnen angegebenes Token bereit. Dies ist die empfohlene Methode zum Testen einer privaten Website oder API in Ihrem Browser. Weitere Informationen finden Sie unter Private Dienste testen.

  • Lassen Sie nicht authentifizierte Aufrufe auf Ihrem Dienst zu. Dies ist zum Testen hilfreich oder wenn Ihr Dienst eine öffentliche API oder Website ist.

HTTP 404: Nicht gefunden

Das folgende Problem tritt während der Schaltung auf:

Ein HTTP 404-Fehler ist aufgetreten.

So lösen Sie dieses Problem:

  1. Überprüfen Sie, ob die angeforderte URL korrekt ist. Rufen Sie dazu die Dienstdetailseite in der Google Cloud Console auf oder führen Sie den folgenden Befehl aus:

    gcloud run services describe SERVICE_NAME | grep URL

  2. Prüfen Sie, wo Ihre Anwendungslogik möglicherweise 404-Fehlercodes zurückgibt. Wenn Ihre Anwendung 404 zurückgibt, ist das in Cloud Logging sichtbar.

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

  4. Achten Sie darauf, dass die Anwendung bei lokaler Ausführung keinen 404-Fehlercode zurückgibt.

Ein 404 wird zurückgegeben, wenn die Einstellungen eines Cloud Run-Dienstes für eingehenden Traffic auf "Intern" oder "Intern und Cloud Load Balancing" festgelegt sind und eine Anfrage nicht die angegebene Netzwerkeinschränkung erfüllt. Dies kann auch auftreten, wenn die Standard-URL run.app des Cloud Run-Dienstes deaktiviert ist und ein Client versucht, den Dienst unter dieser run.app-URL zu erreichen. In beiden Szenarien erreicht die Anfrage nicht den Container und 404 ist nicht in Cloud Logging mit dem folgenden Filter vorhanden:

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

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 (nicht die Seite Logs für Cloud Run):

    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.

Möglicherweise wird auch ein 404-Fehler angezeigt, wenn Sie 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.

HTTP 429: 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 Einstellungen für "Maximale Instanz". Wenn Sie weitere Instanzen benötigen, fordern Sie eine Kontingenterhöhung an.

HTTP 500: Cloud Run konnte die Trafficrate nicht verwalten

Der folgende Fehler tritt während der Bereitstellung auf und kann auch auftreten, wenn der Dienst das maximale Limit für Containerinstanzen nicht erreicht hat:

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

Dieses Problem kann folgende Ursachen haben:

  • 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.

Beheben Sie die zuvor aufgeführten Probleme, um dieses Problem zu beheben.

Neben der Behebung dieser Probleme können Sie als Behelfslösung exponentiellen Backoff und Wiederholungsversuche für Anfragen implementieren, 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.

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

HTTP 501: Vorgang ist nicht implementiert

Der folgende Fehler tritt während der Schaltung auf:

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

Dieses Problem tritt auf, wenn Sie beim Aufrufen Ihres Cloud Run-Jobs einen falschen REGION angeben. Dieser Fehler kann beispielsweise auftreten, wenn Sie einen Job in der Region asia-southeast1 bereitstellen und den Job mit southeast1-asia oder asia-southeast aufrufen. Eine Liste der unterstützten Regionen finden Sie unter Cloud Run-Standorte.

HTTP 503: Standardanmeldedaten wurden nicht gefunden

Der folgende Fehler tritt während der Schaltung auf:

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

Dieses Problem tritt auf, wenn Ihre Anwendung aufgrund fehlender Dateien, ungültiger Anmeldedatenpfade oder falscher Zuweisungen von Umgebungsvariablen nicht ordnungsgemäß authentifiziert wurde.

So beheben Sie das 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 Ihrem Google-Konto zugeordnet sind. Konfigurieren Sie ADC 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.

HTTP 500 / HTTP 503: Containerinstanzen überschreiten die Speicherlimits

Der folgende Fehler tritt während der Schaltung auf:

In Cloud Logging:

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 beheben Sie das 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.

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

HTTP 503: Fehlerhafte Antwort oder Problem mit Containerinstanzverbindung

Während der Schaltung tritt einer der folgenden Fehler auf: 

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 Empfehlungen zur Problembehebung aus, um das Problem zu beheben:

  • Cloud Logging prüfen Verwenden Sie Cloud Logging, um in den Logs nach Speicherfehlern zu suchen. Wenn Fehlermeldungen in Bezug auf die Containerinstanzen angezeigt werden, die Speicherlimits überschreiten, folgen Sie den Empfehlungen zur Behebung dieses Problems.

  • Zeitüberschreitung App-Level 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:

  • Nachgelagerter Netzwerkengpass: In einigen Fällen kann ein 503-Fehlercode indirekt aus einem nachgelagerten Engpass 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.

  • Limit für eingehende Anfragen an einen einzelnen Container Es gibt ein bekanntes Problem, bei dem hohe Anfrageraten pro Container vorliegen, was zu diesem 503-Fehler führt. Wenn eine Containerinstanz mehr als 800 Anfragen pro Sekunde empfängt, können die verfügbaren TCP-Sockets aufgebraucht sein. Versuchen Sie Folgendes, um dies zu beheben:

    1. Aktivieren Sie HTTP/2 für Ihren Dienst und nehmen Sie die erforderlichen Änderungen an Ihrem Dienst vor, um HTTP/2 zu unterstützen.

    2. Vermeiden Sie es, mehr als 800 Anfragen pro Sekunde an eine einzelne Containerinstanz zu senden, indem Sie die konfigurierte Gleichzeitigkeit verringern. Verwenden Sie die folgende Gleichung, um eine Schätzung der Anfragerate pro Containerinstanz zu erhalten: requests/sec/container_instance ~= concurrency * (1sec / median_request_latency)

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

Folgende Fehler treten während der Schaltung auf:

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

Dieses Problem tritt auf, wenn Ihre Containerinstanzen viel CPU-Leistung zum Verarbeiten von Anfragen verwenden. Daher können die Containerinstanzen nicht alle Anfragen verarbeiten. Daher geben einige Anfragen den Fehlercode 503 zurück.

Versuchen Sie Folgendes (eines davon oder mehr) um dieses Problem zu beheben:

HTTP 504: Zeitüberschreitung bei Gateway

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

Wenn Ihr Dienst lange Anfragen verarbeitet, können Sie das Zeitlimit für Anfragen erhöhen. Wenn Ihr Dienst innerhalb der angegebenen Zeit keine Antwort zurückgibt, endet die Anfrage und der Dienst gibt einen HTTP 504-Fehler zurück, wie im Containerlaufzeitvertrag dokumentiert.

Versuchen Sie Folgendes (eines davon oder mehr) um dieses Problem zu beheben:

  • 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.
    • Mit einer Aktivitätsprüfung können Sie eine Instanz beenden, die persistente Fehler zurückgibt.

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

    • Wenn Sie möchten, dass die Containerinstanz im obigen Szenario beendet wird, konfigurieren Sie das Speicherlimit auf Anwendungsebene höher als Ihr Containerspeicherlimit.
    • Mithilfe einer Aktivitätsprüfung können Sie eine Instanz beenden, die persistente Fehler zurückgibt.

Verbindung wurde von einem anderen Computer zurückgesetzt

Während der Schaltung tritt einer der folgenden Fehler auf:

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

Dieser Fehler tritt auf, wenn eine Anwendung eine TCP-Verbindung zu einem Peer im Netzwerk hergestellt hat und dieser Peer die Verbindung unerwartet schließt.

So beheben Sie das Problem:

  • Wenn Sie versuchen, Hintergrundarbeit mit CPU-Drosselung durchzuführen, verwenden Sie versuchsweise die CPU-Zuordnungseinstellung "CPU wird immer zugewiesen".

  • Achten Sie darauf, dass das Zeitlimits für ausgehende Anfragen eingehalten wird. Wenn Ihre Anwendung eine Verbindung im inaktiven Zustand hält, der über diese Schwellenwerte 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 in Cloud Run auf Dienstebene zu konfigurieren. Sie können jedoch die Option keepalive für jede Socket-Verbindung aktivieren, indem Sie beim Öffnen einer neuen TCP-Socket-Verbindung die richtigen Socket-Optionen angeben, abhängig von der Client-Bibliothek, 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. Dadurch schlagen HTTP-Clients fehl, wenn eine bereits geschlossene Verbindung wiederverwendet wird. Wenn Sie ausgehenden Traffic über einen HTTP-Proxy weiterleiten möchten, müssen Sie dieses Szenario berücksichtigen, indem Sie die Verbindungsvalidierung, Wiederholungsversuche und exponentiellen Backoff implementieren. Konfigurieren Sie für Verbindungspools die Höchstwerte für das Alter der Verbindung, inaktive Verbindungen und das Zeitlimit bei inaktiven Verbindungen.

Zeitlimits für Verbindungen

Latenzfehler oder einer der folgenden Fehler treten auf, wenn beim Senden einer Anfrage an einen Remote-Host Verbindungszeitüberschreitungen auftreten:

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

Diese Art von Fehlern tritt auf, wenn eine Anwendung versucht, eine neue TCP-Verbindung zu einem Remote-Host herzustellen, und das Herstellen der Verbindung zu lange dauert.

  • Wenn Sie den gesamten ausgehenden Traffic über ein VPC-Netzwerk weiterleiten, entweder mithilfe von VPC-Connectors oder mithilfe von ausgehendem Direct VPC-Traffic, achten Sie auf Folgendes:

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

    • Ihre VPC-Firewallregeln lassen eingehenden Traffic von den VPC-Connectors oder dem ausgehenden Direct VPC-Subnetz zu, um den Zielhost oder das Subnetz zu erreichen.

    • Sie haben alle erforderlichen Routen, um ein korrektes Trafficrouting zu den Zielhosts und zurück zu ermöglichen. Dies ist wichtig, wenn ausgehender Traffic über VPC-Netzwerk-Peering oder Hybrid-Cloud-Konnektivität weitergeleitet wird, da Pakete mehrere Netzwerke durchlaufen, bevor sie den Remote-Host erreichen.

  • Wenn Sie einen HTTP-Proxy verwenden, um den gesamten ausgehenden Traffic von Ihren Cloud Run-Diensten oder -Jobs weiterzuleiten, achten Sie darauf, dass die Remote-Hosts über den Proxy erreichbar sind.

    Traffic, der über einen HTTP-Proxy weitergeleitet wird, kann je nach Ressourcennutzung des Proxys verzögert sein. Wenn Sie den ausgehenden HTTP-Traffic über einen Proxy weiterleiten möchten, müssen Sie dieses Szenario durch die Implementierung von Wiederholungsversuchen, exponentiellem Backoff oder Schutzschaltern berücksichtigen.

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.

Hosts und Subnetze ohne Proxy 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 Hosts ohne Proxy Folgendes enthalten:

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

Zu den gängigen Methoden zum Konfigurieren von HTTP-Proxy-Ausnahmen für ausgehende Netzwerke gehören:

  • Umgebungsvariablen: NO_PROXY oder no_proxy.

  • Java Virtual Machine-Flag http.nonProxyHosts.

    • Das Systemattribut https.nonProxyHosts ist nicht definiert, sodass http.nonProxyHosts sowohl für HTTP als auch für HTTPS gilt.
    • Das Systemattribut http.nonProxyHosts unterstützt keine CIDR-Notation. Daher müssen Sie Ausdrücke für den Musterabgleich verwenden.

Von Google entfernte Identitätstokensignatur

Folgende Fehler treten während der Schaltung auf:

SIGNATURE_REMOVED_BY_GOOGLE

Dies kann während der Entwicklung und beim Testen unter folgenden Umständen auftreten:

  1. Ein Nutzer meldet sich über die Google Cloud CLI oder Cloud Shell an.
  2. Der Nutzer generiert ein ID-Token mit gcloud-Befehlen.
  3. Der Nutzer versucht, das ID-Token zu verwenden, um einen nicht öffentlichen Cloud Run-Dienst aufzurufen.

Dies geschieht absichtlich. 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 Authentifizierung in Ihrem 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

Dies ist nur eine Warnung und wirkt sich nicht auf Ihren Dienst aus. Diese Warnung wird angezeigt, weil die von der Ausführungsumgebung der ersten Generation verwendete Container-Sandbox keine Hardwarefunktionen auf niedriger Ebene zur Verfügung stellt. Sie können optional zur Ausführungsumgebung der zweiten Generation wechseln, wenn Sie diese Warnungen nicht in Ihren Logs sehen möchten.

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

Während der Schaltung 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>

So beheben Sie das Problem:

Um den Wert der Umgebungsvariablen zu ändern und das Problem zu beheben, legen Sie in Ihrem Dockerfile ENV SPARK_LOCAL_IP="127.0.0.1" fest. Wenn in Cloud Run die Variable SPARK_LOCAL_IP nicht festgelegt ist, wird standardmäßig IPv6 verwendet und nicht localhost. Beachten Sie, dass die Einstellung RUN export SPARK_LOCAL_IP="127.0.0.1" zur Laufzeit nicht verfügbar ist und Spark sich so verhält, als ob sie nicht gesetzt wäre.

Benutzerdefinierte Domains zuordnen

Benutzerdefinierte Domain hängt im Zertifikat-Bereitstellungsstatus fest

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

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 beheben Sie das Problem:

  • 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.

  • 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 die Google Cloud Console zum Hinzufügen auffordert.

  • Bestätigen Sie mit einer der folgenden Methoden, dass das Stammverzeichnis der Domain unter Ihrem Konto bestätigt wurde:

  • 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

Admin API

Dieses Feature wird in der deklarierten Startphase 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 den Anfragen das Feld „Startphase“ hinzu, um dieses Problem zu beheben. Im Folgenden finden Sie Beispiele für die v1 REST API und die v2 REST API:

Im folgenden Beispiel wird einer Clientanfrage mithilfe von JSON und der v1 REST API eine Startphasenannotation hinzugefügt:

    "annotations": {
      "run.googleapis.com/launch-stage": "BETA"
    }

Das folgende Beispiel fügt einer Client-Anfrage mithilfe von JSON und der v2 REST API eine LaunchStage-Referenz hinzu:

  "launchStage": "BETA"

Im folgenden Beispiel wird einer Dienstanfrage mithilfe von YAML und der v1 REST API eine Startphasenannotation hinzugefügt:

kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: BETA

Die Verbindungstrennung des Clients wird nicht an Cloud Run weitergegeben

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

Die Lösung besteht darin, Websockets oder HTTP/2.0 zu verwenden, die die Trennung von Clients propagieren.

Fehlerbehebung bei Problemen mit dem Netzwerkdateisystem

Netzwerkdateisysteme verwenden.

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 fehlen die Abhängigkeiten 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.