Bekannte Probleme in Cloud Run

Auf dieser Seite werden bekannte Probleme, Einschränkungen und nicht unterstützte Funktionen in Cloud Run aufgeführt.

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

Wählen Sie eine Kategorie für Ihr Problem aus:

Bereitstellung Bereitstellung Konnektivität und Sicherheit URL Beobachtbarkeit Nicht unterstützte Dienste und Funktionen

Sie können auch nach bekannten Problemen filtern:

Kategorie	Problem und Problemumgehung
Bereitstellung	Verzögerte Wiederherstellung des Dienstes nach Aufhebung einer überschrittenen Ausgabenobergrenze oder Reaktivierung der Abrechnung Wenn Ihr Projekt das Ausgabenlimit überschritten hat oder die Abrechnung deaktiviert wurde, kann es bis zu 30 Minuten dauern, bis Ihre Cloud Run-Ressourcen wieder Traffic verarbeiten, nachdem Sie das Ausgabenlimit aufgehoben oder die Abrechnung wieder aktiviert haben. In diesem Zeitraum können Anfragen mit 429- oder 503-Fehlern fehlschlagen (mit Logs, die „The request was aborted because there was no available instance“ (Die Anfrage wurde abgebrochen, da keine Instanz verfügbar war) angeben) oder Instanzen können nicht gestartet werden. Es gibt keine manuelle Umgehungslösung. Es kann bis zu 30 Minuten dauern, bis Ihre Ressourcen wieder fehlerfrei ausgeführt werden.
Konnektivität und Sicherheit	VPC-Connectors für Worker-Pools sind nicht produktionsreif Connectors für Serverloser VPC-Zugriff mit Cloud Run-Worker-Pools sind als Vorabversion 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.
Beobachtbarkeit	Linearer Anstieg des Messwerts für die Ingress-to-Region-Latenz Möglicherweise sehen Sie einen künstlichen linearen Anstieg des Messwerts run.googleapis.com/request_latency/ingress_to_region, am häufigsten, wenn Sie einen Dienst hinter einem externen Application Load Balancer mit dem HTTP/2-Protokoll platzieren und Verbindungen wiederverwendet werden. Das liegt daran, dass der Zeitstempel der ursprünglichen Anfrage bei nachfolgenden Anfragen über dieselbe Verbindung möglicherweise nicht aktualisiert wird, während die regionale Ankunftszeit fortlaufend aktualisiert wird. Dieses Muster ist eine Anomalie bei der Messwertberichterstellung. Dieses Problem spiegelt nicht die tatsächliche Latenz der Datenebene wider, die in der Regel niedrig bleibt. Der Messwert wird korrigiert, wenn die Verbindung geschlossen oder der Zähler zurückgesetzt wird.
Bereitstellung	Hohe Bereitstellungslatenz in einigen Regionen Das Erstellen oder Aktualisieren von Cloud Run-Ressourcen kann in einigen Regionen wie us-central1 länger dauern als erwartet. Wenn die Bereitstellungs-Latenz in einer bestimmten Region ein Problem darstellt, empfiehlt Google, die Bereitstellung in einer anderen Region vorzunehmen.
Bereitstellung	Cloud Run-Jobs können fälschlicherweise als wiederholt markiert werden In manchen Fällen kann eine Aufgabe als wiederholt markiert werden, wenn die Aufgabe beim ersten Versuch tatsächlich 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.
Bereitstellung	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.
Bereitstellung	Umgebungsvariable HOME ist in der Ausführungsumgebung der ersten Generation auf /home festgelegt Die Cloud Run-Ausführungsumgebung der ersten Generation legt die Umgebungsvariable HOME 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.
Bereitstellung	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 in /tmp bereitstellen. Sie können jedoch Secrets in jedem Unterverzeichnis von /tmp bereitstellen.
Bereitstellung	Hohe Anfragelatenz mit benutzerdefinierten Domains beim Aufrufen aus einigen Regionen Anfragen an Cloud Run-Dienste mit benutzerdefinierten Domains können von einigen Standorten aus eine sehr hohe Latenz 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.
Bereitstellung	Manchmal wird eine Anfrage an Instanzen gesendet, bevor die Ergebnisse der Startprüfung bekannt sind Cloud Run verwendet möglicherweise die an den Dienstendpunkt gesendete Anfrage, 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 im Cloud Run-Anfragelog aufgeführten receiveTimestamp. Wenn die Prüfung fehlschlägt, protokolliert Cloud Run den Fehler, ohne den Code des Dienstes auszuführen.
Konnektivität und Sicherheit	Für benutzerdefinierte Domainzuordnungen sind aktivierte run.app-URLs erforderlich Sie können benutzerdefinierte Domains nur für Cloud Run-Dienste zuordnen, die eine standardmäßige run.app-URL haben. Bis dieses Problem behoben ist, empfehlen wir Ihnen, die Standard-URL run.app zu aktivieren, die benutzerdefinierte Domain zuzuordnen und dann die Standard-URL run.app wieder zu deaktivieren, falls Sie die Standard-URL run.app deaktiviert haben.
Konnektivität und Sicherheit	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 für den direkten VPC-Ausgang Dual-Stack-Subnetze verwendet werden oder wenn auf Nicht-VPC-Endpunkte zugegriffen wird, während vpc-egress auf private-ranges-only gesetzt ist.
Konnektivität und Sicherheit	IP-Adressen werden bei Verwendung durch serverloses Computing nicht klar identifiziert Wenn Sie ausgehenden Direct VPC-Traffic verwenden, können Sie die von Cloud Run reservierten IP-Adressen, die derzeit verwendet werden, auf der Seite IP-Adressen in der Google Cloud Console als None anstelle von Serverless identifizieren.
URL	Reservierte URL-Pfade Die folgenden URL-Pfade können nicht verwendet werden: /eventlog Pfade, die mit /_ah/ beginnen Einige Pfade, die auf z enden Um Konflikte mit reservierten Pfaden zu vermeiden, sollten Sie alle Pfade vermeiden, die auf z enden.
URL	Einige codierte URL-Zeichen sind decodiert Cloud Run decodiert einige codierte Zeichen in der URL von Cloud Run-Diensten, bevor die Containerinstanz erreicht wird. %41 wird beispielsweise automatisch in A decodiert.
Nicht unterstützte Dienste und Funktionen	Nicht unterstützte Dienste Web Security Scanner
Nicht unterstützte Dienste und Funktionen	HTTP/2-Push Cloud Run unterstützt HTTP/2, jedoch nicht HTTP/2 Server Push.
Nicht unterstützte Dienste und Funktionen	HTTP-Methoden Cloud Run unterstützt keine Anfragen mit HTTP-Methoden wie TRACE und CONNECT. Daher werden diese Methoden nicht von Diensten empfangen, die in Cloud Run ausgeführt werden.
Nicht unterstützte Dienste und Funktionen	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 hängt das Verzeichnis /cloudsql nicht in die Container ein.

Nach oben