Probleme mit Cloud Run beheben

Auf dieser Seite wird gezeigt, wie Sie Probleme mit Cloud Run beheben.

Prüfen Sie bei anderen Problemen, die unten nicht aufgeführt sind, ob es sich womöglich um bekannte Probleme handelt.

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 von einem Dienstkonto aufgerufen wird, muss für die Zielgruppenanforderung (aud) des von Google signierten ID-Tokens Folgendes 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 mit genau den angegebenen Werten. Beispiel: Wenn die benutzerdefinierte Zielgruppe service.example.com ist, muss der Wert für die Zielgruppenanforderung (aud) ebenfalls service.example.com sein. Wenn die benutzerdefinierte Zielgruppe https://service.example.com ist, muss der Wert für die Zielgruppenanforderung ebenfalls https://service.example.com sein.

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

  • Wenn das Authentifizierungstoken ein ungültiges Format hat, 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.

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 404: Nicht gefunden

Das folgende Problem tritt während der Schaltung auf:

Ein HTTP 404-Fehler ist aufgetreten.

So beheben Sie das Problem:

  1. Überprüfen Sie, ob die angeforderte URL korrekt ist. Rufen Sie dazu die Dienstdetailseite in der 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. In diesem Szenario 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.

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

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

Um dieses Problem zu beheben, versehen Sie die Ressource mit dem run.googleapis.com/launch-stage-Wert BETA in der Anfrage, wenn ein Beta-Feature verwendet wird.

Im folgenden Beispiel wird einer Dienstanfrage eine Startphasenannotation hinzugefügt:

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

Die Verbindung 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 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.