Auf dieser Seite werden die wichtigsten Anforderungen und Verhaltensweisen von Containern in Cloud Run aufgeführt. Auf der Seite werden auch die Unterschiede zwischen Cloud Run-Diensten, Cloud Run-Jobs und Cloud Run-Worker-Pools beschrieben.
Unterstützte Sprachen und Images
Ihr Container-Image kann Code in der Programmiersprache Ihrer Wahl ausführen und jedes Basis-Image verwenden, sofern die auf dieser Seite aufgeführten Einschränkungen berücksichtigt werden.
Ausführbare Dateien im Container-Image müssen für Linux 64-Bit kompiliert sein. Cloud Run unterstützt speziell das Linux x86_64-ABI-Format.
Cloud Run akzeptiert Container-Images in den Docker Image Manifest V2, Schema 1, Schema 2 und OCI-Bildformate. Cloud Run akzeptiert auch Zstd-komprimierte Container-Images.
Wenn Sie ein Image mit mehreren Architekturen bereitstellen, muss die Manifestliste linux/amd64 enthalten.
Für Funktionen, die mit Cloud Run bereitgestellt werden, können Sie eines der Cloud Run-Laufzeit-Basis-Images verwenden, die von den Buildpacks von Google Cloud veröffentlicht werden, um automatische Sicherheits- und Wartungsupdates zu erhalten. Informationen zu den unterstützten Laufzeiten finden Sie im Zeitplan für die Laufzeitunterstützung.
Anfragen auf dem richtigen Port überwachen (Dienste)
Ein Cloud Run-Dienst startet Cloud Run-Instanzen zur Verarbeitung eingehender Anfragen. Eine Cloud Run-Instanz hat immer einen einzelnen Ingress-Container, der auf Anfragen wartet, und optional einen oder mehrere Sidecar-Container. Der folgende Port-Konfigurationsdetails gelten nur für den Container für eingehenden Traffic, nicht für Sidecars.
Der Ingress-Container innerhalb einer Instanz muss auf Anfragen unter 0.0.0.0 auf dem Port achten, an den Anfragen gesendet werden.
Der Ingress-Container sollte nicht auf 127.0.0.1 warten.
Standardmäßig werden Anfragen an 8080 gesendet, aber Sie können Cloud Run so konfigurieren, dass Anfragen an den Port Ihrer Wahl gesendet werden. Cloud Run fügt die PORT-Umgebungsvariable in den Ingress-Container ein.
Container, die in einer Jobausführung laufen, müssen nach Abschluss beendet werden
Bei Cloud Run-Jobs muss der Container mit dem Exit-Code 0 beendet werden, wenn der Job erfolgreich abgeschlossen wurde, und mit einem Exitcode ungleich Null beendet werden, wenn der Job fehlgeschlagen ist.
Da Jobs keine Anfragen verarbeiten sollen, sollte der Container weder einen Port überwachen noch einen Webserver starten.
Verschlüsselung auf Transportebene (TLS)
Der Container sollte die Sicherheit der Transportebene nicht direkt implementieren. TLS wird von Cloud Run für HTTPS und gRPC beendet und Anfragen werden dann als HTTP/1 oder gRPC ohne TLS an den Container weitergeleitet.
Wenn Sie einen Cloud Run-Dienst für die End-to-End-Verwendung von HTTP/2 konfigurieren, muss Ihr Container Anfragen im HTTP/2-Klartextformat (h2c) verarbeiten, da TLS weiterhin von Cloud Run automatisch beendet wird.
Antworten (Dienste)
Bei Cloud Run-Diensten muss Ihr Container innerhalb der in der Einstellung für das Zeitlimit für Anfragen angegebenen Zeit nach Erhalt einer Anfrage eine Antwort senden, wobei die Startzeit des Containers zu berücksichtigen ist. Andernfalls wird die Anfrage beendet und der Fehler 504 wird ausgegeben.
Antwort-Caching und Cookies
Wenn die Antwort Ihres Cloud Run-Dienstes einen Set-Cookie-Header enthält, setzt Cloud Run den Cache-Control-Header auf private, damit die Antwort nicht im Cache gespeichert wird. Dadurch wird verhindert, dass andere Nutzer das Cookie abrufen.
Umgebungsvariablen
Für Cloud Run-Dienste und -Jobs stehen verschiedene Umgebungsvariablen zur Verfügung.
Umgebungsvariablen für Dienste
Die folgenden Umgebungsvariablen werden allen laufenden Containern automatisch hinzugefügt, außer PORT. Die Variable PORT wird nur dem Ingress-Container hinzugefügt:
| Name | Beschreibung | Beispiel |
|---|---|---|
PORT |
Der Port, den Ihr HTTP-Server beobachten soll. | 8080 |
K_SERVICE |
Der Name des ausgeführten Cloud Run-Dienstes. | hello-world |
K_REVISION |
Der Name der ausgeführten Cloud Run-Überarbeitung. | hello-world.1 |
K_CONFIGURATION |
Der Name der Cloud Run-Konfiguration, mit der die Überarbeitung erstellt wurde. | hello-world |
Umgebungsvariablen für Jobs
Für Cloud Run-Jobs werden folgende Umgebungsvariablen festgelegt:
| Name | Beschreibung | Beispiel |
|---|---|---|
CLOUD_RUN_JOB |
Der Name des ausgeführten Cloud Run-Jobs. | hello-world |
CLOUD_RUN_EXECUTION |
Der Name der ausgeführten Cloud Run-Ausführung. | hello-world-abc |
CLOUD_RUN_TASK_INDEX |
Der Index dieser Aufgabe. Beginnt mit 0 für die erste Aufgabe und wird bei jeder nachfolgenden Aufgabe um 1 erhöht, bis zur maximalen Anzahl an Aufgaben minus 1. Wenn Sie --parallelism auf einen Wert größer als 1 festlegen, werden die Aufgaben möglicherweise nicht in der Indexreihenfolge ausgeführt. Zum Beispiel kann Aufgabe 2 vor Aufgabe 1 beginnen. |
0 |
CLOUD_RUN_TASK_ATTEMPT |
Die Anzahl der Ausführungsversuche für diese Aufgabe. Beginnt mit 0 für den ersten Versuch und wird bei jedem weiteren Wiederholungsversuch um 1 erhöht, bis zum maximalen Wiederholungswert. | 0 |
CLOUD_RUN_TASK_COUNT |
Die Zahl der Aufgaben, die im Parameter --tasks definiert sind. |
1 |
Umgebungsvariablen für Worker-Pools
Cloud Run legt die folgenden Umgebungsvariablen für Worker-Pools fest:
| Name | Beschreibung | Beispiel |
|---|---|---|
CLOUD_RUN_WORKER_POOL |
Der Name des ausgeführten Cloud Run-Worker-Pools. | hello-world |
CLOUD_RUN_WORKER_POOL_REVISION |
Der Name der ausgeführten Cloud Run-Worker-Pool-Überarbeitung. | hello-world.1 |
Anforderungen an Anfrage- und Antwortheader (Dienste)
Bei Diensten beschränkt Cloud Run Headernamen auf druckbare ASCII-Zeichen außer Leerzeichen und dürfen keine Doppelpunkte enthalten. Cloud Run beschränkt Headerwerte gemäß IETF RFC 7230 auf sichtbare ASCII-Zeichen plus Leerzeichen und horizontaler Tabulator.
Dateisystemzugriff
Das Dateisystem jedes Containers ist beschreibbar und unterliegt dem folgenden Verhalten:
- Da es sich um ein speicherinternes Dateisystem handelt, wird beim Schreiben der Arbeitsspeicher der Instanz verwendet.
- In das Dateisystem geschriebene Daten gehen verloren, wenn die Instanz beendet wird.
Sie können keine Größenbeschränkung für dieses Dateisystem festlegen. Sie können also möglicherweise den gesamten Ihrer Instanz zugewiesenen Speicher nutzen, indem Sie in das speicherinterne Dateisystem schreiben. Dies führt zu einem Absturz der Instanz. Sie können dieses Problem vermeiden, indem Sie ein dediziertes In-Memory-Volume mit einer Größenbeschränkung verwenden.
Lebenszyklus von Instanzen
Die Lebenszykluseigenschaften für Cloud Run-Jobs und -Dienste unterscheiden sich. Entsprechend werden sie in den folgenden Unterabschnitten separat beschrieben.
Für Dienste
Die folgenden Merkmale gelten nur für Dienste.
Dienstskalierung
Standardmäßig wird ein Cloud Run-Dienst automatisch auf die Anzahl der Instanzen skaliert, die zum Verarbeiten aller eingehenden Anfragen, Ereignisse oder der CPU-Auslastung erforderlich sind. Optional können Sie die manuelle Skalierung verwenden, wenn Sie mehr Kontrolle über das Skalierungsverhalten benötigen.
Jede Instanz führt eine feste Anzahl an Containern aus: einen Ingress-Container und optional einen oder mehrere Sidecar-Container.
Wenn eine Überarbeitung keinen Traffic empfängt, wird sie auf die konfigurierte Mindestanzahl von Containerinstanzen herunterskaliert (standardmäßig null).
Starten
Bei Cloud Run-Diensten müssen Ihre Instanzen innerhalb von vier Minuten nach dem Start auf Anfragen überwachen und alle Container innerhalb der Instanz müssen fehlerfrei sein. Während dieser Startzeit wird den Instanzen CPU zugewiesen. Sie können den CPU-Boost beim Start aktivieren, um die CPU-Zuweisung während des Starts einer Instanz vorübergehend zu erhöhen und damit die Startlatenz zu reduzieren.
Anfragen werden an den Ingress-Container gesendet, sobald er den konfigurierten Port überwacht.
Eine Anfrage, die auf eine Instanz wartet, wird so in einer Warteschlange aufbewahrt:
Anfragen bleiben bis zum 3,5-Fachen der durchschnittlichen Startzeit von Containerinstanzen dieses Dienstes oder bis zu 10 Sekunden ausstehend, je nachdem, welcher Wert größer ist.
Sie können eine Startprüfung konfigurieren, um festzustellen, ob der Container gestartet wurde und bereit ist, Anfragen zu verarbeiten.
Bei einem Cloud Run-Dienst, der aus Multi-Container-Instanzen besteht, können Sie die Reihenfolge angeben, in der die Container innerhalb der Instanz gestartet werden. Dazu konfigurieren Sie die Containerstartreihenfolge.
Anfrage verarbeiten
Bei Cloud Run-Diensten wird die CPU immer allen Containern, einschließlich Sidecar-Dateien, innerhalb einer Instanz zugewiesen, solange die Cloud Run-Überarbeitung mindestens eine Anfrage verarbeitet.
Inaktiv
Bei Cloud Run-Diensten ist eine inaktive Instanz eine, die keine Anfragen verarbeitet.
Die CPU, die allen Containern in einer inaktiven Instanz zugewiesen wird, hängt von den konfigurierten Abrechnungseinstellungen ab.
Eine Instanz ist nicht länger als 15 Minuten inaktiv, es sei denn, sie muss aufgrund der Konfigurationseinstellung für die Mindestanzahl von Instanzen inaktiv sein.
Herunterfahren
Bei Cloud Run-Diensten kann eine inaktive Instanz jederzeit heruntergefahren werden. Das gilt auch für Instanzen, die aufgrund einer konfigurierten Mindestanzahl an Instanzen einsatzbereit gehalten werden. Wenn eine Instanz, die Anfragen verarbeitet, heruntergefahren werden muss, werden die bereits verarbeiteten Anfragen abgeschlossen und neue eingehende Anfragen an andere Instanzen weitergeleitet. In Ausnahmefällen kann Cloud Run ein Herunterfahren initiieren und ein SIGTERM-Signal an einen Container senden, der noch Anfragen verarbeitet.
Bevor Sie eine Instanz herunterfahren, sendet Cloud Run ein SIGTERM-Signal an alle Container in einer Instanz, das den Beginn eines Zeitraums von 10 Sekunden vor dem tatsächlichen Herunterfahren angibt. An diesem Punkt sendet Cloud Run ein SIGKILL-Signal
In diesem Zeitraum wird der Instanz CPU zugewiesen und in Rechnung gestellt.
Wenn die Instanz bei Diensten, die die Ausführungsumgebung der ersten Generation verwenden, das SIGTERM-Signal nicht einfängt, wird sie sofort heruntergefahren. Bei Diensten, die die Ausführungsumgebung der zweiten Generation verwenden, empfehlen wir, einen SIGTERM-Handler in Ihrem Container zu installieren, um eine Warnung zu erhalten, wenn Cloud Run eine Instanz herunterfahren möchte.
Erzwungene Beendigung
Wenn ein oder mehrere Cloud Run-Container das Speicherlimit für den gesamten Container überschreiten, wird die Instanz beendet. Alle Anfragen, die noch auf der Instanz verarbeitet werden, werden mit dem Fehler HTTP 500 beendet.
Für Jobs
Bei Cloud Run-Jobs werden Containerinstanzen so lange ausgeführt, bis die Containerinstanz beendet wird, das Zeitlimit für Aufgaben erreicht ist oder der Container abstürzt.
Exit-Codes
Anhand von Job-Exit-Codes können Sie sehen, ob der Job erfolgreich abgeschlossen wurde oder ob Fehler aufgetreten sind. Die Exit-Codes sind numerische Werte, die einer erfolgreichen Ausführung oder bestimmten Fehlertypen zugeordnet sind.
In der folgenden Tabelle sind gängige Beendigungscodes und ihre Definitionen aufgeführt:
| Exit-Code | Signal | Beschreibung |
|---|---|---|
| 0 | Aufgabe erfolgreich abgeschlossen. | |
| 4 | SIGILL |
Der Task hat versucht, auf den Arbeitsspeicher an einer falschen Adresse zuzugreifen. |
| 7 | SIGBUS |
Die Aufgabe hat versucht, auf Arbeitsspeicher außerhalb des zugewiesenen Bereichs zuzugreifen. |
| 9 | SIGKILL |
Der Task wird entweder durch eine Nutzeraktion oder durch manuelles Eingreifen beendet. |
| 11 | SIGSEGV |
Die Aufgabe hat versucht, auf nicht autorisierten Speicher zuzugreifen. |
| 15 | SIGTERM |
Wenn eine Aufgabe das konfigurierte Zeitlimit überschreitet oder abgebrochen wird, erhält sie das Signal SIGTERM. Der Anwendungsserver sendet das SIGTERM-Signal, damit die Containerinstanz heruntergefahren wird. Wenn die Instanz nicht innerhalb weniger Sekunden nach dem Empfang von SIGTERM heruntergefahren wird, sendet Cloud Run ein SIGKILL-Signal für eine erzwungene Beendigung. Wenn die Instanz korrekt mit SIGTERM beendet wird, wird möglicherweise ein anderer Fehlercode gemeldet. Andernfalls wird SIGTERM zurückgegeben. |
Erzwungene Beendigung
Eine Cloud Run-Containerinstanz, die das zulässige Arbeitsspeicherlimit überschreitet, wird beendet. Alle Anfragen, die noch auf der Containerinstanz verarbeitet werden, enden mit dem Fehler HTTP 500.
Wenn eine Aufgabe das Zeitlimit für Aufgaben überschreitet, sendet Cloud Run ein "SIGTERM"-Signal, das den Start eines 10-Sekunden-Zeitraums vor dem tatsächlichen Herunterfahren bedeutet. Cloud Run sendet dann ein SIGKILL-Signal, mit dem die Containerinstanz heruntergefahren wird.
Während dieses Zeitraums wird Containerinstanzen für ihren gesamten Lebenszyklus eine CPU zugewiesen, die auch in Rechnung gestellt wird.
Weitere Informationen zum Einfangen des SIGTERM-Signals finden Sie im SIGTERM-Codebeispiel.
Für Worker-Pools
Die folgenden Eigenschaften gelten nur für Worker-Pools.
Skalierung
Worker-Pools werden nicht automatisch skaliert. Manuelles Skalieren der Anzahl der Instanzen, die Ihr Cloud Run-Worker-Pool zum Verarbeiten seiner Arbeitslast benötigt. Standardmäßig legt Cloud Run die Anzahl der Instanzen auf 1 fest. Sie können diese Zahl erhöhen oder verringern oder die Skalierung deaktivieren, indem Sie die Zahl auf 0 setzen. Damit Ihre Arbeitslast gestartet wird und aktiv bleibt, muss sie mindestens eine Instanz haben. Wenn Sie die Mindestanzahl von Instanzen auf 0 festlegen, wird die Worker-Instanz nicht gestartet, auch wenn die Bereitstellung erfolgreich ist.
Starten
Cloud Run-Worker-Pool-Instanzen starten den Container mit dem Einstiegspunkt, den Sie im Container-Image oder in der Worker-Pool-Konfiguration angeben. Alle Container in der Instanz müssen fehlerfrei sein.
Standardmäßig verwenden Cloud Run-Containerinstanzen eine CPU. Sie können diesen Wert erhöhen oder verringern, je nach Ihren Anforderungen.
Sie können eine Startprüfung konfigurieren, um festzustellen, ob der Container gestartet wurde. Mit der Startprüfung kann Cloud Run den Status eines abhängigen Containers prüfen. So wird sichergestellt, dass dieser erfolgreich durchlaufen wird, bevor er den nächsten Container startet. Wenn Sie keine Systemdiagnosen verwenden, startet Cloud Run Container in der angegebenen Reihenfolge, auch wenn die Container, von denen sie abhängen, nicht gestartet werden können.
Ressourcenzuweisung
Worker-Pools sind nicht im Leerlauf. Unabhängig vom Status weist Cloud Run immer CPU für alle Container zu, einschließlich Sidecars in einer Worker-Pool-Instanz. Solange eine Instanz ausgeführt wird, gilt sie als aktiv und wird entsprechend abgerechnet.
Herunterfahren
Cloud Run skaliert Worker-Pool-Instanzen nicht basierend auf Leerlaufinstanzen herunter. Wenn eine Instanz, die Arbeitslasten verarbeitet, heruntergefahren werden muss, haben die laufenden Aufgaben in Cloud Run Zeit, abgeschlossen zu werden. Neue Arbeitslasten werden an andere Instanzen weitergeleitet. Cloud Run kann auch ein Herunterfahren initiieren und ein SIGTERM-Signal an einen Container senden, der noch eine Arbeitslast verarbeitet.
Bevor Sie eine Instanz herunterfahren, sendet Cloud Run ein SIGTERM-Signal an alle Container in einer Instanz. Dieses Signal gibt den Beginn eines 10-Sekunden-Zeitraums vor dem tatsächlichen Herunterfahren an. An diesem Punkt sendet Cloud Run ein SIGKILL-Signal.
Während dieses Herunterfahrzeitraums wird der Instanz CPU zugewiesen und in Rechnung gestellt.
Wir empfehlen, einen SIGTERM-Handler in Ihrem Container zu installieren, um eine Warnung zu erhalten, wenn Cloud Run eine Instanz herunterfährt.
Erzwungene Beendigung
Wenn ein oder mehrere Cloud Run-Container das Speicherlimit für den gesamten Container überschreiten, wird die Instanz von Cloud Run beendet. Alle Anfragen, die noch auf der Instanz verarbeitet werden, werden mit dem Fehler HTTP 500 beendet.
Containerinstanzressourcen
In den folgenden Abschnitten werden Ressourcen für Ihre Containerinstanz beschrieben:
CPU
Jedem Cloud Run-Container in einer Instanz wird standardmäßig die vCPU zugewiesen, die konfiguriert wurde (Standard: 1). Es ist möglich, CPU-Limits für jeden Container separat zu konfigurieren.
Eine vCPU ist als Abstraktion einer zugrunde liegenden Hardware implementiert, um deren ungefähre CPU-Zeit für einen einzelnen Hardware-Hyper-Thread auf variablen CPU-Plattformen bereitzustellen. Alle von Cloud Run verwendeten CPU-Plattformen unterstützen den Befehl AVX2. Beachten Sie, dass der Containervertrag keine weiteren CPU-Plattformdetails enthält.
Der Container kann auf mehreren Kernen gleichzeitig ausgeführt werden.
Bei Cloud Run-Diensten hängt die CPU-Zuweisung von der ausgewählten Abrechnung ab.
Wenn Sie die instanzbasierte Abrechnung auswählen, wird die CPU während der Lebensdauer der Instanz zugewiesen. Wenn Sie die anfragebasierte Abrechnung (Standard) auswählen, wird die CPU zugewiesen, wenn Instanzen Anfragen verarbeiten. Weitere Informationen finden Sie in den Abrechnungseinstellungen.
Wenn Sie eine Reihe von Mindestinstanzen konfiguriert haben, müssen Sie die instanzbasierte Abrechnung verwenden, damit die CPU außerhalb von Anfragen zugewiesen wird.
Sie können den CPU-Boost beim Start aktivieren, um die CPU-Zuweisung während des Starts einer Instanz vorübergehend zu erhöhen, um die Startlatenz zu reduzieren.
Speicher
Jeder Cloud Run-Container wird standardmäßig der konfigurierte Speicher zugewiesen (standardmäßig 512 MiB). Es ist möglich, für jeden Container separat Arbeitsspeicherlimits zu konfigurieren.
Typische Einsatzmöglichkeiten des Speichers:
- Code in Speicher laden, um den Dienst auszuführen
- In das Dateisystem schreiben
- Zusätzliche Containerprozesse ausführen, z. B. einen Nginx-Server
- Speicherinterne Caching-Systeme wie OpCache von PHP
- Speichernutzung pro Anfrage
- Geteilte In-Memory-Volumes
GPU
Sie können einen Container in einer Cloud Run-Instanz so konfigurieren, dass er auf eine GPU zugreifen kann. Wenn der Cloud Run-Dienst mit Sidecar-Containern bereitgestellt wird, kann nur ein Container in der Bereitstellung auf die GPU zugreifen. Weitere Informationen zu den Anforderungen und Details finden Sie unter GPU konfigurieren.
NVIDIA-Bibliotheken
Standardmäßig werden alle NVIDIA L4-Treiberbibliotheken unter /usr/local/nvidia/lib64 bereitgestellt. Cloud Run hängt diesen Pfad automatisch an die Umgebungsvariable LD_LIBRARY_PATH (d.h. ${LD_LIBRARY_PATH}:/usr/local/nvidia/lib64) des Containers mit der GPU an. Dadurch kann der dynamische Linker die NVIDIA-Treiberbibliotheken finden. Der Linker sucht und löst Pfade in der Reihenfolge, die Sie in der Umgebungsvariablen LD_LIBRARY_PATH angeben. Alle Werte, die Sie in dieser Variablen angeben, haben Vorrang vor dem Standardpfad für Cloud Run-Treiberbibliotheken /usr/local/nvidia/lib64.
Wenn Sie eine CUDA-Version höher als 12.2 verwenden möchten, ist es am einfachsten, von einem neueren NVIDIA-Basis-Image abzuhängen, auf dem bereits Pakete für die Aufwärtskompatibilität installiert sind. Eine weitere Möglichkeit besteht darin, die NVIDIA-Pakete für die Aufwärtskompatibilität manuell zu installieren und sie zu LD_LIBRARY_PATH hinzuzufügen. Sehen Sie sich die Kompatibilitätsmatrix von NVIDIA an, um zu ermitteln, welche CUDA-Versionen mit der bereitgestellten NVIDIA-Treiberversion (535.216.03) aufwärtskompatibel sind.
Gleichzeitigkeit (Dienste)
Bei Cloud Run-Diensten ist jede Cloud Run-Instanz standardmäßig auf Gleichzeitigkeit festgelegt, wobei der Ingress-Container mehr als eine Anfrage gleichzeitig empfangen kann. Sie können dies ändern, indem Sie die Nebenläufigkeit festlegen.
Container-Sandbox
Wenn Sie die Ausführungsumgebung der ersten Generation verwenden, werden die Cloud Run-Container in der gVisor-Containerlaufzeit-Sandbox ausgeführt. Wie in der Referenz zur gVisor-syscall-Kompatibilität dokumentiert, werden einige Systemaufrufe möglicherweise von dieser Container-Sandbox nicht unterstützt.
Wenn Sie die Ausführungsumgebung der zweiten Generation verwenden, ist Ihre Linux-Kompatibilität vollständig.
Cloud Run-Jobs verwenden immer die Ausführungsumgebung der zweiten Generation.
In der Ausführungsumgebung der zweiten Generation ist /sys/class/dmi/id/product_name auf Google Compute Engine gesetzt.
Die Ausführungsumgebung der zweiten Generation führt Ihren Dienstcode in einem separaten Prozess-Namespace aus, sodass er mit dem Container-init-Prozess beginnt, der eine spezielle Prozesssemantik hat. In der Ausführungsumgebung der ersten Generation wird der Dienstcode nicht als Container-Initialisierungsvorgang ausgeführt.
Limits für Dateideskriptoren
In Cloud Run-Umgebungen der ersten und zweiten Generation ist die Anzahl der Dateideskriptoren, die ein Prozess öffnen kann, auf 25.000 begrenzt. Dies gilt für den Container und alle untergeordneten Prozesse, die er erstellt (Forks). Dies ist ein festes Limit. Wenn Sie das Limit überschreiten, könnte die Instanz nicht mehr genug Dateideskriptoren/Sockets haben.
Limits in der Umgebung der zweiten Generation
Mit Ausnahme der oben beschriebenen Limits für Dateideskriptoren gelten in der Umgebung der zweiten Generation die Standard-Linux-Limits.
Die Grenzwerte für die Anzahl der Dateideskriptoren, die geöffnet werden können (wie in /proc/sys/fs/file-max angegeben), verwenden beispielsweise den Standardwert von etwa 10% des Arbeitsspeichers. Weitere Informationen finden Sie in der Kernel-Dokumentation unter file-max und file-nr.
Ebenso wird für max_map_count (wie in /proc/sys/vm/max_map_count erfasst), das die Anzahl der Speicherbereiche festlegt, die ein Prozess haben kann, der Standardwert von 65535 verwendet. Weitere Informationen finden Sie in der Kernel-Dokumentation unter max-map-count.
Privilegierte Container und setuid-Binärdateien
Cloud Run unterstützt keine privilegierten Container. Daher werden in Cloud Run keine Binärdateien unterstützt, die setuid-Flags für Nutzer ohne Root-Berechtigung verwenden, z. B. gcsfuse oder sudo. Die Ausführung kann aufgrund unzureichender Berechtigungen fehlschlagen.
Eine Alternative besteht darin, diese Binärdateien als Root-Nutzer auszuführen und dann mit dem Befehl su zur Laufzeit zu einem anderen Nutzer zu wechseln.
Entfernen Sie beispielsweise in Ihrem Dockerfile die Anweisung USER und verwenden Sie in Ihrem Einstiegspunkt-Skript die folgende Sequenz:
gcsfuse ... # Run gcsfuse as root
su myuser -c "/yourapp.sh" # Switch to 'myuser' and run 'yourapp.sh'
Ausführender Nutzer
Wenn der Nutzername nicht vorhanden ist, wird der Container in Cloud Run als Root-Nutzer (uid=0) ausgeführt.
Metadatenserver der Instanz
Cloud Run-Instanzen stellen einen Metadatenserver bereit, mit dem Sie Details zu Ihren Containern abrufen können, z. B. Projekt-ID, Region, Instanz-ID oder Dienstkonten. Sie können den Metadatenserver auch verwenden, um Tokens für die Dienstidentität zu generieren.
Um auf Metadatenserverdaten zuzugreifen, verwenden Sie HTTP-Anfragen an den Endpunkt http://metadata.google.internal/ mit dem Header Metadata-Flavor: Google. Es sind keine Clientbibliotheken erforderlich. Weitere Informationen finden Sie unter Metadaten abrufen.
In der folgenden Tabelle sind einige der verfügbaren Metadatenserver-Informationen aufgeführt:
| Pfad | Beschreibung |
|---|---|
/computeMetadata/v1/project/project-id |
Projekt-ID des Projekts, zu dem der Cloud Run-Dienst oder -Job gehört |
/computeMetadata/v1/project/numeric-project-id |
Projektnummer des Projekts, zu dem der Cloud Run-Dienst oder -Job gehört |
/computeMetadata/v1/instance/region |
Region dieses Cloud Run-Dienstes oder -Jobs, gibt projects/PROJECT-NUMBER/regions/REGION zurück |
/computeMetadata/v1/instance/id |
Eindeutige Kennung der Instanz (auch in Logs verfügbar). |
/computeMetadata/v1/instance/service-accounts/default/email |
E-Mail für die Dienstidentität dieses Cloud Run-Dienstes oder Jobs. |
/computeMetadata/v1/instance/service-accounts/default/token |
Generiert ein OAuth2-Zugriffstoken für das Dienstkonto dieses Cloud Run-Dienstes oder -Jobs. Der Cloud Run-Dienst-Agent wird zum Abrufen eines Tokens verwendet. Dieser Endpunkt gibt eine JSON-Antwort mit einem access_token-Attribut zurück. Weitere Informationen zum Extrahieren und Verwenden dieses Zugriffstokens |
Cloud Run erteilt keine Informationen darüber, in welcher Google Cloud -Zone die Instanzen ausgeführt werden. Daher gibt das Metadatenattribut /computeMetadata/v1/instance/zone immer projects/PROJECT-NUMBER/zones/REGION-1 zurück.
Dateinamen
Die in Containern verwendeten Dateinamen müssen UTF-8-kompatibel sein; entweder UTF-8 oder ein Format, das sicher automatisch in UTF-8 konvertiert werden kann. Wenn Ihre Dateinamen unterschiedliche Codierungen verwenden, führen Sie den Docker-Build auf einem Computer mit UTF-8-kompatiblen Dateinamen aus. Vermeiden Sie das Kopieren von Dateien in einen Container, der inkompatible UTF-8-Namen enthält.
Die Container-Bereitstellung schlägt fehl, wenn Dateinamen nicht UTF-8-kompatibel sind. Beachten Sie, dass es keine Beschränkung für die Zeichencodierung gibt, die Sie in einer Datei verwenden.
Zeitlimits für ausgehende Anfragen
Bei Cloud Run-Diensten und -Jobs tritt nach 10 Minuten Inaktivität Zeit für Anfragen von Ihrem Container an die VPC auf. Bei Anfragen von Ihrem Container an das Internet kommt es nach 20 Minuten Inaktivität zu einer Zeitüberschreitung.
Ausgehende Verbindungen werden zurückgesetzt
Verbindungsstreams von Ihrem Container zu VPC und dem Internet können gelegentlich beendet und ersetzt werden, wenn die zugrunde liegende Infrastruktur neu gestartet oder aktualisiert wird. Wenn Ihre Anwendung langlebige Verbindungen wiederverwendet, sollten Sie Ihre Anwendung so konfigurieren, dass Verbindungen wiederhergestellt werden, um eine Wiederverwendung einer inaktiven Verbindung zu vermeiden.