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-Dienste konfigurieren. Die Konfiguration variiert je nach Art der Prüfung.
Beachten Sie, dass eine TCP-Startprüfung automatisch für einen neuen Cloud Run-Dienst konfiguriert wird. Weitere Informationen finden Sie unter Standard-TCP-Startprü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 einem Fall die Dienstverfügbarkeit 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 Dienst ausgeführt wird, aber keine Fortschritte machen kann.
Startprüfungen ermitteln, ob der Container gestartet wurde und bereit ist, Traffic entgegenzunehmen.
- 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 Dienststarts 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 Dienst wiederholt Fehler bei Start- oder Aktivitätsprüfungen auftreten, begrenzt Cloud Run Instanzneustarts, um unkontrollierte Absturzschleifen zu verhindern.
Die standardmäßige TCP-Startprüfung
Eine TCP-Startprüfung wird automatisch für einen neuen Cloud Run-Dienst mit Standardwerten konfiguriert. Die Standardprüfung entspricht Folgendem:
startupProbe: tcpSocket: port: CONTAINER_PORT timeoutSeconds: 240 periodSeconds: 240 failureThreshold: 1
Ersetzen Sie CONTAINER_PORT durch den für Ihren Dienst festgelegten Containerport.
Sie können diese Standardwerte gemäß der Anleitung im Abschnitt Prüfungskonfiguration auf dieser Seite ändern.
Abrechnung und CPU-Zuordnung
- Die CPU wird für jede Prüfung zugewiesen.
- Bei allen Prüfungen werden für die Nutzung von CPU und Arbeitsspeicher Kosten in Rechnung gestellt, es fallen jedoch keine anfragebasierten Gebühren an.
Prüfungsanforderungen und -verhalten
Prüfungstyp | Voraussetzungen | Verhalten |
---|---|---|
TCP-Start | Keine | Standardmäßig 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 ( failureThreshold * periodSeconds ), darf 240 nicht überschritten werden. Sekunden, wird der Container heruntergefahren. Siehe auch TCP-Standardeinstellungen. |
HTTP-Start | Erstellen Sie einen HTTP-Systemdiagnose-Endpunkt Verwenden Sie HTTP/1 |
Nach der Prüfungskonfiguration stellt Cloud Run eine HTTP-GET-Anfrage an den Endpunkt der Systemdiagnose für die Dienste (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 nicht erfolgreich ist ( failureThreshold * periodSeconds ), die 240 Sekunden nicht überschreiten darf, wird der Container heruntergefahren.Wenn die HTTP-Startprüfung innerhalb der angegebenen Zeit erfolgreich ist und Sie eine HTTP-Aktivitätsprüfung konfiguriert haben, wird diese 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. Nachdem die Prüfungskonfiguration und jede Startprüfung erfolgreich ist, sendet Cloud Run eine HTTP-GET-Anfrage an den Endpunkt der Systemdiagnose für die Dienste (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 nicht erfolgreich ist ( failureThreshold * periodSeconds ) ) wird der Container mit einem SIGKILL -Signal heruntergefahren. Alle verbleibenden Anfragen, die noch vom Container verarbeitet wurden, werden mit dem HTTP-Statuscode 503 beendet. Nachdem der Container heruntergefahren wurde, startet Cloud Run-Autoscaling eine neue Containerinstanz. |
gRPC-Start | Implementieren Sie das gRPC-Systemdiagnoseprotokoll in Ihrem Cloud Run-Dienst | Wenn eine Startprüfung innerhalb der angegebenen Zeit (failureThreshold * periodSeconds ) nicht erfolgreich ist, die 240 Sekunden nicht überschreiten kann, wird der Container heruntergefahren. |
gRPC-Aktivität | Implementieren Sie das gRPC-Systemdiagnoseprotokoll in Ihrem Cloud Run-Dienst | Wenn Sie eine gRPC-Startprüfung konfigurieren, wird diese erst gestartet, nachdem die Startprüfung erfolgreich war. Nachdem die Aktivitätsprüfung konfiguriert wurde und jede Startprüfung erfolgreich ist, stellt Cloud Run eine Systemdiagnoseanfrage an Der Service. Wenn eine Aktivitätsprüfung innerhalb der angegebenen Zeit ( failureThreshold * periodSeconds ) nicht erfolgreich ist, wird der Container mit einem SIGKILL -Signal heruntergefahren. Nachdem der Container heruntergefahren wurde, startet 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 Google Cloud Console, YAML oder Terraform konfigurieren:
Console
Wichtig: Wenn Sie Ihren Cloud Run-Dienst für HTTP-Prüfungen konfigurieren, müssen Sie dem Dienstcode 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-Dienst implementieren.
Wechseln Sie in der Google Cloud Console zur Seite Cloud Run.
Erweitern Sie für einen neuen Dienst Container, Volumes, Netzwerk, Sicherheit, um die Optionen der Systemdiagnose aufzurufen. Klicken Sie für einen vorhandenen Dienst auf den Dienst, den Sie konfigurieren möchten, und dann auf Bearbeiten und Bereitstellen, um die Optionen für die Systemdiagnose aufzurufen.
Im Abschnitt Container wechseln Sie zu Systemdiagnosen und klicken Sie auf Systemdiagnose hinzufügen, um den Konfigurationsbereich Systemdiagnose hinzufügen zu öffnen.
Wählen Sie im Menü Typ der Systemdiagnose auswählen den Typ der Systemdiagnose aus, die Sie hinzufügen möchten, z. B. Start oder Aktivität.
Wählen Sie im Menü Prüfungstyp auswählen den Typ der Prüfung aus, den Sie verwenden möchten, z. B. HTTP oder gRPC. Dadurch wird das Formular zur Prüfungskonfiguration angezeigt.
Beachten Sie, dass die Prüfungskonfiguration je nach Prüfungstyp variiert. Konfigurieren Sie die Prüfungseinstellungen:
- Wenn Sie HTTP-Prüfungen verwenden:
- Achten Sie darauf, dass Ihr Dienst HTTP/1 (den Cloud Run-Standard) verwendet, nicht HTTP/2.
- Geben Sie im Feld Pfad den relativen Pfad zum Endpunkt an, z. B.
/
. - Klicken Sie das Kästchen HTTP-Header an, um optionale benutzerdefinierte Header anzugeben. Geben Sie dann den Header-Namen im Feld Name und den Header-Wert im Feld Wert an. Klicken Sie auf HTTP-Header hinzufügen, um weitere Header anzugeben.
- Geben Sie unter Port den für Ihren Dienst verwendeten Containerport an.
- Geben Sie unter Anfängliche Verzögerung die Anzahl der Sekunden an, die nach dem Start des Containers gewartet werden soll, bevor die erste Prüfung ausgeführt wird. Geben Sie einen Wert zwischen 0 Sekunden und 240 Sekunden an. Der Standardwert beträgt 0 Sekunden.
- Geben Sie für Period den Zeitraum in Sekunden an, in dem die Prüfung ausgeführt werden soll. Beispiel:
2
, um die Prüfung alle zwei Sekunden durchzuführen. Geben Sie einen Wert zwischen 1 Sekunde und 240 Sekunden an. Der Standardwert beträgt 10 Sekunden. - Geben Sie als Fehlerschwellenwert an, wie oft die Prüfung wiederholt werden soll, bevor der Container heruntergefahren wird. Der Standardwert ist 3.
- Geben Sie unter Zeitlimit die Anzahl der Sekunden an, die gewartet werden soll, bis das Zeitlimit der Prüfung überschritten wird. Dieser Wert darf den für
periodSeconds
angegebenen Wert nicht überschreiten. Geben Sie einen Wert zwischen 1 und 240 an. Der Standardwert ist 1.
- Wenn Sie HTTP-Prüfungen verwenden:
Klicken Sie auf Hinzufügen, um den neuen Schwellenwert hinzuzufügen.
YAML
Wichtig: Wenn Sie Ihren Cloud Run-Dienst für HTTP-Prüfungen konfigurieren, müssen Sie dem Dienstcode auch einen 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-Dienst implementieren.
TPC-Start
-
Wenn Sie einen neuen Dienst erstellen, überspringen Sie diesen Schritt. Wenn Sie einen vorhandenen Dienst aktualisieren, laden Sie die zugehörige YAML-Konfiguration herunter:
gcloud run services describe SERVICE --format export > service.yaml
Konfigurieren Sie das Attribut
startupProbe
so:apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: metadata: spec: containers: - image: IMAGE_URL startupProbe: tcpSocket: port: CONTAINER_PORT initialDelaySeconds: DELAY timeoutSeconds: TIMEOUT failureThreshold: THRESHOLD periodSeconds: PERIOD
Ersetzen
- SERVICE durch den Namen Ihres Cloud Run-Dienstes.
- 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
. - (OPTIONAL) CONTAINER_PORT sollte auf den Containerport festgelegt sein, der für Ihren Dienst verwendet wird.
- DELAY mit der Anzahl der Sekunden, die nach dem Start des Containers gewartet werden soll, bevor die erste Prüfung ausgeführt wird. Geben Sie einen Wert zwischen 0 Sekunden und 240 Sekunden an. Der Standardwert beträgt 0 Sekunden.
- (OPTIONAL) TIMEOUT durch die Anzahl der Sekunden, die gewartet wird, bis das Zeitlimit der Prüfung überschritten wird. Dieser Wert darf den für
periodSeconds
angegebenen Wert nicht überschreiten. Geben Sie einen Wert zwischen 1 und 240 an. Der Standardwert ist 1. - THRESHOLD mit der Anzahl der Wiederholungen der Prüfung, bevor der Container heruntergefahren wird. Der Standardwert ist 3.
- PERIOD durch das Intervall (in Sekunden), in dem die Prüfung durchgeführt werden soll.
Beispiel:
2
, um die Prüfung alle zwei Sekunden durchzuführen. Geben Sie einen Wert zwischen 1 Sekunde und 240 Sekunden an. Der Standardwert beträgt 10 Sekunden.
-
Erstellen oder aktualisieren Sie den Dienst mit dem folgenden Befehl:
gcloud run services replace service.yaml
HTTP-Start
-
Wenn Sie einen neuen Dienst erstellen, überspringen Sie diesen Schritt. Wenn Sie einen vorhandenen Dienst aktualisieren, laden Sie die zugehörige YAML-Konfiguration herunter:
gcloud run services describe SERVICE --format export > service.yaml
Achten Sie darauf, dass Ihr Dienst HTTP/1 (den Cloud Run-Standard) verwendet, nicht HTTP/2.
Konfigurieren Sie das Attribut
startupProbe
so:apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: metadata: spec: containers: - image: IMAGE_URL startupProbe: httpGet: path: PATH port: CONTAINER_PORT httpHeaders: - name: HEADER_NAME value: HEADER_VALUE initialDelaySeconds: DELAY timeoutSeconds: TIMEOUT failureThreshold: THRESHOLD periodSeconds: PERIOD
Ersetzen
- SERVICE durch den Namen Ihres Cloud Run-Dienstes.
- 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
. - PATH durch den relativen Pfad zum HTTP-Endpunkt, z. B.
/ready
. - (OPTIONAL) CONTAINER_PORT sollte auf den Containerport festgelegt sein, der für Ihren Dienst verwendet wird.
- (OPTIONAL)
httpHeaders
kann verwendet werden, um mehrere oder wiederkehrende benutzerdefinierte Header mithilfe der Felder HEADER_NAME und HEADER_VALUE anzugeben. - (OPTIONAL) DELAY mit der Anzahl der Sekunden, die gewartet werden soll, bis der Container gestartet wurde, bevor die erste Prüfung ausgeführt wird. Geben Sie einen Wert zwischen 0 Sekunden und 240 Sekunden an. Der Standardwert beträgt 0 Sekunden.
- (OPTIONAL) TIMEOUT durch die Anzahl der Sekunden, die gewartet wird, bis das Zeitlimit der Prüfung überschritten wird. Dieser Wert darf den für
periodSeconds
angegebenen Wert nicht überschreiten. Geben Sie einen Wert zwischen 1 und 240 an. Der Standardwert ist 1. - (OPTIONAL) THRESHOLD mit der Anzahl der Wiederholungen der Prüfung, bevor der Container heruntergefahren wird. Der Standardwert ist 3.
- (OPTIONAL) PERIOD durch das Intervall (in Sekunden), in dem die Prüfung ausgeführt werden soll.
Beispiel:
2
, um die Prüfung alle zwei Sekunden durchzuführen. Geben Sie einen Wert zwischen 1 Sekunde und 240 Sekunden an. Der Standardwert beträgt 10 Sekunden.
-
Erstellen oder aktualisieren Sie den Dienst mit dem folgenden Befehl:
gcloud run services replace service.yaml
HTTP-Aktivität
-
Wenn Sie einen neuen Dienst erstellen, überspringen Sie diesen Schritt. Wenn Sie einen vorhandenen Dienst aktualisieren, laden Sie die zugehörige YAML-Konfiguration herunter:
gcloud run services describe SERVICE --format export > service.yaml
Achten Sie darauf, dass Ihr Dienst HTTP/1 (den Cloud Run-Standard) verwendet, nicht HTTP/2.
Konfigurieren Sie das Attribut
livenessProbe
so:apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: metadata: spec: containers: - image: IMAGE_URL livenessProbe: httpGet: path: PATH port: CONTAINER_PORT httpHeaders: - name: HEADER_NAME value: HEADER_VALUE initialDelaySeconds: DELAY timeoutSeconds: TIMEOUT failureThreshold: THRESHOLD periodSeconds: PERIOD
Ersetzen
- SERVICE durch den Namen Ihres Cloud Run-Dienstes.
- 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
. - PATH durch den relativen Pfad zum HTTP-Endpunkt, z. B.
/ready
. - (OPTIONAL) CONTAINER_PORT sollte auf den Containerport festgelegt sein, der für Ihren Dienst verwendet wird.
- (OPTIONAL)
httpHeaders
kann verwendet werden, um mehrere oder wiederkehrende benutzerdefinierte Header mithilfe der Felder HEADER_NAME und HEADER_VALUE anzugeben. - (OPTIONAL) DELAY mit der Anzahl der Sekunden, die gewartet werden soll, bis der Container gestartet wurde, bevor die erste Prüfung ausgeführt wird. Geben Sie einen Wert zwischen 0 Sekunden und 240 Sekunden an. Der Standardwert beträgt 0 Sekunden.
- (OPTIONAL) TIMEOUT durch die Anzahl der Sekunden, die gewartet wird, bis das Zeitlimit der Prüfung überschritten wird. Dieser Wert darf den für
periodSeconds
angegebenen Wert nicht überschreiten. Geben Sie einen Wert zwischen 1 und 3.600 an. Der Standardwert ist 1. - (OPTIONAL) THRESHOLD mit der Anzahl der Wiederholungen der Prüfung, bevor der Container heruntergefahren wird. Der Standardwert ist 3.
- (OPTIONAL) PERIOD durch das Intervall (in Sekunden), in dem die Prüfung ausgeführt werden soll.
Beispiel:
2
, um die Prüfung alle zwei Sekunden durchzuführen. Geben Sie einen Wert zwischen 1 Sekunde und 3.600 Sekunden an. Der Standardwert beträgt 10 Sekunden.
-
Erstellen oder aktualisieren Sie den Dienst mit dem folgenden Befehl:
gcloud run services replace service.yaml
gRPC-Start
-
Wenn Sie einen neuen Dienst erstellen, überspringen Sie diesen Schritt. Wenn Sie einen vorhandenen Dienst aktualisieren, laden Sie die zugehörige YAML-Konfiguration herunter:
gcloud run services describe SERVICE --format export > service.yaml
Konfigurieren Sie das Attribut
startupProbe
so:apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: metadata: spec: containers: - image: IMAGE_URL startupProbe: grpc: service: GRPC_SERVICE port: CONTAINER_PORT initialDelaySeconds: DELAY timeoutSeconds: TIMEOUT failureThreshold: THRESHOLD periodSeconds: PERIOD
Ersetzen
- SERVICE durch den Namen Ihres Cloud Run-Dienstes.
- 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
. - GRPC_SERVICE durch den Namen des gRPC-Dienstes, an den die Systemdiagnose gesendet werden soll.
- (OPTIONAL) CONTAINER_PORT sollte auf den Containerport festgelegt sein, der für Ihren Dienst verwendet wird.
- (OPTIONAL) DELAY mit der Anzahl der Sekunden, die gewartet werden soll, bis der Container gestartet wurde, bevor die erste Prüfung ausgeführt wird. Geben Sie einen Wert zwischen 0 Sekunden und 240 Sekunden an. Der Standardwert beträgt 0 Sekunden.
- (OPTIONAL) Zeitüberschreitung durch die Anzahl der Sekunden, die gewartet wird, bis das Zeitlimit der Prüfung überschritten wird. Dieser Wert darf den für periodSeconds angegebenen Wert nicht überschreiten. Geben Sie einen Wert zwischen 1 und 240 an. Der Standardwert ist 1.
- (OPTIONAL) THRESHOLD mit der Anzahl der Wiederholungen der Prüfung, bevor der Container heruntergefahren wird. Der Standardwert ist 3.
- (OPTIONAL) PERIOD durch das Intervall (in Sekunden), in dem die Prüfung ausgeführt werden soll.
Beispiel:
2
, um die Prüfung alle zwei Sekunden durchzuführen. Geben Sie einen Wert zwischen 1 Sekunde und 240 Sekunden an. Der Standardwert beträgt 10 Sekunden.
-
Erstellen oder aktualisieren Sie den Dienst mit dem folgenden Befehl:
gcloud run services replace service.yaml
gRPC-Aktivität
-
Wenn Sie einen neuen Dienst erstellen, überspringen Sie diesen Schritt. Wenn Sie einen vorhandenen Dienst aktualisieren, laden Sie die zugehörige YAML-Konfiguration herunter:
gcloud run services describe SERVICE --format export > service.yaml
Konfigurieren Sie das Attribut
livenessProbe
so:apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: metadata: spec: containers: - image: IMAGE_URL livenessProbe: grpc: port: CONTAINER_PORT service: GRPC_SERVICE initialDelaySeconds: DELAY timeoutSeconds: TIMEOUT failureThreshold: THRESHOLD periodSeconds: PERIOD
Ersetzen
- SERVICE durch den Namen Ihres Cloud Run-Dienstes.
- 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
. - (OPTIONAL) CONTAINER_PORT sollte auf den Containerport festgelegt sein, der für Ihren Dienst verwendet wird.
- GRPC_SERVICE durch den Namen des gRPC-Dienstes, an den die Systemdiagnose gesendet werden soll.
- (OPTIONAL) DELAY mit der Anzahl der Sekunden, die gewartet werden soll, bis der Container gestartet wurde, bevor die erste Prüfung ausgeführt wird. Geben Sie einen Wert zwischen 0 Sekunden und 240 Sekunden an. Der Standardwert beträgt 0 Sekunden.
- (OPTIONAL) TIMEOUT durch die Anzahl der Sekunden, die gewartet wird, bis das Zeitlimit der Prüfung überschritten wird. Dieser Wert darf den für
periodSeconds
angegebenen Wert nicht überschreiten. Geben Sie einen Wert zwischen 1 und 3.600 an. Der Standardwert ist 1. - (OPTIONAL) THRESHOLD mit der Anzahl der Wiederholungen der Prüfung, bevor der Container heruntergefahren wird. Der Standardwert ist 3.
- (OPTIONAL) PERIOD durch das Intervall (in Sekunden), in dem die Prüfung ausgeführt werden soll. Beispiel:
2
, um die Prüfung alle zwei Sekunden durchzuführen. Geben Sie einen Wert zwischen 1 Sekunde und 3.600 Sekunden an. Der Standardwert beträgt 10 Sekunden.
-
Erstellen oder aktualisieren Sie den Dienst mit dem folgenden Befehl:
gcloud run services replace service.yaml
Terraform
Wichtig: Wenn Sie Ihren Cloud Run-Dienst für HTTP-Prüfungen konfigurieren, müssen Sie dem Dienstcode auch einen 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-Dienst implementieren.
Informationen zum Anwenden oder Entfernen einer Terraform-Konfiguration finden Sie unter Grundlegende Terraform-Befehle.
TCP-Start
Konfigurieren Sie Ihren Cloud Run-Dienst mit dem Attribut startup_probe
so:
HTTP-Start
Achten Sie darauf, dass Ihr Dienst HTTP/1 (den Cloud Run-Standard) verwendet, nicht HTTP/2.
Konfigurieren Sie Ihren Cloud Run-Dienst mit dem Attribut startup_probe
so:
HTTP-Aktivität
Achten Sie darauf, dass Ihr Dienst HTTP/1 (den Cloud Run-Standard) verwendet, nicht HTTP/2.
Konfigurieren Sie Ihren Cloud Run-Dienst mit dem Attribut liveness_probe
so:
gRPC-Start
Konfigurieren Sie Ihren Cloud Run-Dienst mit dem Attribut startup_probe
so:
gRPC-Aktivität
Konfigurieren Sie Ihren Cloud Run-Dienst mit dem Attribut liveness_probe
so:
HTTP-Systemdiagnose-Endpunkte erstellen
Wenn Sie den Cloud Run-Dienst für eine HTTP-Start- oder Aktivitätsprüfung konfigurieren, müssen Sie dem Dienstcode 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 den Werten übereinstimmen, die 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-Dienstendpunkte.