Für Cloud Run-Dienste ist standardmäßig keine Ausführungsumgebung angegeben. Das bedeutet, dass Cloud Run die Ausführungsumgebung anhand der verwendeten Features auswählt. Wenn Sie also keine Ausführungsumgebung für Ihren Dienst angeben, kann Cloud Run entweder die Umgebung der ersten oder zweiten Generation auswählen.
Beachten Sie, dass Cloud Run-Jobs nur die Ausführungsumgebung der zweiten Generation verwenden und dies für Jobs nicht geändert werden kann.
Die Ausführungsumgebung der ersten Generation bietet schnelle Kaltstartzeiten und die meisten Emulationen der meisten, aber nicht aller Betriebssystemaufrufe. Ursprünglich war dies die einzige Ausführungsumgebung, die für Dienste in Cloud Run verfügbar ist.
Die Ausführungsumgebung der zweiten Generation bietet vollständige Linux-Kompatibilität anstelle einer Systememulation. Diese Ausführungsumgebung bietet folgende Vorteile:
- Höhere CPU-Leistung
- Höhere Netzwerkleistung, insbesondere bei Paketverlust
- Vollständige Linux-Kompatibilität, einschließlich Unterstützung für alle Systemaufrufe, Namespaces und cgroups
- Unterstützung von Netzwerkdateisystemen
Obwohl die Ausführungsumgebung der zweiten Generation in der Regel unter dauerhafter Last schneller ausgeführt wird, hat sie für die meisten Dienste auch längere Kaltstartzeiten als die erste Generation.
Sie können die Ausführungsumgebung für Ihren Cloud Run-Dienst wählen, wenn Sie einen neuen Dienst oder eine neue Überarbeitung bereitstellen. Wenn Sie keine Ausführungsumgebung angeben, wird standardmäßig die erste Generation verwendet.
Ausführungsumgebung auswählen
Sie sollten die erste Generation verwenden, wenn eine der folgenden Bedingungen zutrifft:
- Ihr Cloud Run-Dienst hat stoßweisen Traffic und muss schnell auf viele Instanzen heraufskaliert werden oder Ihr Dienst ist empfindlich gegenüber Kaltstartzeiten.
- Ihr Cloud Run-Dienst hat seltenen Traffic, der häufig zu einer horizontalen Skalierung von null führt.
- Sie möchten weniger als 512 MiB Arbeitsspeicher verwenden. Die Ausführungsumgebung der zweiten Generation erfordert mindestens 512 MiB Arbeitsspeicher.
Sie sollten die zweite Generation verwenden, wenn einer der folgenden Bedingungen auf Ihren Cloud Run-Dienst zutrifft:
- Ihr Dienst muss ein Netzwerkdateisystem verwenden, das nur von der zweiten Generation unterstützt wird.
- Ihr Dienst hat relativ gleichmäßigen Traffic und ist eher tolerant gegenüber den etwas langsameren Kaltstarts.
- Ihr Dienst hat CPU-intensive Arbeitslasten.
- Ihr Dienst könnte von einer höheren Netzwerkleistung profitieren.
- Ihr Dienst muss Software verwenden, bei der aufgrund von nicht implementierten Systemaufrufen Probleme bei der Ausführung in der ersten Generation auftreten.
- Ihr Dienst benötigt Linux cgroup-Funktionalität.
- Ihr Dienst nutzt die Infrastruktur eines Drittanbieters zur Sicherung von Containern.
Best Practices für die Verwendung der Ausführungsumgebung der zweiten Generation
Wir empfehlen, in Ihrem Container einen SIGTERM-Handler zu installieren, insbesondere wenn Sie das On-Demand-Abrechnungsmodell für die CPU verwenden.
Die Verarbeitung von SIGTERM bietet dem Container die Möglichkeit, sämtliche notwendige Bereinigungsaufgaben wie das Leeren von Logs vor dem Beenden durchzuführen. Wenn Ihr Container SIGTERM nicht abfängt, hat er trotzdem 10 Sekunden Zeit, diese Aufgaben auszuführen. Diese 10 Sekunden werden in Rechnung gestellt.
Prüfen, ob Ihr Container SIGTERM verarbeitet
So ermitteln Sie, ob in Ihrem Container ein SIGTERM-Handler installiert ist:
Starten Sie Cloud Shell. Den Schaltfläche Cloud Shell aktivieren finden Sie in der Kopfzeile der Dokumentationsseite, auf der Sie sich befinden. Möglicherweise müssen Sie es autorisieren und auf die Bereitstellung warten. Alternativ können Sie auch eine eigenständige Sitzung starten.
Führen Sie den Container lokal in Cloud Shell aus:
docker run IMAGE_URL
Ersetzen Sie IMAGE_URL durch einen Verweis auf das Container-Image, z. B.
us-docker.pkg.dev/cloudrun/container/hello:latest
. Wenn Sie Artifact Registry verwenden, muss das Repository REPO_NAME bereits erstellt sein. Die URL hat die FormLOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
.Öffnen Sie einen weiteren Tab in Cloud Shell und rufen Sie eine Liste der Container ab, die in der aktuellen Cloud Shell-Sitzung ausgeführt werden:
docker container ls
Sie müssen die vom Befehl zurückgegebene Container-ID ermitteln.
Mit der Container-ID ein SIGTERM-Signal an den Container senden
docker kill -s SIGTERM CONTAINER_ID
Kehren Sie zum Tab zurück, auf dem Sie
docker run
aufgerufen haben, um zu sehen, ob der Container beendet (angehalten) wurde. Wenn das SIGTERM-Signal dazu geführt hat, dass Ihr Container beendet wurde, verarbeitet der Container SIGTERM.
Verarbeiten von SIGTERM
Wenn Ihr Container SIGTERM nicht verarbeitet, können Sie am einfachsten einen SIGTERM-Handler hinzufügen, indem Sie Ihren Dienst in tini
einschließen. Auf diese Weise wird der Dienst als Unterprozess von tini
ausgeführt, was die Rolle des Container-init-Prozesses übernimmt.
Weitere Informationen finden Sie in der Docker-Anleitung.
Alternativ können Sie Ihre Anwendung so ändern, dass SIGTERM direkt verarbeitet wird.
Nächste Schritte
- Informationen zum Angeben einer Ausführungsumgebung für Ihre Cloud Run-Dienste finden Sie unter Ausführungsumgebung auswählen.
- Informationen zum Angeben von Arbeitsspeicher für Ihre Cloud Run-Dienste finden Sie unter Speicherlimits.
- Informationen zur Verwendung von Filestore mit Cloud Run finden Sie unter Filestore mit Cloud Run verwenden.
- Informationen zur Verwendung von Cloud Storage FUSE mit Cloud Run finden Sie unter Cloud Storage FUSE mit Cloud Run verwenden.
- Informationen zur Verwendung von Netzwerkdateisystemen wie NFS, NDB, 9P, CIFS/Samba und Ceph mit Cloud Run finden Sie unter Netzwerkdateisysteme verwenden.