SSH-Verbindungen schlagen beim Kaltstart eines Cloud Run-Dienstes mit mehreren Containern fehl

Wenn eine SSH-Verbindung einen Kaltstart eines Cloud Run-Dienstes mit mehreren Containern mit Containerstartreihenfolge (container-dependencies) auslöst, wird die Anfrage weitergeleitet, bevor die Containerumgebung bereit ist. Cloud Run gibt einen HTTP-500-Fehler zurück und beendet die neue Instanz sofort. Wenn Sie die Verbindung über die Google Cloud CLI herstellen, schlägt der Befehl fehl.

Um dieses Problem zu umgehen, stellen Sie nur dann eine Verbindung über SSH her, wenn eine Instanz bereits ausgeführt wird. Senden Sie beispielsweise zuerst eine Anfrage an den Dienst, um eine Instanz zu starten, oder konfigurieren Sie Mindestinstanzen.

Vorgänge mit langer Ausführungszeit zum Aktivieren oder Deaktivieren von SSH für Cloud Run-Instanzen werden möglicherweise vorzeitig zurückgegeben

Vorgänge mit langer Ausführungszeit (Long-Running Operations, LROs) zum Aktivieren oder Deaktivieren von SSH auf Cloud Run-Instanzen werden möglicherweise zurückgegeben, bevor der Vorgang abgeschlossen ist.

SSH-Verbindungen können gelegentlich fehlschlagen, nachdem SSH aktiviert oder deaktiviert wurde

SSH-Verbindungen können gelegentlich fehlschlagen, insbesondere nachdem Sie SSH aktiviert oder deaktiviert haben. Wenn eine Verbindung fehlschlägt, versuchen Sie es noch einmal.

Die Neustartrichtlinie Always beendet Cloud Run-Instanzen, wenn ein Container mit dem Code 0 beendet wird.

Wenn für eine Cloud Run-Instanz mit mehreren Containern die Richtlinie zum Neustarten auf Always festgelegt ist und ein Container mit dem Code 0 beendet wird, beendet Cloud Run die Instanz, anstatt sie neu zu starten.

Das Containerabhängigkeitsflag dependsOn funktioniert nicht für Cloud Run-Instanzen.

Das dependsOn-Flag für Cloud Run-Instanzen mit mehreren Containern ist nicht funktionsfähig. Abhängigkeiten, die zwischen Containern in Multi-Container-Instanzen angegeben werden, werden beim Starten von Containern nicht erzwungen.

Verzögerte Wiederherstellung des Dienstes nach Aufheben einer überschrittenen Ausgabenobergrenze oder Reaktivierung 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. Während dieses Zeitraums 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 sind.

VPC-Connectors für Worker-Pools sind nicht produktionsbereit

Connectors für den Serverloser VPC-Zugriff mit Cloud Run-Worker-Pools sind in der Vorabversion verfügbar und werden nur über Terraform mit der Cloud Run v2 API unterstützt. Es gibt keine Unterstützung in der Cloud de Confiance 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.

Linearer Anstieg des Messwerts für die Latenz beim eingehenden Traffic in die Region

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.

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

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

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.

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.

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

Für benutzerdefinierte Domainzuordnungen sind aktivierte -URLs erforderlich.

Sie können nur benutzerdefinierte Domains für Cloud Run-Dienste zuordnen, die eine standardmäßige -URL haben. Bis dieses Problem behoben ist, empfehlen wir Ihnen, die Standard--URL zu aktivieren, die benutzerdefinierte Domain zuzuordnen und dann die Standard--URL wieder zu deaktivieren, wenn Sie die Standard--URL deaktiviert haben.

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.

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 Cloud de Confiance Konsole als None anstelle von Serverless identifizieren.

Reservierte URL-Pfade

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

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 zu 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 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 hängt das Verzeichnis /cloudsql nicht in die Container ein.