Bekannte Probleme in Cloud Run

Verzögerte Dienstwiederherstellung nach dem Aufheben einer überschrittenen Ausgabenobergrenze oder dem erneuten Aktivieren der Abrechnung

Wenn Ihr Projekt die Ausgabenobergrenze überschritten hat oder die Abrechnung deaktiviert wurde, kann es bis zu 30 Minuten dauern, bis Ihre Cloud Run-Ressourcen wieder Traffic verarbeiten, nachdem Sie die Ausgabenobergrenze aufgehoben oder die Abrechnung wieder aktiviert haben. In diesem Zeitraum können Anfragen mit den Fehlern 429 oder 503 fehlschlagen. In den Logs wird dann „The request was aborted because there was no available instance“ (Die Anfrage wurde abgebrochen, da keine Instanz verfügbar war) angezeigt. Außerdem können Instanzen möglicherweise nicht gestartet werden.

Es gibt keine manuelle Problemumgehung. Sie müssen bis zu 30 Minuten warten, bis Ihre Ressourcen wieder fehlerfrei funktionieren.

VPC-Connectors für Worker-Pools sind nicht für die Produktion geeignet

Connectors für Serverloser VPC-Zugriff mit Cloud Run-Worker-Pools sind in der Vorschau verfügbar und werden nur über Terraform mit der Cloud Run v2 API unterstützt. Es gibt keine Unterstützung in der Google Cloud Console, der Google Cloud CLI, YAML und der Cloud Run v1 API. Außerdem werden Komponenten für die Produktionsbereitschaft wie Monitoring-Messwerte nicht unterstützt.

Lineare Zunahme des Messwerts für die Latenz zwischen Eingang und Region

Möglicherweise beobachten Sie eine künstliche lineare Zunahme des run.googleapis.com/request_latency/ingress_to_region Messwerts. Das tritt am häufigsten auf, wenn Sie einen Dienst mit dem HTTP/2-Protokoll hinter einem externen Application Load Balancer platzieren und Verbindungen wiederverwendet werden. Das liegt daran, dass der ursprüngliche Zeitstempel der Anfrage für nachfolgende Anfragen über dieselbe Verbindung möglicherweise nicht aktualisiert wird, während die regionale Ankunftszeit weiter fortschreitet.

Dieses Muster ist eine Anomalie bei der Messwerterstellung. Dieses Problem stellt keine tatsächliche Latenz der Datenebene dar, die in der Regel niedrig bleibt. Der Messwert korrigiert sich schließlich, wenn die Verbindung geschlossen oder der Zähler zurückgesetzt wird.

Hohe Bereitstellungslatenz in einigen Regionen

Das Erstellen oder Aktualisieren von Cloud Run-Ressourcen kann in einigen Regionen wie us-central1 länger als erwartet dauern. Wenn die Bereitstellungslatenz in einer bestimmten Region ein Problem darstellt, empfiehlt Google, die Bereitstellung in einer anderen Region vorzunehmen.

Cloud Run-Jobs können fälschlicherweise als wiederholt markiert werden

In einigen Fällen kann eine Aufgabe als wiederholt markiert werden, obwohl sie beim ersten Versuch erfolgreich war. Bis dieses Problem behoben ist, empfiehlt Google den Parameter --max-retries auf 3 oder höher zu setzen um irreführende Ausführungsfehler zu vermeiden.

Volume-Bereitstellungen sind nicht mit Config Connector kompatibel

Wenn Sie Ihren Cloud Run-Dienst oder -Job mit Config Connector bereitstellen, werden Ihre Volume-Bereitstellungen bei der nächsten Bereitstellung nicht mehr beibehalten. Möglicherweise treten auch Probleme bei der Verwendung von Config Connector in Diensten oder Jobs auf, auf die bereits Volume-Bereitstellungen angewendet werden.

Umgebungsvariable HOME ist in der Ausführungsumgebung der ersten Generation auf /home festgelegt

Die Ausführungsumgebung der ersten Generation von Cloud Run legt die HOME Umgebungsvariable auf /home fest. Die Ausführungsumgebung der zweiten Generation legt die HOME-Variable auf den Wert in /etc/passwd für den ausführenden Nutzer fest oder wechselt zu /home, wenn /etc/passwd nicht vorhanden ist oder der Nutzer in /etc/passwd nicht gefunden werden kann.

Sie können keine Secrets unter /tmp in der Ausführungsumgebung der ersten Generation bereitstellen

Wenn Sie die Ausführungsumgebung der ersten Generation verwenden, können Sie Secrets nicht direkt unter /tmp bereitstellen. Sie können jedoch Secrets in jedem Unterverzeichnis von /tmp bereitstellen.

Hohe Anfragelatenz mit benutzerdefinierten Domains beim Aufrufen aus einigen Regionen

Anfragen an Cloud Run-Dienste mit benutzerdefinierten Domains können eine sehr hohe Latenz von einigen Standorten aus haben. Dieses Problem ist bei Cloud Run-Diensten in asia-northeast1 und us-east4 stärker ausgeprägt. Wenn dieses Problem auftritt, können Sie mit einer serverlosen NEG eine höhere Leistung mit Cloud Load Balancing erzielen.

Manchmal wird eine Anfrage an Instanzen gesendet, bevor die Ergebnisse der Startprüfung bekannt sind

Cloud Run kann die an den Dienstendpunkt gesendete Anfrage verwenden, um eine Instanz zu starten. Bevor die Ergebnisse der Startprüfung bekannt sind, kann Cloud Run die Anfrage auch der Instanz zuweisen. Wenn die Prüfung bestanden wird, verarbeitet die Instanz die Anfrage beim receiveTimestamp , der im Cloud Run-Anfragelog aufgeführt ist. Wenn die Prüfung fehlschlägt, protokolliert Cloud Run den Fehler, ohne den Code des Dienstes einzugeben.

Für Zuordnungen benutzerdefinierter Domains müssen run.app-URLs aktiviert sein

Sie können nur benutzerdefinierte Domains für Cloud Run Dienste zuordnen, die eine Standard-run.app URL haben. Bis dieses Problem behoben ist, run.appempfehlen wir, die Standard-run.app URL zu aktivieren, die benutzerdefinierte Domain zuzuordnen und dann die Standard- run.app URL wieder zu deaktivieren.

Serverloser VPC-Zugriff unterstützt IPv6 nicht

Sie können IPv6 nicht verwenden, wenn Traffic über Connectors für Serverloser VPC-Zugriff gesendet wird. IPv6 wird unterstützt, wenn Direct VPC Egress Dual-Stack-Subnetze verwendet oder wenn auf Nicht-VPC-Endpunkte zugegriffen wird, während vpc-egress auf private-ranges-only festgelegt ist.

IP-Adressen werden bei Verwendung durch serverloses Computing nicht klar identifiziert

Wenn Sie ausgehenden Direct VPC-Traffic verwenden, können Sie IP-Adressen identifizieren, die von Cloud Run reserviert wurden und derzeit verwendet werden. Diese werden in der Google Cloud Console auf der Seite „IP-Adressen“ als None und nicht als Serverless angezeigt.

Reservierte URL-Pfade

• Pfade, die mit /_ah/ beginnen
• Einige Pfade, die auf z enden. Um Konflikte mit reservierten Pfaden zu vermeiden, empfehlen wir, alle Pfade zu vermeiden, die auf z enden.

Einige codierte URL-Zeichen sind decodiert

Cloud Run decodiert einige codierte Zeichen in der URL von Cloud Run-Diensten, bevor die Containerinstanz erreicht wird. Beispiel: %41 wird automatisch in A decodiert.

Nicht unterstützte Dienste

HTTP/2-Push

Cloud Run unterstützt HTTP/2, jedoch nicht HTTP/2 Server Push.

HTTP-Methoden

Cloud Run unterstützt keine Anfragen mit HTTP-Methoden wie TRACE und CONNECT. Daher werden diese Methoden werden nicht von Diensten empfangen, die in Cloud Run ausgeführt werden.

Integrierte Cloud SQL-Verbindungen sind für Cloud Run-Jobs, die mit mehreren Containern ausgeführt werden, nicht verfügbar

Die Cloud Run-Funktion zum Herstellen einer Verbindung zu Cloud SQL Instanzen wird für Cloud Run-Jobs, die mit mehreren Containern ausgeführt werden, nicht unterstützt. Ihre Jobs werden weiterhin ausgeführt, aber Cloud Run stellt das Verzeichnis /cloudsql nicht in den Containern bereit.