Descripción general de las verificaciones de estado

Google Cloud ofrece verificaciones de estado configurables para los backends de balanceador de cargas de Google Cloud, los backends de Cloud Service Mesh y la reparación automática basada en aplicaciones para grupos de instancias administrados. En este documento, se abordan los conceptos clave de la verificación de estado.

A menos que se indique lo contrario, las verificaciones de estado de Google Cloud se implementan mediante tareas de software dedicadas que se conectan a backends de acuerdo con los parámetros especificados en un recurso de verificación de estado. Cada intento de conexión se denomina sondeo. Google Cloud registra el éxito o el fracaso de cada sondeo.

En función de una cantidad configurable de sondeos secuenciales exitosos o fallidos, se calcula un estado general para cada backend. Los backends que responden de manera satisfactoria la cantidad de veces configurada se consideran en buen estado. Los backends que no responden de forma satisfactoria una cantidad distinta de veces configurada están en mal estado.

El estado general de cada backend determina si es apto para recibir solicitudes o conexiones nuevas. Puedes configurar los criterios que definen un sondeo exitoso. Esto se analiza en detalle en la sección Cómo funcionan las verificaciones de estado.

Las verificaciones de estado implementadas por tareas de software dedicadas usan rutas especiales que no están definidas en tu red de nube privada virtual (VPC). Si deseas obtener más información, consulta Rutas de acceso para las verificaciones de estado.

Protocolos, puertos y categorías de verificación de estado

Las verificaciones de estado tienen una categoría y un protocolo. Las dos categorías son verificaciones de estado y verificaciones de estado heredadas, y sus protocolos compatibles son los siguientes:

El protocolo y el puerto determinan cómo se realizan los sondeos de verificación de estado. Por ejemplo, una verificación de estado puede usar el protocolo HTTP en el puerto TCP 80 o el protocolo TCP para un puerto con nombre en un grupo de instancias.

No puedes convertir una verificación de estado heredada en una verificación de estado ni viceversa.

Selecciona una verificación de estado

Las verificaciones de estado deben ser compatibles con el tipo de balanceador de cargas (o Cloud Service Mesh) y los tipos de backend. Los factores que debes tener en cuenta cuando seleccionas una verificación de estado son los siguientes:

  • Categoría: Verificación de estado o verificación de estado heredada Solo los balanceadores de cargas de red de transferencia externos basados en grupos de destino requieren verificaciones de estado heredadas. Para todos los demás productos, usarás verificaciones de estado regulares.
  • Protocolo: Es el protocolo que Google Cloud usa para sondear los backends. Lo mejor es usar una verificación de estado (o de estado heredada) cuyo protocolo coincida con el protocolo que usa el servicio de backend del balanceador de cargas o el grupo de destino. Sin embargo, no es necesario que los protocolos de verificación de estado y los del balanceador de cargas sean los mismos.
  • Especificación de puerto: Puertos que Google Cloud usa con el protocolo. Debes especificar un puerto para tu verificación de estado. Las verificaciones de estado tienen dos métodos de especificación de puertos: --port y --use-serving-port. En las verificaciones de estado heredadas, hay un método: --port.

En la siguiente sección, se describen las selecciones de verificación de estado válidas para cada tipo de balanceador de cargas y backend.

Guía del balanceador de cargas

En esta tabla, se muestran la categoría, el alcance y la especificación de puertos admitidos para cada balanceador de cargas y tipo de backend.

Balanceador de cargas Tipo de backend Categoría y alcance de la verificación de estado Especificación de puerto
Balanceador de cargas de aplicaciones externo global

Balanceador de cargas de aplicaciones clásico 1

Balanceador de cargas de red del proxy externo global

Balanceador de cargas de red del proxy clásico
NEG compatibles Verificación de estado (global)
  • Número de puerto personalizado (--port)
  • Número de puerto del extremo (--use-serving-port)
Grupos de instancias Verificación de estado (global)
  • Número de puerto personalizado (--port)
  • Puerto con nombre del servicio de backend (--use-serving-port)
Balanceador de cargas de aplicaciones externo regional NEG compatibles Verificación de estado (regional)
  • Número de puerto personalizado (--port)
  • Número de puerto del extremo (--use-serving-port)
Grupos de instancias Verificación de estado (regional)
  • Número de puerto personalizado (--port)
  • Puerto con nombre del servicio de backend (--use-serving-port)
Balanceador de cargas interno de aplicaciones entre regiones
Balanceador de cargas de red de proxy interno entre regiones
NEG compatibles Verificación de estado (global)
  • Número de puerto personalizado (--port)
  • Número de puerto del extremo (--use-serving-port)
Grupos de instancias Verificación de estado (global)
  • Número de puerto personalizado (--port)
  • Puerto con nombre del servicio de backend (--use-serving-port)
Balanceador de cargas de aplicaciones interno regional

Balanceador de cargas de red del proxy interno regional

Balanceador de cargas de red del proxy externo regional
NEG compatibles Verificación de estado (regional)
  • Número de puerto personalizado (--port)
  • Número de puerto del extremo (--use-serving-port)
Grupos de instancias Verificación de estado (regional)
  • Número de puerto personalizado (--port)
  • Puerto con nombre del servicio de backend (--use-serving-port)
Balanceador de cargas de red de transferencia externo 2 Grupos de instancias Verificación de estado (regional)
  • Número de puerto personalizado (--port)
Instancias
en grupos de destino
Verificación de estado heredada
(global con el protocolo HTTP)
Las verificaciones de estado heredadas solo admiten la especificación del número de puerto (--port).
Balanceador de cargas de red de transferencia interno 2 NEG compatibles Verificación de estado (global o regional)
  • Número de puerto personalizado (--port)
Grupos de instancias Verificación de estado (global o regional)
  • Número de puerto personalizado (--port)
1 Para los balanceador de cargas de aplicaciones externos, las verificaciones de estado heredadas no se recomiendan, pero a veces son compatibles, según el modo del balanceador de cargas.
Modo de balanceador de cargas Compatible con las verificaciones de estado heredadas

Balanceador de cargas de aplicaciones externo global

Balanceador de cargas de aplicaciones clásico

Sí, si se cumplen las siguientes condiciones:
  • Los backends son grupos de instancias.
  • Las VMs de backend entregan tráfico que utiliza el protocolo HTTP o HTTPS.
Balanceador de cargas de aplicaciones externo regional No
2 No puedes usar la marca --use-serving-port porque los servicios de backend que se usan con balanceadores de cargas de red de transferencia interno y los balanceadores de cargas de red de transferencia externos no se suscriben a ningún puerto con nombre. Además, los balanceadores de cargas de red de transferencia internos solo admiten NEG zonales con extremos GCE_VM_IP, que carecen de información del puerto.

Notas de uso adicionales

  • Para los backends de grupos de instancias de VM, las verificaciones de estado se realizan solo en las instancias de VM que se inician. Las instancias de VM detenidas no reciben paquetes de verificación de estado.

  • Para los balanceadores de cargas de red de transferencia interna, solo puedes usar TCP o UDP para el protocolo del servicio de backend. Si entregas tráfico HTTP desde VMs detrás de un balanceador de cargas de red de transferencia interno, tiene sentido que emplees una verificación de estado con el protocolo HTTP.

  • Un balanceador de cargas de red de transferencia externo basado en grupos de destino debe usar una verificación de estado HTTP heredada. No puede usar una verificación de estado HTTPS heredada ni ninguna verificación de estado no heredada. Si usas un balanceador de cargas de red de transferencia externo basado en grupos de destino para balancear el tráfico de TCP, debes ejecutar un servicio HTTP en las VMs cuyas cargas se balancean para que puedan responder a los sondeos de verificación de estado.

    Para casi todos los demás tipos de balanceadores de cargas, debes usar verificaciones de estado normales no heredadas en las que el protocolo coincida con el protocolo del servicio de backend del balanceador de cargas.

  • Para los servicios de backend que usan el protocolo gRPC, usa solo las verificaciones de estado de gRPC o TCP. No uses verificaciones de estado de HTTP(S) o HTTP/2.

  • Ciertos balanceadores de cargas basados en Envoy que usan backends de NEG híbridos no admiten verificaciones de estado de gRPC. Para obtener más información, consulta la descripción general de los NEG híbridos.

Verifica el estado con Cloud Service Mesh

Ten en cuenta las siguientes diferencias de comportamiento cuando uses verificaciones de estado con Cloud Service Mesh.

  • Con Cloud Service Mesh, el comportamiento de la verificación de estado para los extremos de red del tipo INTERNET_FQDN_PORT y NON_GCP_PRIVATE_IP_PORT difiere del comportamiento de la verificación de estado para otros tipos de extremos de red. En lugar de usar las tareas de software dedicadas, Cloud Service Mesh programa los proxies de Envoy a fin de realizar verificaciones de estado para NEG de Internet (extremos INTERNET_FQDN_PORT) y NEG híbridos (extremos NON_GCP_PRIVATE_IP_PORT).

    Envoy admite los siguientes protocolos para la verificación de estado:

    • HTTP
    • HTTPS
    • HTTP/2
    • TCP
  • Cuando Cloud Service Mesh se integra en el Directorio de servicios y vinculas un servicio de Directorio de servicios a uno de backend de Cloud Service Mesh, no puedes establecer una verificación de estado en el servicio de backend.

Cómo funcionan las verificaciones de estado

En las siguientes secciones, se describe cómo funcionan las verificaciones de estado.

Sondeos

Cuando creas una verificación de estado o una verificación de estado heredada, especificas las siguientes marcas o aceptas sus valores predeterminados. Cada verificación de estado o verificación de estado heredada que creas se implementa mediante varios sondeos. Estas marcas controlan con qué frecuencia cada sondeo evalúa instancias en grupos de instancias o extremos en NEG zonales.

La configuración de una verificación de estado no se puede establecer por backend. Las verificaciones de estado están asociadas con un servicio de backend completo. Para un balanceo de cargas de red de transferencia externa basado en grupos de destino, una verificación de estado HTTP heredada se asocia a todo el grupo de destino. Por lo tanto, los parámetros del sondeo son los mismos para todos los backends a los que hace referencia un servicio de backend o grupo de destino determinado.

Marca de configuración Propósito Valor predeterminado
Intervalo de verificación
check-interval
El intervalo de verificación es la cantidad de tiempo desde el inicio de un sondeo emitido por un sistema de sondeo hasta el inicio del siguiente sondeo emitido por el mismo sistema de sondeo. Las unidades son segundos. 5s (5 segundos)
Tiempo de espera
timeout
El tiempo de espera es 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. Las unidades son segundos. 5s (5 segundos)

Rangos de IP de sondeo y reglas de firewall

Para que las verificaciones de estado funcionen, debes crear reglas de firewall de entrada allow, de modo que el tráfico de los sistemas de sondeo de Google Cloud pueda conectarse a tus backends.

En la siguiente tabla, se muestran los rangos de IP de origen para permitir los siguientes servicios:

Producto Rangos de IP de origen del sondeo Ejemplo de regla de firewall
  • Balanceador de cargas de aplicaciones externo global
  • Balanceador de cargas de red del proxy externo global
  • 35.191.0.0/16
  • 130.211.0.0/22

Para el tráfico IPv6 a los backends:

  • 2600:2d00:1:b029::/64
  • 2600:2d00:1:1::/64
Reglas de firewall para todos los productos excepto los balanceadores de cargas de red de transferencia externos
  • Balanceador de cargas de aplicaciones externo regional 1, 2
  • Balanceador de cargas de aplicaciones interno entre regiones 1
  • Balanceador de cargas de aplicaciones interno regional 1, 2
  • Balanceador de cargas de red de transferencia interno
  • Balanceador de cargas de red de proxy clásico
  • Balanceador de cargas de aplicaciones clásico
  • Balanceador de cargas de red del proxy interno regional1, 2
  • Balanceador de cargas de red del proxy interno entre regiones 1
  • Balanceador de cargas de red del proxy externo regional1, 2
  • Cloud Service Mesh, excepto para backends de NEG de Internet y de NEG híbridos
  • 35.191.0.0/16
  • 130.211.0.0/22
Reglas de firewall para todos los productos excepto los balanceadores de cargas de red de transferencia externos
Balanceador de cargas de red de transferencia externo

Para el tráfico IPv4 a los backends:

  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22

Para el tráfico IPv6 a los backends:

  • 2600:1901:8001::/48
3
Reglas de firewall para balanceadores de cargas de red de traspaso externos
Balanceador de cargas de red de transferencia interno

Para el tráfico IPv4 a los backends:

  • 35.191.0.0/16
  • 130.211.0.0/22

Para el tráfico IPv6 a los backends:

  • 2600:2d00:1:b029::/64
Reglas de firewall para los balanceadores de cargas de red de transferencia internos
Cloud Service Mesh con backends de NEG de Internet y backends de NEG híbridos Direcciones IP de las VMs que ejecutan el software de Envoy Ejemplo de regla de firewall

1 No es necesario agregar los rangos de sondeo de verificación de estado de Google a una lista de entidades permitidas para NEGs híbridos. Sin embargo, si usas una combinación de NEGs híbridos y zonales en un solo servicio de backend, debes agregar los rangos de sondeo de verificación de estado de Google a una lista de entidades permitidas para los NEGs zonales.

2 Para los NEGs de Internet regionales, las verificaciones de estado son opcionales. El tráfico de los balanceadores de cargas que usan NEGs de Internet regionales se origina desde la subred de solo proxy y, luego, se traduce con NAT (mediante Cloud NAT) a cualquiera de los manuales o direcciones IP de NAT asignadas automáticamente. Este tráfico incluye sondeos de verificación de estado y solicitudes de usuario del balanceador de cargas a los backends. Para obtener más detalles, consulta NEG regionales: Usa Cloud NAT para la salida.

3 Los balanceadores de cargas de red de transferencia externo basados en grupos de destino solo admiten tráfico IPv4 y pueden proxy las verificaciones de estado a través del servidor de metadatos. En este caso, las fuentes de paquetes de verificación de estado coinciden con la dirección IP del servidor de metadatos: 169.254.169.254. No es necesario crear reglas de firewall para permitir el tráfico desde el servidor de metadatos. Los paquetes del servidor de metadatos siempre se permiten.

Importancia de las reglas de firewall

Google Cloud requiere que crees las reglas de firewall de entrada allow necesarias para permitir el tráfico de los sistemas de sondeo a tus backends. Como práctica recomendada, limita estas reglas a solo los protocolos y los puertos que coincidan con los que usan tus verificaciones de estado. Para los rangos de IP de origen, asegúrate de usar los rangos de IP del sondeo documentados que se enumeran en la sección anterior.

Si no tienes reglas de firewall de entrada allow que permitan la verificación de estado, la regla deny implícita bloquea el tráfico entrante. Cuando los sistemas de sondeo no pueden comunicarse con los backends, el balanceador de cargas considera que los backends están en mal estado.

Consideraciones de seguridad para los rangos de IP del sondeo

Considera la siguiente información cuando planifiques las verificaciones de estado y las reglas de firewall necesarias:

  • Los rangos de IP del sondeo pertenecen a Google. Google Cloud usa rutas especiales fuera de la red de VPC, pero dentro de la red de producción de Google para facilitar la comunicación de los sistemas de sondeo.

  • Google usa los rangos de IP de sondeo a fin de enviar sondeos de verificación de estado para balanceadores de cargas de aplicación y balanceadores de cargas de red de proxy externos. Si se recibe un paquete de Internet y la dirección IP de origen del paquete se encuentra dentro de un rango de IP de sondeo, Google descarta el paquete. Esto incluye la dirección IP externa de una instancia de Compute Engine o un nodo de Google Kubernetes Engine (GKE).

  • Los rangos de IP de sondeo son un conjunto completo de direcciones IP posibles que usan los sistemas de sondeo de Google Cloud. Si usas tcpdump o una herramienta similar, es posible que no observes el tráfico de todas las direcciones IP en todos los rangos de IP de sondeo. Como práctica recomendada, crea reglas de firewall de entrada que permitan todos los rangos de IP de sondeo como fuentes. Google Cloud puede implementar sistemas de sondeo nuevos de forma automática sin notificaciones.

Varios sondeos y frecuencia

Google Cloud envía sondeos de verificación de estado desde varios sistemas redundantes denominados sistemas de sondeo. Los sistemas de sondeo usan rangos de IP de origen específicos. Google Cloud no se basa en un solo sistema de sondeo para implementar una verificación de estado: varios sistemas de sondeo evalúan de forma simultánea las instancias en los backends de grupo de instancias o los extremos en los backends de NEG zonales. Si un sistema de sondeo falla, Google Cloud sigue realizando un seguimiento de los estados del backend.

La configuración del intervalo y el tiempo de espera que estableces para una verificación de estado se aplica a cada sistema de sondeo. Para un backend determinado, los registros de acceso al software y tcpdump muestran sondeos más frecuentes que la configuración establecida.

Este es el comportamiento esperado y no puedes configurar la cantidad de sistemas de sondeo que usa Google Cloud para las verificaciones de estado. Sin embargo, puedes estimar el efecto de varios sondeos simultáneos si tienes en cuenta los siguientes factores:

  • Ten estos factores en cuenta para estimar la frecuencia de sondeo por servicio de backend:

    • Frecuencia de base por servicio de backend. Cada verificación de estado tiene una frecuencia de verificación asociada que es inversamente proporcional al intervalo de verificación configurado:

      1(intervalo de verificación)

      Cuando asocias una verificación de estado con un servicio de backend, estableces una frecuencia de base que usa cada sistema de sondeo para los backends en ese servicio de backend.

    • Factor de escala del sondeo. La frecuencia de base del servicio de backend se multiplica por la cantidad de sistemas de sondeo simultáneos que usa Google Cloud. Esta cantidad puede variar, pero, por lo general, está entre 5 y 10.

  • Varias reglas de reenvío para balanceadores de cargas de red de transferencia internas. Si configuraste varias reglas de reenvío internas (cada una con una dirección IP diferente) que apuntan al mismo servicio de backend interno regional, Google Cloud usa varios sistemas de sondeo para verificar cada dirección IP. La frecuencia de sondeo por servicio de backend se multiplica por la cantidad de reglas de reenvío configuradas.

  • Varias reglas de reenvío para balanceadores de cargas de red de transferencia externos. Si configuraste varias reglas de reenvío que apuntan al mismo servicio de backend o grupo de destino, Google Cloud utiliza varios sistemas de sondeo para verificar cada dirección IP. La frecuencia de sondeo por VM de backend se multiplica por la cantidad de reglas de reenvío configuradas.

  • Varios proxies de destino para balanceadores de cargas de aplicaciones externos. Si tienes varios proxies de destino que dirigen el tráfico al mismo mapa de URL, Google Cloud utiliza varios sistemas de sondeo para verificar la dirección IP asociada con cada proxy de destino. La frecuencia de sondeo por servicio de backend se multiplica por la cantidad de proxies de destino configurados.

  • Varios proxies de destino para balanceadores de cargas de red de proxy externo y balanceadores de cargas de red de proxy interno regionales. Si configuraste varios proxies de destino que dirigen el tráfico al mismo servicio de backend, Google Cloud usa varios sistemas de sondeo para verificar la dirección IP asociada con cada proxy de destino. La frecuencia de sondeo por servicio de backend se multiplica por la cantidad de proxies de destino configurados.

  • Suma los servicios de backend. Si varios servicios de backend usan un backend, las instancias de backend se contactan con tanta frecuencia como la suma de frecuencias para cada verificación de estado del servicio de backend.

    Con los backends de NEG zonales, es más difícil determinar la cantidad exacta de sondeos de verificación de estado. Por ejemplo, el mismo extremo puede estar en varios NEG zonales. Esos NEG zonales no necesariamente tienen el mismo conjunto de extremos, y diferentes extremos pueden apuntar al mismo backend.

Destino para paquetes de sondeo

En la siguiente tabla, se muestra la interfaz de red y las direcciones IP de destino a las que los sistemas de sondeo de verificación de estado envían paquetes, según el tipo de balanceador de cargas.

Para los balanceadores de cargas de red de transferencia externos y los ¡internos, la aplicación debe vincularse a la dirección IP del balanceador de cargas (o a cualquier dirección IP 0.0.0.0).

Balanceador de cargas Interfaz de la red de destino Dirección IP de destino
  • Balanceador de cargas de aplicaciones externo global
  • Balanceador de cargas de red del proxy externo global
  • Para los backends de grupo de instancias, la interfaz de red principal (nic0).
  • Para los backends de NEG zonales con extremos GCE_VM_IP_PORT, la interfaz de red en la red de VPC asociada con el NEG.
  • Para los backends de NEG zonales con extremos NON_GCP_PRIVATE_IP_PORT, el extremo debe representar una interfaz de un recurso local a la que se pueda acceder a través de una ruta en la red de VPC asociada con el NEG y en la región que contiene el NEG.
  • Para los backends de grupo de instancias, la dirección IPv4 o IPv6 interna principal asociada con la interfaz de red principal (nic0) de cada instancia.
  • Para los backends de NEG zonales con extremos GCE_VM_IP_PORT, la dirección IP del extremo: una dirección IPv4 o IPv6 interna principal de la interfaz de red o una dirección IPv4 o IPv6 interna de un rango de alias de IP de la interfaz de red.
  • Para los backends de NEG zonales con extremos NON_GCP_PRIVATE_IP_PORT, la dirección IP del extremo.
  • 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
  • Balanceador de cargas de red de proxy clásico
  • Balanceador de cargas de red del proxy interno regional
  • Balanceador de cargas de red del proxy interno entre regiones
  • Cloud Service Mesh
  • Para los backends de grupo de instancias, la interfaz de red principal (nic0).
  • Para los backends de NEG zonales con extremos GCE_VM_IP_PORT, la interfaz de red en la red de VPC asociada con el NEG.
  • Para los backends de NEG zonales con extremos NON_GCP_PRIVATE_IP_PORT, el extremo debe representar una interfaz de un recurso local a la que se pueda acceder a través de una ruta en la red de VPC asociada con el NEG y en la región que contiene el NEG.
  • Para los backends de grupo de instancias, la dirección IPv4 interna principal asociada con la interfaz de red principal (nic0) de cada instancia.
  • Para los backends de NEG zonales con extremos GCE_VM_IP_PORT, la dirección IP del extremo: una dirección IPv4 interna principal de la interfaz de red o una dirección IPv4 interna de un rango de alias de IP de la red.
  • Para los backends de NEG zonales con extremos NON_GCP_PRIVATE_IP_PORT, la dirección IP del extremo.
Balanceador de cargas de red de transferencia externo Interfaz de red principal (nic0)

La dirección IP de la regla de reenvío externa.

Si varias reglas de reenvío apuntan al mismo servicio de backend (para el balanceador de cargas de red basado en grupos de destino, el mismo grupo de destino), Google Cloud envía sondeos a la dirección IP de cada regla de reenvío. Esto puede generar un aumento en la cantidad de sondeos.

Balanceador de cargas de red de transferencia interno Para los backends de grupo de instancias y los backends de NEG zonales con extremos GCE_VM_IP, la interfaz de red usada depende de cómo se configure el servicio de backend. Para obtener más información, consulta Servicios de backend e interfaces de red.

La dirección IP de la regla de reenvío interno.

Si varias reglas de reenvío apuntan al mismo servicio de backend, Google Cloud envía sondeos a cada dirección IP de la regla de reenvío. Esto puede generar un aumento en la cantidad de sondeos.

Criterios de éxito para HTTP, HTTPS y HTTP/2

Cuando una verificación de estado usa el protocolo HTTP, HTTPS o HTTP/2, cada sondeo requiere que se entregue un código de estado HTTP 200 (OK) antes de que se agote el tiempo de espera del sondeo. Además, puedes hace lo siguiente:

  • Puedes configurar los sistemas de sondeo de Google Cloud para que envíen solicitudes HTTP a una ruta de solicitud específica. Si no especificas una ruta de solicitud, se usará /.

  • Si configuras una verificación de estado basada en contenido mediante la especificación de una string de respuesta esperada, Google Cloud deberá encontrar la string esperada en los primeros 1,024 bytes del cuerpo de la respuesta HTTP.

Las siguientes combinaciones de ruta de solicitud y marcas de string de respuesta están disponibles para las verificaciones de estado que usan los protocolos HTTP, HTTPS y HTTP/2.

Marca de configuración Criterios para alcanzar el éxito
Ruta de solicitud
request-path
Especifica la ruta de URL a la que Google Cloud envía las solicitudes de sondeo de verificación de estado.
Si se omite, Google Cloud enviará las solicitudes de sondeo a la ruta raíz, /.
Respuesta
response
La marca de respuesta opcional te permite configurar una verificación de estado basada en el contenido. La string de respuesta esperada debe ser menor o igual que 1,024 caracteres ASCII (un solo byte). Cuando se configura, Google Cloud espera esta string en los primeros 1,024 bytes de la respuesta, además de recibir un código de estado HTTP 200 (OK).

Criterios de éxito para SSL y TCP

A menos que especifiques una string de respuesta esperada, los sondeos de verificación de estado que usan los protocolos SSL y TCP se ejecutan de forma correcta cuando las dos condiciones base son verdaderas:

  • Cada sistema de sondeo de Google Cloud puede completar de forma correcta un protocolo de enlace SSL o TCP antes de que se agote el tiempo de espera del sondeo.
  • Para las verificaciones de estado de TCP, la sesión de TCP se finaliza de forma correcta de las siguientes maneras:
    • El backend o
    • El sistema de sondeo de Google Cloud que envía un paquete de TCP RST (reset) mientras la sesión de TCP para el sistema de sondeo aún está establecida

Si el backend envía un paquete de TCP RST (reset) con el objetivo de cerrar una sesión de TCP para una verificación de estado de TCP, el sondeo podría considerarse incorrecto. Esto sucede cuando el sistema de sondeo de Google Cloud ya inició una finalización correcta de TCP.

Puedes crear una verificación de estado basada en contenido si proporcionas una string de solicitud y una string de respuesta esperada, cada una de hasta 1,024 caracteres ASCII (de un solo byte) de longitud. Cuando se configura una string de respuesta esperada, Google Cloud considera que un sondeo es exitoso solo si se cumplen las condiciones básicas y si la string de respuesta que se muestra coincide de forma exacta con la string de respuesta esperada.

Las siguientes combinaciones de solicitudes y marcas de respuesta están disponibles para las verificaciones de estado que usan los protocolos SSL y TCP.

Marcas de configuración Criterios para alcanzar el éxito
No se especificó ninguna solicitud ni respuesta

No se especificó ninguna marca: --request, --response
Google Cloud considera que el sondeo tuvo éxito cuando se cumplen las condiciones básicas.
Se especificaron la solicitud y la respuesta

Se especificaron ambas marcas: --request, --response
Google Cloud envía la string de solicitud configurada y aguarda la string de respuesta esperada. Google Cloud considera que el sondeo tuvo éxito cuando se cumplen las condiciones básicas y cuando la string de respuesta que se muestra coincide de forma exacta con la string de respuesta esperada.
Solo se especificó la respuesta

Marcas especificadas: solo --response
Google Cloud aguarda la string de respuesta esperada y considera que el sondeo tuvo éxito cuando se cumplen las condiciones básicas y cuando la string de respuesta que se muestra coincide de forma exacta con la string de respuesta esperada.

Solo deberías usar --response si tus backends envían de forma automática una string de respuesta como parte del protocolo de enlace TCP o SSL.
Solo se especificó la solicitud

Marcas especificadas: solo --request
Google Cloud envía la string de solicitud configurada y considera que el sondeo se ejecuta de forma correcta cuando se cumplen las condiciones básicas. La respuesta, si la hay, no está verificada.

Criterios de éxito para gRPC

Si usas verificaciones de estado de gRPC, asegúrate de que el servicio de gRPC envíe la respuesta de RPC con el estado OK y el campo de estado configurado en SERVING o NOT_SERVING, según corresponda.

Ten en cuenta lo siguiente:

  • Las verificaciones de estado de gRPC solo se usan con aplicaciones de gRPC y Cloud Service Mesh.
  • Las verificaciones de estado de gRPC no son compatibles con TLS.

Para obtener más información, consulta lo siguiente:

Criterios de éxito para las verificaciones de estado heredadas

Si la respuesta que recibe el sondeo de verificación de estado heredada es HTTP 200 OK, el sondeo se considera correcto. Todos los demás códigos de respuesta HTTP, incluido un redireccionamiento (301302), se consideran en mal estado.

Estado

Google Cloud usa las siguientes marcas de configuración para determinar el estado general de cada backend cuya carga de tráfico se balancea.

Marca de configuración Propósito Valor predeterminado
Umbral de buen estado
healthy-threshold
El umbral de buen estado especifica la cantidad de resultados de sondeos secuenciales correctos para que se considere que un backend está en buen estado. Un umbral de 2 sondeos.
Umbral de mal estado
unhealthy-threshold
El umbral de mal estado especifica la cantidad de resultados de sondeos secuenciales fallidos para que se considere que un backend está en mal estado. Un umbral de 2 sondeos.

Google Cloud considera que los backends están en buen estado después de alcanzar este umbral de buen estado. Los backends en buen estado son aptos para recibir conexiones nuevas.

Google Cloud considera que los backends están en mal estado cuando alcanzan el umbral de mal estado. Los backends en mal estado no son aptos para recibir conexiones nuevas. Sin embargo, las conexiones existentes no se finalizan de inmediato. En cambio, la conexión permanece abierta hasta que se agota el tiempo de espera o se deja de recibir tráfico.

Según la causa por la que falla el sondeo, puede que las conexiones existentes no muestren respuestas. Un backend en mal estado puede revertirse si es capaz de volver a alcanzar el umbral de buen estado.

Cuando todos los backends están en mal estado, el comportamiento específico difiere según el tipo de balanceador de cargas que uses:

Balanceador de cargas Comportamiento cuando todos los backends están en mal estado
Balanceador de cargas de aplicaciones clásico Muestra un código de estado HTTP “502” a los clientes cuando ninguno de los backends está en buen estado.
Balanceador global de cargas de aplicaciones externo
Balanceador regional de cargas de aplicaciones externo
Balanceador de cargas de aplicaciones interno
Muestra un código de estado HTTP “503” a los clientes cuando ninguno de los backends está en buen estado.
Balanceadores de cargas de red del proxy Finalizar las conexiones de clientes cuando ninguno de los backends está en buen estado.
Balanceadores de cargas de red de transferencia internos y balanceadores de cargas de red de transferencia externos basados en servicios de backend

Distribuye el tráfico a todas las VMs de backend como último recurso cuando todos los backends están en mal estado y la conmutación por error no está configurada.

Para obtener más detalles sobre este comportamiento, consultaDistribución de tráfico para balanceadores de cargas de red de transferencia interno y Distribución de tráfico para balanceadores de cargas de red externos basados en servicios de backend.

Balanceadores de cargas de red de transferencia externos basados en grupos de destino

Distribuye el tráfico a todas las VMs de backend como último recurso cuando ninguno de los backends esté en buen estado.

Notas adicionales

En las siguientes secciones, se incluyen algunas notas más sobre el uso de verificaciones de estado en Google Cloud.

Verificaciones de estado basadas en el contenido

Una verificación de estado basada en contenido es aquella cuyo criterio de éxito depende de la evaluación de una string de respuesta esperada. Usa una verificación de estado basada en contenido para que los sondeos de verificación de estado de Google Cloud validen de forma más completa la respuesta de tu backend.

  • Para configurar una verificación de estado basada en contenido HTTP, HTTPS o HTTP/2, especifica una string de respuesta esperada y, de forma opcional, define una ruta de solicitud. A fin de obtener más detalles, consulta Criterios de éxito para HTTP, HTTPS y HTTP/2.

  • Para configurar una verificación de estado basada en contenido SSL o TCP, especifica una string de respuesta esperada y, de forma opcional, define una string de solicitud. A fin de obtener más detalles, consulta Criterios de éxito para SSL y TCP.

Certificados y verificaciones de estado

Los sistemas de sondeo de verificación de estado de Google Cloud no validan certificados, incluso para protocolos que requieren que los backends usen certificados (SSL, HTTPS y HTTP/2), por ejemplo:

  • Puedes usar certificados autofirmados o firmados por cualquier autoridad certificadora (CA).
  • Se aceptan certificados caducados o que aún no son válidos.
  • Ni los atributos CN ni subjectAlternativeName deben coincidir con un encabezado Host o un registro PTR de DNS.

Encabezados

Las verificaciones de estado que usan cualquier protocolo, pero no las verificaciones de estado heredadas, te permiten establecer un encabezado de proxy mediante la marca --proxy-header.

Las verificaciones de estado que usan protocolos HTTP, HTTPS o HTTP/2 y las verificaciones de estado heredadas te permiten especificar un encabezado HTTP Host mediante la marca --host.

Si usas encabezados de solicitud personalizados, ten en cuenta que el balanceador de cargas agrega estos encabezados solo a las solicitudes del cliente, no a los sondeos de verificación de estado. Si el backend requiere un encabezado específico para la autorización que falta en el paquete de verificación de estado, la verificación de estado puede fallar.

Ejemplo de verificación de estado

Supongamos que configuraste una verificación de estado de esta manera:

  • Intervalo: 30 segundos
  • Tiempo de espera: 5 segundos
  • Protocolo: HTTP
  • Umbral de mal estado: 2 (predeterminado)
  • Umbral de buen estado: 2 (predeterminado)

Con esta configuración, la verificación de estado se comporta de la siguiente manera:

  1. Varios sistemas redundantes se configuran en simultáneo con los parámetros de verificación de estado. La configuración de intervalo y tiempo de espera se aplica a cada sistema. Para obtener más información, consulta Varios sondeos y frecuencia.
  2. Cada sistema de sondeo de verificación de estado hace lo siguiente:

    1. Inicia una conexión HTTP desde una de las direcciones IP de origen hasta la instancia de backend cada 30 segundos.
    2. Espera hasta cinco segundos por un código de estado 200 (OK) (criterios de éxito para los protocolos HTTP, HTTPS y HTTP/2).
  3. Un backend se considera en mal estado cuando al menos un sistema de sondeo de verificación de estado se comporta de la siguiente manera:

    1. No recibe un código de respuesta HTTP 200 (OK) para dos sondeos consecutivos. Por ejemplo, es posible que se rechace la conexión o que se agote el tiempo de espera de la conexión o el socket.
    2. Recibe dos respuestas consecutivas que no coinciden con los criterios de éxito específicos del protocolo.
  4. Un backend se considera en buen estado cuando al menos un sistema de sondeo de verificación de estado recibe dos respuestas consecutivas que coinciden con los criterios de éxito específicos del protocolo.

En este ejemplo, cada sistema de sondeo inicia una conexión cada 30 segundos. Transcurren treinta segundos entre los intentos de conexión de un sistema de sondeo, sin importar la duración del tiempo de espera (si se agotó o no la conexión). En otras palabras, el tiempo de espera siempre debe ser menor o igual que el intervalo y nunca aumenta el intervalo.

En este ejemplo, el tiempo de cada sistema de sondeo es similar al siguiente, en segundos:

  1. t=0: Iniciar el sondeo A.
  2. t=5: Detener el sondeo A.
  3. t=30: Iniciar el sondeo B.
  4. t=35: Detener el sondeo B.
  5. t=60: Iniciar el sondeo C.
  6. t=65: Detener el sondeo C.

¿Qué sigue?