Container-Systemdiagnosen für Worker-Pools konfigurieren

Sie können HTTP-, TCP- und gRPC-Start-up-Prüfungen sowie HTTP- und gRPC-Aktivitätsprüfungen für neue und vorhandene Cloud Run-Workerpools konfigurieren. Die Konfiguration variiert je nach Art der Prüfung.

Anwendungsfälle

Sie können zwei Arten von Systemdiagnoseprüfungen konfigurieren:

  • Aktivitätsprüfungen bestimmen, ob ein Container neu gestartet werden soll.

    • Durch einen Neustart eines Containers kann in diesem Fall die Verfügbarkeit des Worker-Pools bei Programmfehlern erhöht werden.
    • Aktivitätsprüfungen sollen einzelne Instanzen neu starten, die auf andere Weise nicht wiederhergestellt werden können. Sie sollten hauptsächlich für nicht wiederherstellbare Instanzfehler verwendet werden, um beispielsweise einen Deadlock zu erkennen, wenn ein Worker-Pool ausgeführt wird, aber keine Fortschritte machen kann. Mithilfe von benutzerdefinierten Organisationsrichtlinien können Sie für jeden Container eine Aktivitätsprüfung erzwingen.

  • Startprüfungen ermitteln, ob der Container gestartet wurde.

    • Wenn Sie eine Startprüfung konfigurieren, werden Aktivitätsprüfungen deaktiviert, bis die Startprüfung feststellt, dass der Container gestartet wurde, um Störungen des Worker-Pool-Starts zu vermeiden.
    • Startprüfungen sind besonders nützlich, wenn Sie Aktivitätsprüfungen für langsam startende Container verwenden, da sie verhindern, dass sie vorzeitig heruntergefahren werden, bevor die Container ausgeführt werden.

Wenn bei einem Worker-Pool wiederholt Fehler bei Start- oder Aktivitätsprüfungen auftreten, verhindert Cloud Run unkontrollierte Absturzschleifen, indem es Instanzneustarts begrenzt.

CPU-Zuweisung

  • Die CPU wird immer zugewiesen, wenn Prüfungen ausgeführt werden.
  • Bei allen Prüfungen werden für die Nutzung von CPU und Arbeitsspeicher Kosten in Rechnung gestellt.

Prüfungsanforderungen und -verhalten

Prüfungstyp Voraussetzungen Verhalten
TCP-Start Keine Falls angegeben, stellt Cloud Run eine TCP-Verbindung her, um den TCP-Socket am angegebenen Port zu öffnen. Wenn Cloud Run keine Verbindung herstellen kann, weist dies auf einen Fehler hin.

Wenn eine Startprüfung innerhalb der angegebenen Zeit nicht erfolgreich ist, wird der Container von Cloud Run heruntergefahren. Die Zeit beträgt maximal 240 Sekunden und wird als failureThreshold * periodSeconds berechnet. Sie legen sie bei der Konfiguration der Startprüfung für den Worker-Pool fest.
HTTP-Start Erstellen Sie einen HTTP-Systemdiagnose-Endpunkt
Verwenden Sie HTTP/1		 Nach der Konfiguration der Prüfung sendet Cloud Run eine HTTP-GET-Anfrage an den Endpunkt der Systemdiagnose des Worker-Pools (z. B. /ready). Jede Antwort zwischen 200 und 400 ist ein Erfolg. Alles andere zeigt einen Fehler an.

Wenn eine Startprüfung innerhalb der angegebenen Zeit (failureThreshold × periodSeconds) nicht erfolgreich ist, darf 240 nicht überschritten werden. Sekunden, wird der Container von Cloud Run heruntergefahren.

Wenn die HTTP-Startprüfung innerhalb der angegebenen Zeit erfolgreich ist und Sie eine HTTP-Aktivitätsprüfung konfiguriert haben, wird diese von Cloud Run gestartet.
HTTP-Aktivität Erstellen Sie einen HTTP-Systemdiagnose-Endpunkt
Verwenden Sie HTTP/1		 Die Aktivitätsprüfung wird erst gestartet, wenn die Startprüfung erfolgreich war. Nach der Konfiguration der Prüfung und wenn eine Startprüfung erfolgreich ist, sendet Cloud Run eine HTTP-GET-Anfrage an den Endpunkt der Systemdiagnose (z. B. /health). Jede Antwort zwischen 200 und 400 ist ein Erfolg. Alles andere zeigt einen Fehler an.

Wenn eine Aktivitätsprüfung innerhalb der angegebenen Zeit (failureThreshold × periodSeconds) nicht erfolgreich ist, fährt Cloud Run den Container mit einem SIGKILL-Signal herunter. Alle verbleibenden Anfragen, die noch vom Container verarbeitet wurden, werden mit dem HTTP-Statuscode 503 beendet. Nachdem Cloud Run den Container heruntergefahren hat, startet das Cloud Run-Autoscaling eine neue Containerinstanz.
gRPC-Start Implementieren Sie das gRPC-Systemdiagnoseprotokoll in Ihrem Cloud Run-Workerpool Wenn eine Startprüfung innerhalb der angegebenen Zeit (failureThreshold * periodSeconds) nicht erfolgreich ist, die 240 Sekunden nicht überschreiten kann, wird der Container von Cloud Run heruntergefahren.
gRPC-Aktivität Implementieren Sie das gRPC-Systemdiagnoseprotokoll in Ihrem Cloud Run-Workerpool Wenn Sie eine gRPC-Startprüfung konfigurieren, wird die Aktivitätsprüfung erst gestartet, nachdem die Startprüfung erfolgreich war.

Nachdem die Aktivitätsprüfung konfiguriert wurde und jede Startprüfung erfolgreich ist, sendet Cloud Run eine Systemdiagnoseanfrage an den Worker-Pool.

Wenn eine Aktivitätsprüfung innerhalb der angegebenen Zeit (failureThreshold × periodSeconds) nicht erfolgreich ist, fährt Cloud Run den Container mit einem SIGKILL-Signal herunter. Nachdem Cloud Run den Container heruntergefahren hat, startet das Cloud Run-Autoscaling eine neue Containerinstanz.

Prüfungen konfigurieren

Jede Konfigurationsänderung führt zur Erstellung einer neuen Überarbeitung. Für nachfolgende Überarbeitungen gilt automatisch dieselbe Konfigurationseinstellung, sofern Sie sie nicht explizit aktualisieren.

Sie können HTTP-, TCP- und gRPC-Prüfungen mit der Cloud Run REST API konfigurieren:

REST API

Wichtig: Wenn Sie Ihren Cloud Run-Worker-Pool für HTTP-Prüfungen konfigurieren, müssen Sie dem Worker-Pool-Code auch einen HTTP-Systemdiagnose-Endpunkt hinzufügen, um auf die Prüfung zu reagieren. Wenn Sie eine gRPC-Prüfung konfigurieren, müssen Sie auch das gRPC-Systemdiagnoseprotokoll in Ihrem Cloud Run-Worker-Pool implementieren.

HTTP-Start

Verwenden Sie die REST API, um dies zu konfigurieren.

HTTP-Aktivität

Verwenden Sie die REST API, um dies zu konfigurieren.

gRPC-Start

Verwenden Sie die REST API, um dies zu konfigurieren.

gRPC-Aktivität

Verwenden Sie die REST API, um dies zu konfigurieren.

HTTP-Systemdiagnose-Endpunkte erstellen

Wenn Sie den Cloud Run-Worker-Pool für eine HTTP-Start- oder Aktivitätsprüfung konfigurieren, müssen Sie dem Worker-Pool-Code einen Endpunkt hinzufügen, der auf die Prüfung reagiert. Der Endpunkt kann einen beliebigen Namen haben, z. B. /startup oder /ready. Er muss jedoch mit dem Wert übereinstimmen, den Sie in der Prüfungskonfiguration für path angeben. Wenn Sie beispielsweise /ready für eine HTTP-Startprüfung angeben, geben Sie path in Ihrer Prüfungskonfiguration so an:

startupProbe:
  httpGet:
    path: /ready

HTTP-Systemdiagnose-Endpunkte sind extern zugänglich und folgen den gleichen Prinzipien wie alle anderen extern zugänglichen HTTP-Endpunkte.