Systemdiagnosen für Container konfigurieren (Dienste)

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 diesem 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. Mithilfe von benutzerdefinierten Organisationsrichtlinien können Sie für jeden Container eine Aktivitätsprüfung erzwingen.
  • 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

Prüfungsanforderungen und -verhalten

Prüfungstyp Voraussetzungen Verhalten
TCP-Start Ohne 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.

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud Run.

    Zu Cloud Run

  2. 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.

  3. Im Abschnitt Container wechseln Sie zu Systemdiagnosen und klicken Sie auf Systemdiagnose hinzufügen, um den Konfigurationsbereich Systemdiagnose hinzufügen zu öffnen.

  4. 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.

  5. 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.

  6. 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.
  7. 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.

TCP-Start

  1. 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
  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:
             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 Form LOCATION-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.
  3. Erstellen oder aktualisieren Sie den Dienst mit dem folgenden Befehl:
    gcloud run services replace service.yaml

HTTP-Start

  1. 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
  2. Achten Sie darauf, dass Ihr Dienst HTTP/1 (den Cloud Run-Standard) verwendet, nicht HTTP/2.

  3. 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 Form LOCATION-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.
  4. Erstellen oder aktualisieren Sie den Dienst mit dem folgenden Befehl:
    gcloud run services replace service.yaml

HTTP-Aktivität

  1. 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
  2. Achten Sie darauf, dass Ihr Dienst HTTP/1 (den Cloud Run-Standard) verwendet, nicht HTTP/2.

  3. 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 Form LOCATION-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.
  4. Erstellen oder aktualisieren Sie den Dienst mit dem folgenden Befehl:
    gcloud run services replace service.yaml

gRPC-Start

  1. 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
  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:
                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 Form LOCATION-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.
  3. Erstellen oder aktualisieren Sie den Dienst mit dem folgenden Befehl:
    gcloud run services replace service.yaml

gRPC-Aktivität

  1. 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
  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:
                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 Form LOCATION-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.
  3. 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:

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      startup_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        tcp_socket {
          port = 8080
        }
      }
    }
  }
}

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:

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      startup_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        http_get {
          path = "/"
          # Custom headers to set in the request
          # https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/cloud_run_v2_service#http_headers
          http_headers {
            name  = "Access-Control-Allow-Origin"
            value = "*"
          }
        }
      }
    }
  }
}

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:

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      liveness_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        http_get {
          path = "/"
          # Custom headers to set in the request
          # https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/cloud_run_v2_service#http_headers
          http_headers {
            name  = "Access-Control-Allow-Origin"
            value = "*"
          }
        }
      }
    }
  }
}

gRPC-Start

Konfigurieren Sie Ihren Cloud Run-Dienst mit dem Attribut startup_probe so:

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      # Note: Change to the name of your image
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      startup_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        grpc {
          # Note: Change to the name of your pre-existing grpc health status service
          service = "grpc.health.v1.Health"
        }
      }
    }
  }
}

gRPC-Aktivität

Konfigurieren Sie Ihren Cloud Run-Dienst mit dem Attribut liveness_probe so:

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      # Note: Change to the name of your image
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      liveness_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        # Note: Change to the name of your pre-existing grpc health status service
        grpc {
          service = "grpc.health.v1.Health"
        }
      }
    }
  }
}

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.