Configura las verificaciones de estado de los contenedores (servicios)

Puedes configurar sondeos de inicio de HTTP, TCP y gRPC, junto con sondeos de funcionamiento de HTTP y gRPC para servicios nuevos y existentes de Cloud Run. La configuración varía según el tipo de sondeo.

Ten en cuenta que un sondeo de inicio de TCP se configura de forma automática para un servicio de Cloud Run nuevo. Consulta El sondeo de inicio de TCP predeterminado para obtener más detalles.

Casos de uso

Puedes configurar dos tipos de sondeos de verificación de estado:

  • Los sondeos de funcionamiento determinan si el contenedor se debe reiniciar.

    • En este caso, reiniciar un contenedor puede aumentar la disponibilidad del servicio en caso de errores.
    • Los sondeos de funcionamiento están diseñados para reiniciar instancias individuales que no se pueden recuperar de ninguna otra manera. Se deben usar en particular para fallas irrecuperables de instancias, por ejemplo, para detectar un interbloqueo en el que se ejecuta un servicio, pero no puede avanzar. Puedes requerir un sondeo en funcionamiento para cada contenedor con las políticas de organización personalizadas.
  • Los sondeos de inicio determinan si el contenedor se inició y está listo para aceptar tráfico.

    • Cuando configuras un sondeo de inicio, las verificaciones de funcionamiento se inhabilitan hasta que el sondeo de inicio determina que el contenedor se inicia para evitar interferencias en el inicio del servicio.
    • Los sondeos de inicio son útiles en especial si usas verificaciones en funcionamiento en contenedores de inicio lento, ya que evita que se cierren prematuramente antes de que los contenedores estén en funcionamiento.

Ten en cuenta que, cuando un servicio experimenta fallas repetidas de sondeo o inicio de funcionamiento, Cloud Run limita los reinicios de las instancias para evitar bucles de fallas no controlados.

El sondeo de inicio de TCP predeterminado

Un sondeo de inicio de TCP se configura de forma automática para un servicio de Cloud Run nuevo con valores predeterminados. El sondeo predeterminado es equivalente a lo siguiente:

startupProbe:
  tcpSocket:
    port: CONTAINER_PORT
  timeoutSeconds: 240
  periodSeconds: 240
  failureThreshold: 1

Reemplaza CONTAINER_PORT por el puerto del contenedorconfigurado para el servicio.

Puedes cambiar estos valores predeterminados según las instrucciones de la sección Configuración de sondeo en esta página.

Facturación y asignación de CPU

  • La CPU se asigna para cada sondeo.
  • Todos los sondeos se facturan por el consumo de CPU y memoria, pero no se aplican cargos basados en solicitudes.

Requisitos y comportamiento del sondeo

Tipo de sondeo Requisitos Comportamiento
Inicio de TCP Ninguno De forma predeterminada, Cloud Run realiza una conexión TCP para abrir el socket TCP en el puerto especificado. Si Cloud Run no puede establecer una conexión, indica un error.

Si un sondeo de inicio no se realiza de forma correcta dentro del tiempo especificado (failureThreshold * periodSeconds), que no puede superar los 240 segundos, el contenedor se cierra. Consulta también Valores predeterminados de TCP.
Inicio de HTTP Crea un extremo de verificación de estado HTTP
Usa HTTP/1
Después de la configuración del sondeo, Cloud Run realiza una solicitud GET de HTTP al extremo de la verificación de estado del servicio (por ejemplo, /ready). Cualquier respuesta entre 200 y 400 es una respuesta correcta, todo lo demás indica error.

Si el resultado del sondeo de inicio no es correcto dentro del tiempo especificado (failureThreshold * periodSeconds), que no puede superar los 240 segundos, el contenedor se cierra.

Si el sondeo de inicio HTTP es correcto dentro del tiempo especificado y configuraste un sondeo de funcionamiento de HTTP, se inicia el sondeo de funcionamiento de HTTP.
Activo de HTTP Crea un extremo de verificación de estado HTTP
Usa HTTP/1
El sondeo de capacidad de respuesta comienza solo después de que el sondeo de inicio se realiza correctamente. Después de que la configuración del sondeo y de cualquier sondeo de inicio se completan correctamente, Cloud Run realiza una solicitud GET de HTTP al extremo de verificación de estado del servicio (por ejemplo, /health). Cualquier respuesta entre 200 y 400 es una respuesta correcta, todo lo demás indica error.

Si el resultado de un sondeo de funcionamiento no es correcto dentro del tiempo especificado (failureThreshold * periodSeconds), el contenedor se cierra con una señal SIGKILL. Las solicitudes restantes que el contenedor aún entregaba se finalizan con el código de estado HTTP 503. Después de cerrar el contenedor, el ajuste de escala automático de Cloud Run inicia una instancia de contenedor nueva.
Inicio de gRPC Implementa el protocolo de verificación de estado de gRPC en tu servicio de Cloud Run. Si un sondeo de inicio no se completa de forma correcta dentro del tiempo especificado (failureThreshold * periodSeconds), que no puede superar los 240 segundos, el contenedor se cierra.
gRPC en funcionamiento Implementa el protocolo de verificación de estado de gRPC en tu servicio de Cloud Run. Si configuras un sondeo de inicio de gRPC, el sondeo de funcionamiento comienza solo después de que el sondeo de inicio se realiza correctamente.

Después de configurar el sondeo de funcionamiento y cualquier sondeo de inicio se realiza correctamente, Cloud Run realiza una solicitud de verificación de estado al servicio.

Si un sondeo de funcionamiento no se completa de forma correcta dentro del tiempo especificado (failureThreshold * periodSeconds), el contenedor se cierra con una señal SIGKILL. Después de cerrar el contenedor, el ajuste de escala automático de Cloud Run inicia una instancia de contenedor nueva.

Configura sondeos

Cualquier cambio en la configuración conlleva la creación de una revisión nueva. Las revisiones posteriores también adoptarán esta configuración de manera automática, a menos que realices actualizaciones explícitas para cambiarla.

Puedes configurar sondeos de HTTP, TCP y gRPC a través de la consola de Google Cloud, YAML o Terraform:

Console

Importante: Si configuras el servicio de Cloud Run para sondeos HTTP, también debes agregar un extremo de verificación de estado HTTP en el código de servicio para responder al sondeo. Si configuras un sondeo de gRPC, también debes implementar el protocolo de verificación de estado de gRPC en tu servicio de Cloud Run.

  1. En la consola de Google Cloud, ve a la página Cloud Run.

    Ir a Cloud Run

  2. Para un servicio nuevo, expande Contenedores, volúmenes, Herramientas de redes y seguridad para mostrar las opciones de verificación de estado. En el servicio existente, haz clic en el servicio que quieras configurar y, luego, en Implementar y editar para ver las opciones de verificación de estado.

  3. En la sección Contenedores, dirígete a Verificaciones de estado y haz clic en Agregar verificación de estado para abrir el panel de configuración Agregar verificación de estado.

  4. En el menú Seleccionar el tipo de verificación de estado, selecciona el tipo de verificación de estado que quieras agregar, por ejemplo, inicio o funcionamiento.

  5. En el menú Seleccionar tipo de sondeo, selecciona el tipo de sondeo que quieras usar, por ejemplo, HTTP o gRPC. Se mostrará el formulario de configuración del sondeo.

  6. Ten en cuenta que la configuración del sondeo varía según el tipo de sondeo. Establece la configuración del sondeo:

    • Si usas sondeos de HTTP, realiza lo siguiente:
      • Asegúrate de que tu servicio use HTTP/1 (el valor predeterminado de Cloud Run), no HTTP/2.
      • Usa el campo Ruta de acceso para especificar la ruta de acceso relativa al extremo, por ejemplo, /.
      • Selecciona la casilla de verificación Encabezados HTTP para especificar encabezados personalizados opcionales. Luego, especifica el nombre del encabezado en el campo Nombre y el valor del encabezado en el campo Valor. Haz clic en Agregar encabezado HTTP para especificar más encabezados.
    • En Puerto, especifica el puerto de contenedor que se usa para el servicio.
    • En Retraso inicial, especifica la cantidad de segundos que se espera después de que el contenedor se inició antes de realizar el primer sondeo. Especifica un valor de 0 a 240 segundos. El valor predeterminado es 0 segundos.
    • En Período, especifica el período (en segundos) en el que se realizará el sondeo. Por ejemplo, 2 para realizar el sondeo cada 2 segundos. Especifica un valor de 1 segundo a 240 segundos. El valor predeterminado es 10 segundos.
    • En Umbral de falla, especifica la cantidad de veces que se debe reintentar el sondeo antes de apagar el contenedor. El valor predeterminado es 3.
    • En Tiempo de espera, especifica la cantidad de segundos que se espera hasta que se agote el tiempo de espera del sondeo. Este valor no puede exceder el valor especificado para periodSeconds. Especifica un valor de 1 a 240. El valor predeterminado es 1.
  7. Haz clic en Agregar para agregar el umbral nuevo.

YAML

Importante: Si configuras el servicio de Cloud Run para sondeos HTTP, también debes agregar un extremo en el código de servicio para responder al sondeo. Si configuras un sondeo de gRPC, también debes implementar el protocolo de verificación de estado de gRPC en tu servicio de Cloud Run.

Inicio de TCP

  1. Si creas un servicio nuevo, omite este paso. Si actualizas un servicio existente, descarga su configuración de YAML:
    gcloud run services describe SERVICE --format export > service.yaml
  2. Configura el atributo startupProbe como se muestra a continuación:

    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

    Reemplazar

    • SERVICE por el nombre del servicio de Cloud Run
    • IMAGE_URL por una referencia a la imagen del contenedor, como us-docker.pkg.dev/cloudrun/container/hello:latest Si usas Artifact Registry, el repositorio REPO_NAME debe estar creado. La URL tiene el formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
    • (OPCIONAL) CONTAINER_PORT se debe configurar como el puerto del contenedor que se usa para el servicio.
    • DELAY con una cantidad de segundos que se espera después de que el contenedor se inició antes de realizar el primer sondeo. Especifica un valor de 0 segundos a 240 segundos. El valor predeterminado es 0 segundos.
    • TIMEOUT (opcional) por la cantidad de segundos que se espera hasta que se agote el tiempo de espera del sondeo. Este valor no puede exceder el valor especificado para periodSeconds. Especifica un valor de 1 a 240. El valor predeterminado es 1.
    • THRESHOLD por la cantidad de veces que se debe reintentar el sondeo antes de cerrar el contenedor. El valor predeterminado es 3.
    • PERIOD por el período (en segundos) en el que se realizará el sondeo. Por ejemplo, 2 para realizar el sondeo cada 2 segundos. Especifica un valor de 1 segundo a 240 segundos. El valor predeterminado es 10 segundos.
  3. Crea o actualiza el servicio con el siguiente comando:
    gcloud run services replace service.yaml

Inicio de HTTP

  1. Si creas un servicio nuevo, omite este paso. Si actualizas un servicio existente, descarga su configuración de YAML:
    gcloud run services describe SERVICE --format export > service.yaml
  2. Asegúrate de que tu servicio use HTTP/1 (el valor predeterminado de Cloud Run), no HTTP/2.

  3. Configura el atributo startupProbe como se muestra a continuación:

    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

    reemplazar

    • SERVICE por el nombre del servicio de Cloud Run
    • IMAGE_URL por una referencia a la imagen del contenedor, como us-docker.pkg.dev/cloudrun/container/hello:latest Si usas Artifact Registry, el repositorio REPO_NAME debe estar creado. La URL tiene el formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
    • PATH por la ruta relativa al extremo HTTP, por ejemplo, /ready.
    • (OPCIONAL) CONTAINER_PORT se debe configurar como el puerto del contenedor que se usa para el servicio.
    • Se puede usar httpHeaders para proporcionar varios encabezados personalizados o repetidos mediante los campos HEADER_NAME y HEADER_VALUE (opcional).
    • DELAY con la cantidad de segundos que se espera después de que el contenedor se inició antes de realizar el primer sondeo (opcional). Especifica un valor de 0 segundos a 240 segundos. El valor predeterminado es 0 segundos.
    • TIMEOUT (opcional) por la cantidad de segundos que se espera hasta que se agote el tiempo de espera del sondeo. Este valor no puede exceder el valor especificado para periodSeconds. Especifica un valor de 1 a 240. El valor predeterminado es 1.
    • THRESHOLD por la cantidad de veces que se debe reintentar el sondeo antes de apagar el contenedor (opcional). El valor predeterminado es 3.
    • PERIOD con el período (en segundos) en el que se realizará el sondeo (OPCIONAL). Por ejemplo, 2 para realizar el sondeo cada 2 segundos. Especifica un valor de 1 a 240 segundos. El valor predeterminado es 10 segundos.
  4. Crea o actualiza el servicio con el siguiente comando:
    gcloud run services replace service.yaml

Activo de HTTP

  1. Si creas un servicio nuevo, omite este paso. Si actualizas un servicio existente, descarga su configuración de YAML:
    gcloud run services describe SERVICE --format export > service.yaml
  2. Asegúrate de que tu servicio use HTTP/1 (el valor predeterminado de Cloud Run), no HTTP/2.

  3. Configura el atributo livenessProbe como se muestra a continuación:

    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

    Reemplazar

    • SERVICE por el nombre del servicio de Cloud Run
    • IMAGE_URL por una referencia a la imagen del contenedor, como us-docker.pkg.dev/cloudrun/container/hello:latest Si usas Artifact Registry, el repositorio REPO_NAME debe estar creado. La URL tiene el formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
    • PATH por la ruta relativa al extremo HTTP, por ejemplo, /ready.
    • (OPCIONAL) CONTAINER_PORT se debe configurar como el puerto del contenedor que se usa para el servicio.
    • Se puede usar httpHeaders para proporcionar varios encabezados personalizados o repetidos mediante los campos HEADER_NAME y HEADER_VALUE (opcional).
    • DELAY con la cantidad de segundos que se espera después de que el contenedor se inició antes de realizar el primer sondeo (opcional). Especifica un valor de 0 segundos a 240 segundos. El valor predeterminado es 0 segundos.
    • TIMEOUT (opcional) por la cantidad de segundos que se espera hasta que se agote el tiempo de espera del sondeo. Este valor no puede exceder el valor especificado para periodSeconds. Especifica un valor de 1 a 3,600. El valor predeterminado es 1.
    • THRESHOLD por la cantidad de veces que se debe reintentar el sondeo antes de apagar el contenedor (opcional). El valor predeterminado es 3.
    • PERIOD con el período (en segundos) en el que se realizará el sondeo (OPCIONAL). Por ejemplo, 2 para realizar el sondeo cada 2 segundos. Especifica un valor de 1 a 3,600 segundos. El valor predeterminado es 10 segundos.
  4. Crea o actualiza el servicio con el siguiente comando:
    gcloud run services replace service.yaml

Inicio de gRPC

  1. Si creas un servicio nuevo, omite este paso. Si actualizas un servicio existente, descarga su configuración de YAML:
    gcloud run services describe SERVICE --format export > service.yaml
  2. Configura el atributo startupProbe como se muestra a continuación:

    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

    Reemplazar

    • SERVICE por el nombre del servicio de Cloud Run
    • IMAGE_URL por una referencia a la imagen del contenedor, como us-docker.pkg.dev/cloudrun/container/hello:latest Si usas Artifact Registry, el repositorio REPO_NAME debe estar creado. La URL tiene el formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
    • (OPCIONAL) GRPC_SERVICE. Si se establece, se usa en el campo de servicio de grpc.health.v1.HealthCheckRequest cuando se llama a la RPC de grpc.health.v1.Health.Check.
    • (OPCIONAL) CONTAINER_PORT se debe configurar como el puerto del contenedor que se usa para el servicio.
    • DELAY con la cantidad de segundos que se espera después de que el contenedor se inició antes de realizar el primer sondeo (opcional). Especifica un valor de 0 a 240 segundos. El valor predeterminado es 0 segundos.
    • TIMEOUT por la cantidad de segundos que se espera hasta que se agote el tiempo de espera del sondeo (opcional). Este valor no puede exceder el valor especificado para periodSeconds. Especifica un valor de 1 a 240. El valor predeterminado es 1.
    • THRESHOLD por la cantidad de veces que se debe reintentar el sondeo antes de apagar el contenedor (opcional). El valor predeterminado es 3.
    • PERIOD con el período (en segundos) en el que se realizará el sondeo (OPCIONAL). Por ejemplo, 2 para realizar el sondeo cada 2 segundos. Especifica un valor de 1 a 240 segundos. El valor predeterminado es 10 segundos.
  3. Crea o actualiza el servicio con el siguiente comando:
    gcloud run services replace service.yaml

gRPC en funcionamiento

  1. Si creas un servicio nuevo, omite este paso. Si actualizas un servicio existente, descarga su configuración de YAML:
    gcloud run services describe SERVICE --format export > service.yaml
  2. Configura el atributo livenessProbe como se muestra a continuación:

    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

    Reemplazar

    • SERVICE por el nombre del servicio de Cloud Run
    • IMAGE_URL por una referencia a la imagen del contenedor, como us-docker.pkg.dev/cloudrun/container/hello:latest Si usas Artifact Registry, el repositorio REPO_NAME debe estar creado. La URL tiene el formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
    • (OPCIONAL) CONTAINER_PORT se debe configurar como el puerto del contenedor que se usa para el servicio.
    • (OPCIONAL) GRPC_SERVICE. Si se establece, se usa en el campo de servicio de grpc.health.v1.HealthCheckRequest cuando se llama a la RPC de grpc.health.v1.Health.Check.
    • DELAY con la cantidad de segundos que se espera después de que el contenedor se inició antes de realizar el primer sondeo (opcional). Especifica un valor de 0 segundos a 240 segundos. El valor predeterminado es 0 segundos.
    • TIMEOUT (opcional) por la cantidad de segundos que se espera hasta que se agote el tiempo de espera del sondeo. Este valor no puede exceder el valor especificado para periodSeconds. Especifica un valor de 1 a 3,600. El valor predeterminado es 1.
    • THRESHOLD por la cantidad de veces que se debe reintentar el sondeo antes de apagar el contenedor (opcional). El valor predeterminado es 3.
    • PERIOD con el período (en segundos) en el que se realizará el sondeo (OPCIONAL). Por ejemplo, 2 para realizar el sondeo cada 2 segundos. Especifica un valor de 1 a 3,600 segundos. El valor predeterminado es 10 segundos.
  3. Crea o actualiza el servicio con el siguiente comando:
    gcloud run services replace service.yaml

Terraform

Importante: Si configuras el servicio de Cloud Run para sondeos HTTP, también debes agregar un extremo en el código de servicio para responder al sondeo. Si configuras un sondeo de gRPC, también debes implementar el protocolo de verificación de estado de gRPC en tu servicio de Cloud Run.

Si deseas obtener más información para aplicar o quitar una configuración de Terraform, consulta los comandos básicos de Terraform.

Inicio de TCP

Configura el servicio de Cloud Run con el atributo startup_probe como se muestra a continuación:

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
        }
      }
    }
  }
}

Inicio de HTTP

Asegúrate de que tu servicio use HTTP/1 (el valor predeterminado de Cloud Run), no HTTP/2.

Configura el servicio de Cloud Run con el atributo startup_probe como se muestra a continuación:

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 = "*"
          }
        }
      }
    }
  }
}

Activo de HTTP

Asegúrate de que tu servicio use HTTP/1 (el valor predeterminado de Cloud Run), no HTTP/2.

Configura el servicio de Cloud Run con el atributo liveness_probe como se muestra a continuación:

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 = "*"
          }
        }
      }
    }
  }
}

Inicio de gRPC

Configura el servicio de Cloud Run con el atributo startup_probe como se muestra a continuación:

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 en funcionamiento

Configura el servicio de Cloud Run con el atributo liveness_probe como se muestra a continuación:

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"
        }
      }
    }
  }
}

Crea extremos de verificación de estado de HTTP

Si configuras el servicio de Cloud Run para un sondeo de inicio o de funcionamiento de HTTP, debes agregar un extremo en el código de servicio para responder al sondeo. El extremo puede tener el nombre que desees, por ejemplo, /startup o /ready, pero deben coincidir con los valores que especifiques para path en la configuración del sondeo. Por ejemplo, si especificas /ready para un sondeo de inicio HTTP, debes especificar path en la configuración de sondeo, como se muestra a continuación:

startupProbe:
  httpGet:
    path: /ready

Los extremos de la verificación de estado de HTTP son accesibles de forma externa y siguen los mismos principios que cualquier otro extremo de servicio HTTP que se exponga de forma externa.