Diese Dokumentation bezieht sich auf die neueste Version von Knative Serving, die Flotten und Anthos Service Mesh verwendet. Weitere Informationen

Die vorherige Version (Cloud Run for Anthos) wurde archiviert. Die Dokumentation ist für bestehende Nutzer aber weiterhin verfügbar.

Verfügbare Versionen

Neueste
Archivieren

Containerlaufzeitvertrag

Auf dieser Seite werden die wichtigsten Anforderungen und Verhaltensweisen von Containern in Knative-Bereitstellung aufgeführt.

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. Knative Serving unterstützt speziell das Linux x86_64-ABI-Format.

Anfragen auf dem richtigen Port überwachen

Der Container muss eine Überwachung von Anfragen an 0.0.0.0 an dem Port ausführen, an den die Anfragen gesendet werden. Standardmäßig werden Anfragen an 8080 gesendet, aber Sie können Knative Serving so konfigurieren, dass Anfragen an den Port Ihrer Wahl gesendet werden.

In Knative Serving-Containerinstanzen entspricht der Wert der Umgebungsvariablen PORT immer dem Port, an den Anfragen gesendet werden. Der Standardwert ist 8080.

Verschlüsselung auf Transportebene (TLS)

Der Container sollte die Sicherheit der Transportebene nicht direkt implementieren. TLS wird von Knative Serving für HTTPS und gRPC beendet und dann werden Anfragen als HTTP oder gRPC ohne TLS an den Container weitergeleitet.

Antworten

Ihre Containerinstanz muss innerhalb des in der Einstellung für die Zeitüberschreitung bei Anfragen angegebenen Zeitraums eine Antwort senden, einschließlich der Startzeit der Containerinstanz. Andernfalls wird die Anfrage beendet und der Fehler 504 wird ausgegeben.

Umgebungsvariablen

Die folgenden Umgebungsvariablen werden den ausgeführten Containern automatisch hinzugefügt:

Name	Beschreibung	Beispiel
`PORT`	Der Port, den Ihr HTTP-Server beobachten soll.	`8080`
`K_SERVICE`	Der Name des ausgeführten Knative Serving-Dienstes.	`hello-world`
`K_REVISION`	Der Name der ausgeführten Knative Serving-Überarbeitung.	`hello-world.1`
`K_CONFIGURATION`	Der Name der Knative Serving-Konfiguration, mit der die Überarbeitung erstellt wurde.	`hello-world`

Dateisystemzugriff

Das Dateisystem Ihres Containers ist beschreibbar und unterliegt dem folgenden Verhalten:

Da es sich um ein speicherinternes Dateisystem handelt, wird beim Schreiben der Arbeitsspeicher der Containerinstanz verwendet.
In das Dateisystem geschriebene Daten gehen verloren, wenn die Containerinstanz beendet wird.

Lebenszyklus einer Containerinstanz

Als Reaktion auf eingehende Anfragen wird ein Dienst automatisch auf eine bestimmte Anzahl von Containerinstanzen skaliert, von denen jede das bereitgestellte Container-Image ausführt.

Wenn eine Überarbeitung keinen Traffic empfängt, wird sie auf die konfigurierte Mindestanzahl von Containerinstanzen herunterskaliert (standardmäßig null).

Starten

Die Containerinstanzen müssen vier Minuten lang nach dem Start eine Überwachung auf Anfragen ausführen. Während dieser Startzeit wird den Containerinstanzen CPU zugewiesen.

Berechnung ist auf eine Anfrage beschränkt

Nach dem Start können Rechenvorgänge nur im Bereich einer Anfrage ausgeführt werden: Einer Containerinstanz ist keine CPU zugewiesen, wenn sie keine Anfrage verarbeitet.

Herunterfahren

Eine Containerinstanz kann jederzeit heruntergefahren werden.

Wenn eine Containerinstanz heruntergefahren werden muss, werden neue eingehende Anfragen an andere Instanzen weitergeleitet und die aktuell verarbeiteten Anfragen werden abgeschlossen. Die Containerinstanz erhält dann ein SIGTERM-Signal, das den Beginn einer Zeitspanne von 10 Sekunden angibt, bevor die Instanz heruntergefahren wird (mit einem SIGKILL-Signal). In diesem Zeitraum wird der Containerinstanz CPU zugewiesen und in Rechnung gestellt. Wenn die Containerinstanz das Signal SIGTERM nicht erfasst, wird sie sofort heruntergefahren.

Eine Containerinstanz ist nicht länger als 15 Minuten inaktiv, es sei denn, sie muss aufgrund der Konfigurationseinstellung für die Mindestzahl von Containerinstanzen inaktiv sein.

Containerinstanzressourcen

Die Ressourcenanforderungen für Ihre Containerinstanzen werden in den Knoten Ihres GKE-Clusters geplant. Jeder Knoten teilt die für Ihren GKE-Cluster verfügbaren Rechenressourcen.

Daher ist die Menge der für einen Knative Serving-Dienst verfügbaren Rechenressourcen nur durch die Menge der verfügbaren Ressourcen in diesem Knoten begrenzt. Weitere Informationen finden Sie unter Rechenressourcen für Anfragen.

Wenn Sie beispielsweise einem Container 512 MiB Speicher zuweisen und dieser Container in dem einzigen Pod innerhalb eines Knotens mit 8 GiB Arbeitsspeicher ausgeführt wird, kann der Container versuchen, mehr RAM zu nutzen.

CPU

Standardmäßig reserviert der Warteschlangen-Proxy-Sidecar 25 MilliCPU. Die Anzahl der vCPUs, die Ihre Knative Serving-Dienste nutzen können, ist nicht begrenzt. Der Ressourcenverbrauch des Warteschlangenproxys hängt von der Anzahl der Anfragen in der Warteschlange und der Größe der Anfragen ab.

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. Die Containerinstanz kann auf mehreren Kernen gleichzeitig ausgeführt werden. Die vCPU wird nur während des Starts und der Anfrageverarbeitung der Containerinstanz zugewiesen. Andernfalls wird sie gedrosselt.

Wenn Sie einen anderen vCPU-Wert zuweisen möchten, lesen Sie die Dokumentation zum Zuordnen von CPU.

Speicher

Standardmäßig reserviert der Warteschlangen-Proxy-Sidecar keinen Arbeitsspeicher und es gibt keine Beschränkung für die Größe von Arbeitsspeicher, den Ihre Knative Serving-Dienste verwenden können. Bei Bedarf können Sie Speicherlimits für Ihre Knative Serving-Dienste konfigurieren. Weitere Informationen dazu, wie GKE Arbeitsspeicher verarbeitet, finden Sie unter Zuweisbare Arbeitsspeicher- und CPU-Ressourcen.

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
Speichernutzung pro Anfrage

Gleichzeitigkeit

Jede Knative Serving-Containerinstanz ist standardmäßig auf Gleichzeitigkeit eingestellt, wobei jede Containerinstanz mehr als eine Anfrage gleichzeitig erhalten kann. Sie können dies ändern und eine Gleichzeitigkeit festlegen.

Sandbox für Containerinstanzen

Knative Serving verwendet keine Container-Sandbox.

Metadatenserver der Containerinstanz

Knative Serving-Containerinstanzen stellen einen Metadatenserver bereit, mit dem Sie Details zu Ihrer Containerinstanz abrufen können, z. B. Projekt-ID, Region, Instanz-ID oder Dienstkonten.

Sie können auf diese Daten vom Metadatenserver mit einfachen HTTP-Anfragen an den Endpunkt http://metadata.google.internal/ mit dem Header Metadata-Flavor: Google zugreifen. 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 dieses Knative Serving-Dienstes
`/computeMetadata/v1/instance/region`	Region dieses Knative Serving-Dienstes
`/computeMetadata/v1/instance/id`	Eindeutige Kennung der Containerinstanz (auch in Logs verfügbar).
`/computeMetadata/v1/instance/service-accounts/default/token`	Generiert ein Token für das Laufzeitdienstkonto dieses Knative Serving-Dienstes