Usa verificaciones de estado.

Google Cloud proporciona mecanismos de verificación de estado que determinan si las instancias de backend responden al tráfico de manera correcta. En este documento, se describe cómo crear y usar las verificaciones de estado para los balanceadores de cargas y Cloud Service Mesh.

En esta página, se supone que estás familiarizado con los siguientes conceptos:

Crear verificaciones de estado

Google Cloud te permite crear o seleccionar una verificación de estado cuando completas la configuración de backend del balanceador de cargas en la consola de Google Cloud.

También puedes crear una verificación de estado sin importar la configuración del balanceador de cargas en la consola de Google Cloud. Esto es útil si necesitas crear la verificación de estado primero o usar una para varios balanceadores de cargas. Puedes crear una verificación de estado con la consola de Google Cloud, la CLI de Google Cloud o las API de REST.

Console

Ve a la página Verificaciones de estado en la consola de Google Cloud.
Ir a la página Verificaciones de estado
Haz clic en Crear una verificación de estado.
En la página Crea una verificación de estado, proporciona la siguiente información:
- Nombre: Proporciona un nombre para la verificación de estado.
- Descripción: De manera opcional, puedes proporcionar una descripción.
- Alcance: Selecciona un alcance, Global o Regional, según el tipo de balanceador de cargas.
  - Si seleccionaste Regional, elige una Región en el menú desplegable.
- Protocolo: Elige un protocolo de verificación de estado.
- Puerto: Proporciona un número de puerto. Cuando creas una verificación de estado en la consola de Google Cloud, debes especificar el puerto mediante un número de puerto.
- Protocolo de proxy: De manera opcional, puedes agregar un encabezado de proxy a las solicitudes que realizan los sistemas de sondeo de verificación de estado.
- Solicitar ruta y respuesta: para los protocolos HTTP, HTTPS y HTTP2, de manera opcional, puedes proporcionar una ruta de URL a fin de que los sistemas de sondeo de verificación de estado se pongan en contacto. A fin de obtener más información, consulta Marcas adicionales para verificaciones de estado de HTTP, HTTPS y HTTP/2.
- Solicitud y Respuesta: En los protocolos TCP y SSL, puedes especificar una string de texto ASCII para enviar una string de respuesta de texto esperada. A fin de obtener más información, consulta Marcas adicionales para verificaciones de estado de SSL y TCP.
- Intervalo de verificación: Define la cantidad de tiempo desde el inicio de un sondeo hasta el inicio del siguiente.
- Tiempo de espera: Define la cantidad de tiempo que Google Cloud espera una respuesta a un sondeo. Su valor debe ser menor o igual que el intervalo de verificación.
- Umbral de buen estado: Define la cantidad de sondeos secuenciales que se deben realizar de forma correcta para que la instancia de VM se considere en buen estado.
- Umbral de mal estado: Define la cantidad de sondeos secuenciales que deben fallar para que la instancia de VM se considere en mal estado.
Haz clic en Crear.

gcloud

Para crear una verificación de estado global, usa el comando compute health-checks create adecuado:

gcloud compute health-checks create PROTOCOL NAME \
    --global \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

Para crear una verificación de estado regional, usa el comando compute health-checks create adecuado:

gcloud compute health-checks create PROTOCOL NAME \
    --region=REGION \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

Reemplaza lo siguiente:

PROTOCOL define el protocolo que se usa para la verificación de estado. Las opciones válidas son grpc, http, https, http2, ssl y tcp.
NAME es el nombre de la verificación de estado. Dentro de un proyecto determinado, cada verificación de estado global debe tener un nombre único, y las verificaciones de estado regionales deben tener nombres únicos dentro de una región determinada.
REGION: Es la región de la verificación de estado. En el caso de los balanceadores de cargas regionales, la región de la verificación de estado debe coincidir con la región del servicio de backend.
DESCRIPTION es una descripción opcional.
CHECK_INTERVAL es la cantidad de tiempo desde el inicio de la conexión de un sistema de sondeo de verificación de estado hasta el inicio de la siguiente. Las unidades son segundos. Si se omite, Google Cloud usa un valor de 5s (5 segundos).
TIMEOUT es la cantidad de tiempo que Google Cloud espera una respuesta a un sondeo. El valor de TIMEOUT debe ser menor o igual que CHECK_INTERVAL. Las unidades son segundos. Si se omite, Google Cloud usa un valor de 5s (5 segundos).
HEALTHY_THRESHOLD y UNHEALTHY_THRESHOLD especifican la cantidad de sondeos secuenciales que deben tener éxito o fallar para que la instancia de VM se considere en buen o mal estado. Si se omite alguno, Google Cloud usa un límite predeterminado de 2.
PORT_SPECIFICATION define la especificación de puerto mediante una de las marcas de especificación de puerto.
ADDITIONAL_FLAGS son otras marcas para especificar puertos y opciones específicas de PROTOCOL. Consulta Marcas adicionales para las verificaciones de estado HTTP, HTTPS y HTTP/2, Marcas adicionales para las verificaciones de estado de SSL y TCP o Marca adicional para las verificaciones de estado de gRPC.

Terraform

Para crear una verificación de estado global, usa el recurso google_compute_health_check.

resource "google_compute_health_check" "health_check_tcp_with_logging" {
  provider = google-beta

  name = "health-check-tcp"

  timeout_sec        = 1
  check_interval_sec = 1

  tcp_health_check {
    port = "22"
  }

  log_config {
    enable = true
  }
}

Para crear una verificación de estado regional, usa el recurso google_compute_region_health_check.

resource "google_compute_region_health_check" "default" {
  name               = "tcp-health-check-region-west"
  timeout_sec        = 5
  check_interval_sec = 5
  tcp_health_check {
    port = "80"
  }
  region = "us-west1"
}

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

API

Para crear una verificación de estado global, usa healthChecks.insert.
Para crear una verificación de estado regional, usa regionHealthChecks.insert.

Modifica las verificaciones de estado

No se puede convertir una verificación de estado en una verificación de estado heredada (o viceversa) mediante la modificación de la verificación de estado. Tampoco puedes cambiar el nombre o el alcance de una verificación de estado (por ejemplo, de global a regional).

Console

Ve a la página Verificaciones de estado en la consola de Google Cloud.
Ir a la página Verificaciones de estado
Haz clic en una verificación de estado para ver los detalles.
Si necesitas modificar la verificación de estado, haz clic en Editar y, luego, haz lo siguiente:
- Realiza cambios en los parámetros según sea necesario.
- Haz clic en Guardar.

gcloud

Identifica el nombre y el alcance de la verificación de estado. Para obtener instrucciones, consulta Enumera verificaciones de estado.
Excepto por el nombre, el protocolo y el alcance de una verificación de estado, puedes modificar cualquiera de las marcas comunes, las marcas de especificación de puerto y las marcas opcionales. Para modificar una verificación de estado existente, usa el comando compute health-checks update adecuado. Para las marcas que omites, se conservan los parámetros de configuración que se establecieron de forma previa.
- Ejemplo de modificación de una verificación de estado global: Con el siguiente comando, se modifica una verificación de estado de HTTP global llamada hc-http-port-80 mediante el cambio del intervalo de verificación, el tiempo de espera y la ruta de solicitud.
```
gcloud compute health-checks update http hc-http-port-80 \
    --global \
    --check-interval=20s \
    --timeout=15s \
    --request-path="/health"
```
- Ejemplo de modificación de una verificación de estado regional: Con el siguiente comando, se modifica una verificación de estado de TCP regional en us-west1 llamada hc-west1-tcp-ldap mediante el cambio de la especificación de puerto.
```
gcloud compute health-checks update tcp hc-west1-tcp-ldap \
    --region=us-west1 \
    --port=631
```

API

Identifica el nombre y el alcance de la verificación de estado. Consulta Enumera verificaciones de estado para obtener instrucciones.
Excepto por el nombre, el protocolo y el alcance de una verificación de estado, puedes modificar cualquiera de las marcas comunes, las marcas de especificación de puerto y las marcas opcionales con estas llamadas a la API. Usa las llamadas a la API de patch para conservar la configuración ya establecida que no se determina de forma explícita en la solicitud.
- Para modificar una verificación de estado global, usa healthChecks.update o healthChecks.patch.
- Para modificar una verificación de estado regional, usa regionHealthChecks.update o regionHealthChecks.patch.

Mostrar lista de verificaciones de estado

Console

Ve a la página Verificaciones de estado en la consola de Google Cloud.
Ir a la página Verificaciones de estado
Haz clic en una verificación de estado para ver los detalles.

gcloud

Para enumerar las verificaciones de estado, usa el comando compute health-checks list:

Para enumerar las verificaciones de estado globales, haz lo siguiente:
```
gcloud compute health-checks list \
    --global
```
Para enumerar las verificaciones de estado regionales, reemplaza REGION_LIST por una lista delimitada por comas de las regiones de Google Cloud a consultar.
```
gcloud compute health-checks list \
    --regions=REGION_LIST
```

Una vez que sepas el nombre y el alcance de una verificación de estado, usa el comando compute health-checks describe para ver la configuración actual.

Para describir una verificación de estado global, reemplaza NAME por su nombre.
```
gcloud compute health-checks describe NAME \
    --global
```
Para describir una verificación de estado regional, reemplaza NAME por su nombre y REGION por la región en la que se encuentra.
```
gcloud compute health-checks describe NAME \
    --region=REGION
```

API

Para enumerar las verificaciones de estado, usa estas llamadas a la API:

Para enumerar las verificaciones de estado globales, usa healthChecks.list.
Para enumerar las verificaciones de estado regionales, usa regionHealthChecks.list.

Para describir la configuración actual de una verificación de estado, usa lo siguiente:

Para describir una verificación de estado global, usa healthChecks.get.
Para describir una verificación de estado regional, usa regionHealthChecks.get.

Marcas adicionales

En esta sección, se describen marcas adicionales que puedes usar cuando creas o modificas una verificación de estado. Algunas marcas, como la especificación de puerto, deben configurarse mediante gcloud o la API.

Marcas de especificación de puerto

Si creas una verificación de estado mediante Google Cloud CLI o la API, tienes dos opciones para especificar el puerto de la verificación de estado. En la tabla siguiente, se muestran las opciones de especificación de puerto para combinaciones válidas de balanceadores de cargas y backend. El término grupo de instancias se refiere a grupos de instancias no administrados, administrados zonales o administrados regionales.

Cada verificación de estado solo puede usar un tipo de especificación de puerto.

Producto	Tipo de backend	Opciones de especificación de puerto
Balanceador de cargas de red de transferencia externo	Grupos de instancias y NEGs compatibles	`--port`: Especifica un puerto TCP por número, del `1` al `65535`. La marca `--use-serving-port` se ignora para una verificación de estado asociada con un balanceador de cargas de red de transferencia interno porque los servicios de backend de este balanceador de cargas no se suscriben a ningún puerto con nombre. Esto se debe a que son balanceadores de cargas de transferencia que entregan paquetes directamente a los backends en lugar de crear conexiones nuevas desde el balanceador de cargas al backend.
Balanceador de cargas de red de transferencia externo	Grupos de destino	Las verificaciones de estado heredadas solo admiten la especificación del número de puerto (`--port`).
Balanceador de cargas de red de transferencia interno	Grupos de instancias y NEGs compatibles	`--port`: Especifica un puerto TCP por número, del `1` al `65535`. La marca `--use-serving-port` se ignora para una verificación de estado asociada con un balanceador de cargas de red de transferencia interno porque los servicios de backend de este balanceador de cargas no se suscriben a ningún puerto con nombre. Esto se debe a que son balanceadores de cargas de transferencia que entregan paquetes directamente a los backends en lugar de crear conexiones nuevas desde el balanceador de cargas al backend.
Balanceador de cargas de aplicaciones externo global Balanceador de cargas de aplicaciones clásico Balanceador de cargas de aplicaciones externo regional Balanceador de cargas de aplicaciones interno entre regiones Balanceador de cargas de aplicaciones interno regional Balanceador de cargas de red de proxy externo global Balanceador de cargas de red de proxy clásico Balanceador de cargas de red de proxy externo regional Balanceador de cargas de red de proxy interno entre regiones Balanceador de cargas de red de proxy interno regional Cloud Service Mesh	NEG compatibles	`--port`: Especifica un puerto TCP por número, del `1` al `65535`. `--use-serving-port`: Usa el puerto de cada extremo en el grupo de extremos de red.
	Grupos de instancias	`--port`: Especifica un puerto TCP por número, del `1` al `65535`. `--use-serving-port`: Usa el puerto con nombre del mismo grupo de instancias al que se suscribe el servicio de backend.

Si omites la especificación de puerto mientras creas la verificación de estado, Google Cloud usa los siguientes valores predeterminados:

Si el protocolo de verificación de estado es TCP o HTTP, usa --port=80.
Si el protocolo de verificación de estado es SSL, HTTPS o HTTP2, usa --port=443.
Si el protocolo de verificación de estado es GRPC, no hay un valor predeterminado implícito, por lo que debes incluir la especificación del puerto.

Marcas adicionales para las verificaciones de estado de HTTP, HTTPS y HTTP/2

Además de las marcas comunes y la especificación de puerto, puedes usar las siguientes marcas opcionales para las verificaciones de estado de HTTP, HTTPS y HTTP/2. En este ejemplo, se crea una verificación de estado de HTTP llamada hc-http-port-80 que usa el puerto 80 con los criterios predeterminados de intervalo, tiempo de espera y umbral de estado.

gcloud compute health-checks create HTTP_PROTOCOL hc-http-port-80 \
    COMMON_FLAGS \
    PORT_SPECIFICATION \
    --host=HOST \
    --proxy-header=PROXY_HEADER \
    --request-path=REQUEST_PATH \
    --response=RESPONSE

HTTP_PROTOCOL puede ser http (HTTP/1.1 sin TLS), https (HTTP/1.1 con TLS) o http2 (HTTP/2 con TLS).
COMMON_FLAGS define las marcas comunes. Consulta Procedimiento de creación.
PORT_SPECIFICATION define la especificación de puerto mediante una de las marcas de especificación de puerto.
HOST te permite proporcionar un encabezado HTTP Host. Si se omite, se usa la dirección IP de la regla de reenvío del balanceador de cargas.
PROXY_HEADER debe ser NONE o PROXY_V1. Si se omite, Google Cloud usa NONE. El valor de PROXY_V1 agrega el encabezado PROXY UNKNOWN\r\n.
REQUEST_PATH especifica la ruta de URL que usa Google Cloud cuando envía solicitudes de verificación de estado. Si se omite este paso, la solicitud de verificación de estado se envía a /.
RESPONSE define una respuesta esperada opcional. Las strings de respuesta deben seguir estas reglas:
- La string de respuesta debe constar de letras, números y espacios ASCII.
- La string de respuesta puede tener hasta 1,024 caracteres.
- La coincidencia con comodines no es compatible.
- La verificación basada en el contenido no admite la inversión; por ejemplo, los operadores como ! en HAProxy no están admitidos.

Si Google Cloud encuentra la string de respuesta esperada en cualquier lugar en los primeros 1,024 bytes del cuerpo de respuesta recibido, y el estado HTTP es 200 (OK), el sondeo se considera correcto.

Las marcas --request-path y --response modifican los criterios de éxito para el sondeo de verificación de estado.

Marcas adicionales para las verificaciones de estado de SSL y TCP

Además de las marcas comunes y la especificación de puerto, puedes usar las siguientes marcas opcionales para las verificaciones de estado de SSL y TCP. En este ejemplo, se crea una verificación de estado de TCP llamada hc-tcp-3268 mediante el puerto 3268 con los criterios predeterminados de intervalo, tiempo de espera y límite de estado.

gcloud compute health-checks create tcp hc-tcp-3268 \
    COMMON_FLAGS \
    PORT_SPECIFICATION \
    --proxy-header=PROXY_HEADER \
    --request=REQUEST_STRING \
    --response=RESPONSE_STRING

El protocolo puede ser tcp (en este ejemplo) o ssl.
COMMON_FLAGS define las marcas comunes. Consulta Procedimiento de creación.
PORT_SPECIFICATION define la especificación de puerto mediante una de las marcas de especificación de puerto.
PROXY_HEADER debe ser NONE o PROXY_V1. Si se omite, Google Cloud usa NONE. El valor de PROXY_V1 agrega el encabezado PROXY UNKNOWN\r\n.
REQUEST_STRING: Puedes proporcionar una string de hasta 1,024 caracteres ASCII para enviar una vez que se haya establecido la sesión TCP o SSL.
RESPONSE_STRING: Puedes proporcionar una string de hasta 1,024 caracteres ASCII para la respuesta esperada.

Las marcas --request y --response modifican los criterios de éxito para el sondeo de verificación de estado. Si usas la marca --response, ya sea sola o junto con la marca --request, la respuesta que se muestra debe coincidir de manera exacta con la string de respuesta esperada.

Marca adicional para las verificaciones de estado de gRPC

Tu servidor gRPC de backend debe implementar el servicio de estado de gRPC como se describe en el protocolo de verificación de estado de gRPC. Google Cloud envía un mensaje de HealthCheckRequest a los backends mediante una llamada al método Check del servicio de estado en tu backend. El parámetro de servicio en la solicitud se establece en una string vacía, a menos que se especifique un nombre de servicio de gRPC.

Una verificación de estado de gRPC puede verificar el estado de un servicio de gRPC. Puedes incluir una string de hasta 1,024 caracteres ASCII, que es el nombre de un servicio de gRPC en particular que se ejecuta en un NEG o una VM de backend. Para hacerlo, usa la siguiente marca opcional en las verificaciones de estado de gRPC:

--grpc-service-name=GRPC_SERVICE_NAME

Por ejemplo, es posible que tengas los siguientes servicios y estados que el servidor de backend registra con el servicio de estado de gRPC del backend.

MyPackage.ServiceA con el estado de entrega SERVING
MyPackage.ServiceB con el estado de entrega NOT_SERVING
El nombre del servicio vacío con el estado de entrega NOT_SERVING

Si creas una verificación de estado en MyPackage.ServiceA, como se muestra a continuación, el sondeo de verificación de estado muestra HEALTHY porque el estado del servicio es SERVING.

gcloud beta compute health-checks create grpc MyGrpcHealthCheckServiceA \
    --grpc-service-name=MyPackage.ServiceA

Si creas una verificación de estado en MyPackage.ServiceB, el sondeo de verificación de estado muestra UNHEALTHY porque el estado del servicio es NOT_SERVING.

Si creas una verificación de estado en MyPackage.ServiceC, que no está registrado con el servicio de estado de gRPC, el sondeo de verificación de estado muestra el estado de gRPC NOT_FOUND, que es equivalente a UNHEALTHY.

Si creas una verificación de estado en el nombre del servicio vacío, el sondeo de verificación de estado muestra el estado UNHEALTHY porque el nombre del servicio vacío se registra con el estado NOT_SERVING.

Verificaciones de estado heredadas

En esta sección, se describe cómo crear, modificar y enumerar verificaciones de estado de HTTP y HTTPS heredadas. No puedes convertir una verificación de estado heredada en una verificación de estado ni viceversa.

Para obtener información sobre qué tipos de balanceadores de cargas admiten verificaciones de estado heredadas, consulta la Guía de balanceadores de cargas.

Crea verificaciones de estado heredadas

Console

Aunque la página de verificaciones de estado de la consola de Google Cloud te permite editar las verificaciones de estado y las verificaciones de estado heredadas, no puedes create una verificación de estado heredada nueva desde esa página.

Puedes crear una verificación de estado heredada en la consola de Google Cloud solo mientras creas un balanceador de cargas de red de transferencia externo basado en grupos de destino. Para crear la verificación de estado heredada sola, usa las instrucciones de la gcloud o de la API de esta sección.

gcloud

Para crear una verificación de estado heredada, usa el comando compute http-health-checks create:

gcloud compute LEGACY_CHECK_TYPE create NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --host=HOST \
    --port=PORT \
    --request-path=REQUEST_PATH

Reemplaza lo siguiente:

LEGACY_CHECK_TYPE es http-health-checks para una verificación de estado de HTTP heredada o https-health-checks para una verificación de estado de HTTPS heredada. Si creas una verificación de estado heredada para un balanceador de cargas de red de transferencia externo basado en grupos de destino, debes usar http-health-checks.
NAME es el nombre de la verificación de estado heredada. Dentro de un proyecto determinado, cada verificación de estado heredada debe tener un nombre único.
DESCRIPTION es una descripción opcional.
CHECK_INTERVAL es la cantidad de tiempo desde el inicio de un sondeo hasta el inicio del siguiente. Las unidades son segundos. Si se omite, Google Cloud usa un valor de 5s (5 segundos).
TIMEOUT es la cantidad de tiempo que Google Cloud esperará una respuesta a un sondeo. El valor de TIMEOUT debe ser menor o igual que CHECK_INTERVAL. Las unidades son segundos. Si se omite, Google Cloud usa un valor de 5s (5 segundos).
HEALTHY_THRESHOLD y UNHEALTHY_THRESHOLD especifican la cantidad de sondeos secuenciales que deben tener éxito o fallar para que una instancia de VM se considere en buen o mal estado. Si se omite alguno, Google Cloud usa un límite predeterminado de 2.
HOST te permite proporcionar un encabezado HTTP de host. Si se omite, se usa la dirección IP de la regla de reenvío del balanceador de cargas.
PORT te permite proporcionar un número de puerto. Si se omite, Google Cloud usa 80.
REQUEST_PATH especifica la ruta de URL que usa Google Cloud cuando envía solicitudes de verificación de estado. Si se omite este paso, la solicitud de verificación de estado se envía a /.

API

Para crear una verificación de estado de HTTP heredada, usa la llamada a la API httpHealthChecks.insert.
Para crear una verificación de estado de HTTPS heredada, usa httpsHealthChecks.insert.

Terraform

Para crear un recurso de verificación de estado de HTTP heredada, usa el recurso google_compute_http_health_check.
Para crear un recurso de verificación de estado de HTTPS heredada, usa el recurso google_compute_https_health_check.

Modifica las verificaciones de estado heredadas

Console

Ve a la página Verificaciones de estado en la consola de Google Cloud.
Ir a la página Verificaciones de estado
Haz clic en una verificación de estado para ver los detalles.
Haz clic en Editar , realiza los cambios y, luego, haz clic en Guardar.

gcloud

Para modificar una verificación de estado de HTTP heredada, usa el comando compute http-health-checks update y reemplaza NAME por su nombre. Cuando se modifica una verificación de estado heredada con gcloud, se conserva la configuración ya establecida para las marcas que omites. Las OTHER_OPTIONS son las opciones que se describen en Crea una verificación de estado heredada.
```
gcloud compute http-health-checks update NAME \
  OTHER_OPTIONS
```
Para modificar una verificación de estado de HTTPS heredada, usa el comando compute https-health-checks update y reemplaza NAME por su nombre. Cuando se modifica una verificación de estado heredada con gcloud, se conserva la configuración ya establecida para las marcas que omites. Las OTHER_OPTIONS son las opciones que se describen en Crea una verificación de estado heredada.
```
gcloud compute https-health-checks update NAME \
  OTHER_OPTIONS
```

API

Puedes modificar cualquiera de las marcas usadas para crear una verificación de estado heredada, a excepción del nombre y del tipo. Las llamadas a la API patch conservan cualquier configuración ya establecida que no se determine de forma explícita en la solicitud de parche.

Para modificar una verificación de estado de HTTP heredada, usa httpHealthChecks.update o httpHealthChecks.patch.
Para modificar una verificación de estado de HTTPS heredada, usa httpsHealthChecks.update o httpsHealthChecks.patch.

Enumera las verificaciones de estado heredadas

Console

Ve a la página Verificaciones de estado en la consola de Google Cloud.
Ir a la página Verificaciones de estado
Haz clic en una verificación de estado heredada para ver los detalles.

gcloud

Para enumerar las verificaciones de estado de HTTP heredadas, usa el comando compute http-health-checks list.
```
gcloud compute http-health-checks list
```
Para enumerar las verificaciones de estado de HTTPS heredadas, usa el comando compute https-health-checks list.
```
gcloud compute https-health-checks list
```
Para describir una verificación de estado de HTTP heredada, usa el comando compute http-health-checks describe y reemplaza NAME por su nombre.
```
gcloud compute http-health-checks describe NAME
```
Para describir una verificación de estado de HTTPS heredada, usa el comando compute https-health-checks describe y reemplaza NAME por su nombre.
```
gcloud compute https-health-checks describe NAME
```

API

Para enumerar las verificaciones de estado heredadas, haz lo siguiente:
- Usa httpHealthChecks.list para enumerar las verificaciones de estado de HTTP heredadas.
- Usa httpsHealthChecks.list para enumerar las verificaciones de estado de HTTPS heredadas.
Para describir una verificación de estado heredada, haz lo siguiente:
- Usa httpHealthChecks.get para describir la verificación de estado de HTTP heredada.
- Usa httpsHealthChecks.get para describir la verificación de estado de HTTPS heredada.

Crea las reglas de firewall necesarias

Debes crear reglas de firewall de entrada aplicables a todas las VMs cuyas cargas se balancean para permitir el tráfico de los rangos de IP de verificación de estado. En el siguiente ejemplo, se crea una regla de firewall aplicable a las instancias de VM identificadas por una etiqueta de destino específica.

En este ejemplo, se permite que todo el tráfico de TCP de los sistemas de verificación de estado de Google Cloud se aplique a las instancias de VM (el tráfico de TCP incluye tráfico SSL, HTTP, HTTPS y HTTP/2). Si lo prefieres, puedes especificar puertos junto con el protocolo TCP. Sin embargo, si especificas puertos, las reglas de firewall pueden volverse específicas para una verificación de estado en particular. Si usas tcp:80 para el protocolo y el puerto, esto permite el tráfico de TCP en el puerto 80, por lo que Google Cloud podría comunicarse con las VMs mediante HTTP en el puerto 80, pero no podría comunicarse con ellas mediante HTTPS en el puerto 443.

Console

En la consola de Google Cloud, ve a la página Firewall.
Ir a Políticas de firewall
Haz clic en Crear regla de firewall.
En la página Crear una regla de firewall, proporciona la información siguiente:
- Nombre: Proporciona un nombre para la regla. Para este ejemplo, usa fw-allow-health-checks.
- Red: Elige una red de VPC.
- Prioridad: ingresa un número para la prioridad. Los números más bajos tienen prioridades más altas. Asegúrate de que la regla de firewall tenga una prioridad mayor que otras normas que podrían denegar el tráfico de entrada.
- Dirección del tráfico: elige ingreso.
- Acción en caso de coincidencia: elige Permitir.
- Destinos: Elige Etiquetas de destino especificadas y, luego, ingresa etiquetas en el campo Etiquetas de destino. Para este ejemplo, usa allow-health-checks.
- Filtro de fuente: elige Rangos de IP.
- Rangos de IP de origen: Ingresa el rango de IP de origen según el tipo de balanceador de cargas, el tipo de tráfico y el tipo de verificación de estado. Consulta Rangos de IP del sondeo y reglas de firewall.
- Protocolos y puertos permitidos: Usa tcp y el puerto configurado en tu verificación de estado. TCP es el protocolo subyacente para todos los protocolos de verificación de estado.
- Haz clic en Crear.
En cada instancia cuyas cargas se balancean, debes agregar la etiqueta de red para que se aplique esta regla de firewall de entrada nueva. En este ejemplo, se usa allow-health-checks para la etiqueta de red.

gcloud

Usa el siguiente comando gcloud para crear una regla de firewall llamada fw-allow-health-checks que permite las conexiones TCP entrantes, de sistemas de verificación de estado de Google Cloud, a instancias en la red de VPC con la etiqueta allow-health-checks. Según el tipo de balanceador de cargas, se admite un conjunto diferente de rangos de IP de sondeo y reglas de firewall para el tráfico IPv6 a los backends.

Reemplaza NETWORK_NAME por el nombre de la red de VPC y PORT por los puertos que usa el balanceador de cargas.
```
gcloud compute firewall-rules create fw-allow-health-checks \
    --network=NETWORK_NAME \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=SOURCE_IP_RANGE \
    --target-tags=allow-health-checks \
    --rules=tcp:PORT
```
El valor de SOURCE_IP_RANGE depende de tu balanceador de cargas, tipo de tráfico y verificación de estado. Consulta Rangos de IP del sondeo y reglas de firewall.
En cada instancia cuyas cargas se balancean, debes agregar la etiqueta de red para que se aplique esta regla de firewall de entrada nueva. En este ejemplo, se usa allow-health-checks para la etiqueta de red.

Consulta la documentación de las reglas de firewall de gcloud y la documentación de la API para obtener más detalles.

Documentación relacionada:

A fin de obtener más información sobre cómo especificar objetivos para las reglas de firewall, consulta la explicación de los objetivos en la Descripción general de las reglas de firewall y Configura las etiquetas de red.
Para obtener más información sobre todas las reglas de firewall que requieren los balanceadores de cargas, consulta Reglas de firewall.

Asocia verificaciones de estado con balanceadores de cargas

Si aún no lo hiciste, revisa la Descripción general de las verificaciones de estado: Selecciona una verificación de estado.

Para asociar una verificación de estado a un balanceador de cargas nuevo, consulta la guía de configuración del balanceador de cargas correspondiente. En esta sección, se describe cómo asociar una verificación de estado con un servicio de backend del balanceador de cargas existente.

En esta sección, se da por sentado que hiciste esto:

Creaste un balanceador de cargas.
Creaste una verificación de estado.
Creaste la regla de firewall necesaria.

Console

Haz esto para asociar una verificación de estado a un balanceador de cargas existente:

Ve a la página Balanceo de cargas en la consola de Google Cloud.
Ir a la página Balanceo de cargas
Haz clic en un balanceador de cargas para ver sus detalles.
Haz clic en Editar y, luego, en Configuración de backend.
Elige una verificación de estado en el menú Verificación de estado.
Haz clic en Actualizar.

gcloud

Para asociar una verificación de estado con un servicio de backend existente, sigue estos pasos.

Identifica el nombre y el alcance del servicio de backend. Los balanceadores de cargas de red de transferencia y los balanceadores de cargas de red de proxy solo tienen un servicio de backend por balanceador de cargas. Los balanceadores de cargas de aplicaciones tienen uno o más servicios de backend asociados a un solo mapa de URL.
- Para enumerar los servicios de backend para los balanceadores de cargas de red de transferencia internos, ejecuta el siguiente comando.
```
gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=INTERNAL"
```
- Para enumerar los servicios de backend de los balanceadores de cargas de red de transferencia externos, ejecuta el siguiente comando.
```
gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=EXTERNAL"
```
- Para enumerar los servicios de backend de los balanceadores de cargas de red del proxy externos globales, ejecuta el siguiente comando.
```
gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=EXTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"
```
- Para enumerar los servicios de backend de los balanceadores de cargas de red de proxy clásicos, ejecuta el siguiente comando.
```
gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=EXTERNAL" \
    --filter="protocol=(SSL,TCP)"
```
- Para enumerar los servicios de backend de los balanceadores de cargas de red de proxy internos entre regiones, ejecuta el siguiente comando.
```
gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=INTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"
```
- Para enumerar los servicios de backend para los balanceadores de cargas de red de proxy externos regionales, ejecuta el siguiente comando.
```
gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=EXTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"
```
- Para enumerar los servicios de backend para los balanceadores de cargas de red de proxy internos regionales, ejecuta el siguiente comando.
```
gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=INTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"
```
- Para identificar los servicios de backend para balanceadores de cargas de aplicaciones externos globales, balanceadores de cargas de aplicaciones clásicos y balanceadores de cargas de aplicaciones internos entre regiones, primero identifica un mapa de URL y, luego, describe el mapa. Los mapas de URL y los servicios de backend para estos balanceadores de cargas son siempre globales, sin importar el nivel de servicio de red. Reemplaza URL_MAP_NAME por el nombre del mapa de URL. Los servicios de backend que usa el balanceador de cargas se enumeran en la respuesta.
```
gcloud compute url-maps list \
    --global
```
```
gcloud compute url-maps describe URL_MAP_NAME \
    --global
```
- Para identificar los servicios de backend para un balanceador de cargas de aplicaciones externo regional o uno interno regional, primero identifica un mapa de URL y, luego, describe el mapa. Los mapas de URL y los servicios de backend para estos balanceadores de cargas son regionales. Reemplaza REGION_LIST por una lista delimitada por comas de las regiones de Google Cloud que consultarás. Reemplaza URL_MAP_NAME por el nombre del mapa de URL y REGION por su región. Los servicios de backend que usa el balanceador de cargas se enumeran en la respuesta.
```
gcloud compute url-maps list \
    --regions=REGION_LIST
```
```
gcloud compute url-maps describe URL_MAP_NAME \
    --region=REGION
```
Identifica una verificación de estado. Consulta Enumera las verificaciones de estado.
Asocia una verificación de estado con el servicio de backend mediante el comando compute backend-services update. Cada servicio de backend debe hacer referencia a una sola verificación de estado. En los siguientes comandos, reemplaza BACKEND_SERVICE_NAME por el nombre del servicio de backend, HEALTH_CHECK_NAME por el nombre de la verificación de estado y, si es necesario, REGION por la región de Google Cloud del servicio de backend, la verificación de estado o ambos.
- Para cambiar la verificación de estado de un balanceador de cargas de red de transferencia interno: un servicio de backend del balanceador de cargas de red de transferencia interno es regional. Puede hacer referencia a una verificación de estado global o regional. En el siguiente ejemplo, se muestra una referencia de verificación de estado regional. Si usas una verificación de estado global con el balanceador de cargas de red de transferencia interno, usa --global-health-checks en lugar de --health-checks-region.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```
- Para cambiar la verificación de estado de un balanceador de cargas de red de transferencia externo basado en servicios de backend, el servicio de backend de un balanceador de cargas de red de transferencia externo es regional. Puede hacer referencia a una verificación de estado regional.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```
- Cambia la verificación de estado de un balanceador de cargas de red del proxy externo global, de un balanceador de cargas de red del proxy clásico, de un balanceador de cargas de aplicaciones externo global, de un balanceador de cargas de aplicaciones clásico o un balanceador de cargas de aplicaciones interno entre regiones: tanto el servicio de backend como la verificación de estado son globales para estos balanceadores de cargas. Los balanceadores de cargas de aplicaciones pueden hacer referencia a más de una verificación de estado si hacen referencia a más de un servicio de backend.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --global \
    --health-checks HEALTH_CHECK_NAME \
    --global-health-checks
```
- Cambia la verificación de estado de un balanceador de cargas de aplicaciones externo regional, de balanceador de cargas de red del proxy externo regional, de un balanceador de cargas de red del proxy interno regional o de un balanceador de cargas de aplicaciones interno regional: el servicio de backend y la verificación de estado son regionales. Algunos balanceadores de cargas pueden hacer referencia a más de una verificación de estado si pueden hacer referencia a más de un servicio de backend.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```

API

Puedes enumerar servicios de backend con la llamada a la API backendServices.list.
Consulta las verificaciones de estado.
Para asociar una verificación de estado a un servicio de backend, usa una de estas llamadas a la API:
- backendServices.update
- backendServices.patch

Asocia verificaciones de estado heredadas con balanceadores de cargas de red de transferencia externos basados en grupos de destino

Para asociar una verificación de estado heredada a un balanceador de cargas de red de transferencia externo nuevo, consulta Configura un balanceador de cargas de red de transferencia externo con un grupo de destino. En esta sección, se describe cómo asociar una verificación de estado heredada a un balanceador de cargas de red de transferencia externo basado en grupos de destino.

En esta sección, se da por sentado que hiciste esto:

Creaste un balanceador de cargas de red de transferencia externo basado en grupos de destino.
Creaste una verificación de estado heredada.
Creaste la regla de firewall necesaria.

Console

Para asociar una verificación de estado a un balanceador de cargas de red de transferencia externo basado en grupos de destino:

Ve a la página Balanceo de cargas en la consola de Google Cloud.
Ir a la página Balanceo de cargas
Haz clic en un balanceador de cargas para ver sus detalles.
Haz clic en Editar y, luego, en Configuración de backend.
Elige una verificación de estado heredada en el menú Verificación de estado. (solo se muestran las verificaciones de estado heredadas elegibles).
Haz clic en Actualizar.

gcloud

Para asociar una verificación de estado a un balanceador de cargas de red de transferencia externo basado en grupos de destino:

Identifica los grupos objetivos. Un balanceador de cargas de red de transferencia externo tiene al menos un grupo de destino y puede tener un grupo secundario alternativo.
```
gcloud compute target-pools list
```
Identifica una verificación de estado heredada con el protocolo HTTP. Si es necesario, consulta las verificaciones de estado heredadas.
Asocia la verificación de estado heredada a los grupos de destino. En los comandos siguientes, reemplaza TARGET_POOL_NAME por el nombre del grupo de destino, REGION por la región y LEGACY_CHECK_NAME por el nombre de la verificación de estado heredada. La verificación de estado heredada debe usar el protocolo HTTP.
- Usa este comando para quitar una verificación de estado HTTP heredada de un grupo de destino:
```
gcloud compute target-pools remove-health-checks TARGET_POOL_NAME \
    --region=REGION \
    --http-health-check LEGACY_CHECK_NAME
```
- Usa este comando para agregar una verificación de estado HTTP heredada a un grupo de destino:
```
gcloud compute target-pools add-health-checks TARGET_POOL_NAME \
    --region=REGION \
    --http-health-check LEGACY_CHECK_NAME
```

API

Puedes enumerar los grupos de destino con la llamada a la API targetPools.list.
Observa verificaciones de estado heredadas y, además, identifica una verificación de estado HTTP heredada.
Para asociar una verificación de estado HTTP heredada a un grupo de destino, usa la llamada a la API targetPools.addHealthCheck.

Comprueba el estado de la verificación de estado

Después de asociar una verificación de estado con un servicio de backend o un grupo de destino, puedes obtener el estado instantáneo de la verificación para los backends del balanceador de cargas.

Console

Dirígete a la página Balanceo de cargas.
Ir a la página Balanceo de cargas
Haz clic en el nombre de un balanceador de cargas.
En Backend, inspecciona la columna En buen estado. El estado se informa para cada grupo de instancias de backend o grupo de extremos de red.

gcloud

Para todos los balanceadores de cargas, excepto los de red de transferencia externos basados en grupos de destino, identifica el nombre y el alcance (globales o regionales) del servicio de backend. Para obtener una lista completa de los balanceadores de cargas y los alcances, consulta Servicios de backend.

Usa el comando compute backend-services get-health y reemplaza NAME por el nombre del servicio de backend y REGION por su región, si es necesario.
- Para obtener el estado instantáneo de un servicio de backend global, ejecuta este comando:
```
gcloud compute backend-services get-health GLOBAL_BACKEND_SERVICE_NAME \
    --global
```
- Para obtener el estado instantáneo de un servicio de backend regional, ejecuta este comando:
```
gcloud compute backend-services get-health REGIONAL_BACKEND_SERVICE_NAME \
    --region=REGION
```
Para los balanceadores de cargas de red de transferencia externos basados en grupos de destino, identifica el nombre y la región del grupo de destino del balanceador de cargas y, luego, usa el comando compute target-pools get-health, reemplazando NAME por el nombre del grupo de destino y REGION por su región.
```
gcloud compute target-pools get-health TARGET_POOL_NAME \
    --region=REGION
```

API

Para todos los balanceadores de cargas, excepto los de red de transferencia externos basados en grupos de destino, identifica el nombre y el alcance (globales o regionales) del servicio de backend. Para obtener una lista completa de los balanceadores de cargas y los alcances, consulta Servicios de backend.
- Para obtener el estado instantáneo de un servicio de backend global, usa backendServices.getHealth.
- Para obtener el estado instantáneo de un servicio de backend regional, usa regionBackendServices.getHealth.
Para los balanceadores de cargas de red de transferencia externos basados en grupos de destino, usa targetPools.getHealth