Descripción general de las verificaciones de estado

Google Cloud proporciona mecanismos de verificación de estado que determinan si los backends, como los grupos de instancias y los grupos de extremos de red (NEG) zonales, responden correctamente al tráfico. En este documento, se analizan los conceptos de verificación de estado específicos de Google Cloud y sus balanceadores de cargas.

Google Cloud proporciona sistemas de verificación de estado globales y regionales que se conectan a backends de forma periódica y configurable. Cada intento de conexión se denomina sondeo, y cada sistema de verificación de estado se denomina sistema de sondeo. Google Cloud registra el éxito o el fracaso de cada sondeo.

Las verificaciones de estado y los balanceadores de cargas funcionan en conjunto. Según una cantidad configurable de sondeos secuenciales exitosos o fallidos, Google Cloud calcula el estado general de cada backend en el balanceador de cargas. Los backends que responden de manera satisfactoria al número de veces configurado se consideran en buen estado. Los backends que no responden de manera satisfactoria una cantidad distinta de veces están en mal estado.

Google Cloud utiliza el estado general de cada backend a fin de determinar si es apto para recibir solicitudes o conexiones nuevas. Además de poder configurar la frecuencia de sondeo y los umbrales de estado, puedes configurar los criterios que definen un sondeo exitoso. Esto se analiza en detalle en la sección sobre cómo funcionan las verificaciones de estado.

Google Cloud utiliza rutas especiales no definidas en tu red de nube privada virtual (VPC) para las verificaciones de estado. Para obtener información completa, consulta el artículo sobre rutas de retorno del balanceador de cargas.

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

Google Cloud organiza las verificaciones de estado por categoría y protocolo.

Las dos categorías son verificaciones de estado y verificaciones de estado heredadas. Cada categoría admite un conjunto diferente de protocolos y un medio para especificar el puerto que se usa en la verificación de estado. El protocolo y el puerto determinan cómo los sistemas de verificación de estado de Google Cloud establecen contacto con tus backends. Por ejemplo, puedes crear una verificación de estado que use el protocolo HTTP en el puerto TCP 80 o puedes crear una que use el protocolo TCP para un puerto con nombre configurado en un grupo de instancias.

La mayoría de los balanceadores de cargas de Google Cloud requieren verificaciones de estado no heredadas, pero el balanceo de cargas de red requiere verificaciones de estado heredadas que usen el protocolo HTTP. Puedes encontrar instrucciones específicas sobre cómo seleccionar la categoría, el protocolo y los puertos en la siguiente sección: “Selecciona una verificación de estado”.

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

Selecciona una verificación de estado

Las verificaciones de estado deben ser compatibles con el tipo de balanceador de cargas y los tipos de backends (grupos de instancias o NEG zonales) que utilizan. Estos son los tres factores que debes especificar cuando creas una verificación de estado:

  • Categoría: verificación de estado o verificación de estado heredada, que debe ser compatible con el balanceador de cargas.
  • Protocolo: define qué protocolo usarán los sistemas de Google Cloud para sondear periódicamente tus backends.
  • Especificación de puerto: define qué puertos se usarán para el protocolo de verificación de estado.

En la guía al final de esta sección, se resumen combinaciones válidas de categoría de verificación de estado, protocolo y especificación de puerto en función de un tipo determinado de balanceador de cargas y de backend.

Para obtener información sobre los tipos de verificaciones de estado admitidas por varios balanceadores de cargas, consulta este artículo sobre las verificaciones de estado.

Categoría y protocolo

El tipo de balanceador de cargas y los tipos de backends que usa el balanceador de cargas determinan la categoría de la verificación de estado. El balanceo de cargas de red requiere verificaciones de estado heredadas que usen el protocolo HTTP. Todos los demás tipos de balanceadores de cargas usan verificaciones de estado normales.

Debes seleccionar un protocolo de la lista de protocolos compatibles con la categoría de verificación de estado. Se recomienda usar el mismo protocolo que el balanceador de cargas. Sin embargo, esto no es un requisito ni siempre es posible. Por ejemplo, los balanceadores de cargas de red requieren verificaciones de estado heredadas que usen el protocolo HTTP, a pesar de que el balanceo de cargas de red admite TCP y UDP en general. Para los balanceadores de cargas de red, debes ejecutar un servidor HTTP en tus instancias de máquina virtual (VM) para que puedan responder a los sondeos de verificación de estado.

En la siguiente tabla, se enumeran las categorías de verificación de estado y los protocolos que admite cada categoría.

Categoría de verificación de estado Protocolos admitidos
Verificación de estado • HTTP
• HTTPS
• HTTP/2 (con TLS)
• SSL
• TCP
Verificación de estado heredada • HTTP
• HTTPS

Las verificaciones de estado HTTPS heredadas no son compatibles con los balanceadores de cargas de red y no se pueden usar con la mayoría de los otros tipos de balanceadores de cargas.

Categoría y especificación de puerto

Además de un protocolo, debes seleccionar una especificación de puerto para la verificación de estado. Las verificaciones de estado proporcionan tres métodos de especificación de puerto y las verificaciones de estado heredadas, uno. No todos los métodos de especificación de puertos son aplicables a cada tipo de balanceador de cargas. El tipo de balanceador de cargas y los tipos de backends que usa el balanceador de cargas determinan qué método de especificación de puertos puedes usar.

Categoría de verificación de estado Métodos de especificación de puertos y significados
Verificación de estado --port: especifica un número de puerto TCP
--port-name: especifica cualquier puerto con nombre configurado en un grupo de instancias
--use-serving-port: para los grupos de instancias, usa el mismo puerto con nombre utilizado por el servicio de backend; en el caso de los NEG zonales, usa el puerto definido en cada extremo
Verificación de estado heredada --port: especifica un número de puerto TCP

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 de Google Cloud y tipo de backend.

Balanceador de cargas Tipo de backend Categoría y alcance de la verificación de estado Especificación de puerto
Balanceo de cargas TCP/UDP interno1 Grupos de instancias Verificación de estado (global)
  • Número de puerto personalizado (--port)
  • Puerto con nombre personalizado (--port-name)
Balanceo de cargas HTTP(S) interno NEG zonales 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 personalizado (--port-name)
  • Puerto con nombre del servicio de backend (--use-serving-port)
Balanceo de cargas de red Instancias
en grupos de destino
Verificación de estado heredada (global) que usa el protocolo HTTP Las verificaciones de estado heredadas solo admiten la especificación del número de puerto (--port).
Balanceo de cargas HTTP(S) externo 2

Balanceo de cargas de proxy TCP

Balanceo de cargas del proxy SSL
NEG zonales 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 personalizado (--port-name)
  • Puerto con nombre del servicio de backend (--use-serving-port)

1 No puedes usar la marca --use-serving-port porque los servicios de backend internos no tienen un puerto con nombre asociado.
2 Es posible, pero no se recomienda, usar una verificación de estado heredada para servicios de backend asociados con balanceadores de cargas HTTP(S) externos en las siguientes circunstancias:

  • Los backends son grupos de instancias, no NEG zonales.
  • Las VM de backend entregan tráfico que utiliza protocolos HTTP o HTTPS.

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 de verificación de estado de Google Cloud evalúa instancias en backends de grupo de instancias o extremos en backends de NEG zonales.

La configuración de una verificación de estado no se puede establecer por backend. Las verificaciones de estado se asocian con un servicio de backend completo, y las verificaciones de estado heredadas se asocian con un grupo de destino completo (para balanceo de cargas de red) o servicio de backend (correspondiente a ciertas configuraciones de balanceo de cargas HTTP(S) externo). 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. Si se omite, Google Cloud utilizará 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. Si se omite, Google Cloud utilizará 5s (5 segundos).

Rangos de IP del sondeo y reglas de firewall

Para que las verificaciones de estado funcionen, debes crear reglas de firewall de entrada allow, de modo tal 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 que se permiten según el tipo de balanceador de cargas.

Balanceador de cargas Rangos de IP de origen del sondeo Ejemplo de regla de firewall
Balanceo de cargas TCP/UDP interno
Balanceo de cargas HTTP(S) interno
Balanceo de cargas HTTP(S) externo
Balanceo de cargas de proxy SSL
Balanceo de cargas de proxy TCP
35.191.0.0/16
130.211.0.0/22
Reglas de firewall para todos los balanceadores de cargas, excepto los balanceadores de cargas de red
Balanceo de cargas de red 35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
Reglas de firewall para los balanceadores de cargas de red

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 solo a los protocolos y puertos que coincidan con los que tus verificaciones de estado usan. 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 el protocolo, el puerto y el rango de IP de origen que usa tu verificación de estado, la regla de firewall de entrada deny implícita bloquea el tráfico entrante de todas las fuentes. Cuando los sistemas de sondeo no puedan comunicarse con tus backends, el balanceador de cargas de Google Cloud clasifica todos tus backends como en mal estado. El comportamiento cuando ninguno de los backends está buen estado depende del tipo de balanceador de cargas:

  • Un balanceador de cargas HTTP(S) externo muestra respuestas HTTP 502 a los clientes cuando ninguno de los backends está en buen estado.

  • Un balanceador de cargas HTTP(S) interno muestra respuestas HTTP 503 a los clientes cuando ninguno de los backends está en buen estado.

  • Los balanceadores de cargas de proxy SSL y los balanceadores de cargas de proxy TCP caducan cuando ninguno de los backends está en buen estado.

  • Un balanceador de cargas de red intenta distribuir el tráfico a todas las VM de backend cuando no están en buen estado como último recurso.

  • Un balanceador de cargas TCP/UDP interno sin una configuración de conmutación por error distribuye el tráfico a todas las VM de backend cuando no están en buen estado como último recurso. Puedes inhabilitar este comportamiento si habilitas la conmutación por error.

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 utiliza rutas especiales fuera de tu red de VPC, pero dentro de la red de producción de Google para facilitar la comunicación de los sistemas de sondeo.

  • Google utiliza los rangos de IP del sondeo exclusivamente para ejecutar sondeos de verificación de estado y enviar tráfico de Google Front End (GFE) a los balanceadores de cargas HTTP(S), los balanceadores de cargas de proxy SSL y los balanceadores de cargas de proxy TCP. Si se recibe un paquete de Internet, incluida la dirección IP externa de una instancia de Compute Engine o un nodo de Google Kubernetes Engine (GKE), y la dirección IP de origen del paquete se encuentra dentro del rango de IP de un sondeo, Google descarta el paquete.

  • Los rangos de IP del sondeo son un conjunto completo de direcciones IP posibles que utilizan 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 del sondeo. Como práctica recomendada, crea reglas de firewall de entrada allow para el balanceador de cargas elegido con todos los rangos de IP del sondeo como fuentes, ya que Google Cloud puede implementar nuevos sistemas de sondeo automáticamente sin notificación.

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 simultáneamente 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 de intervalo y 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 consideras los siguientes factores:

  • Considera los siguientes factores para estimar la frecuencia de sondeo por servicio de backend:

    • Frecuencia base por servicio de backend. Cada verificación de estado tiene una frecuencia de verificación asociada, 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 base que usa cada sistema de sondeo para los backends en ese servicio de backend.

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

  • Varias reglas de reenvío para balanceadores de cargas TCP/UDP internos. 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 utiliza 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. Si configuraste varias reglas de reenvío que apuntan al mismo grupo de destino, Google Cloud utiliza varios sistemas de sondeo para verificar cada dirección IP. La frecuencia de sondeo que ve cada instancia en el grupo de destino se multiplica por la cantidad de reglas de reenvío configuradas.

  • Varios proxies de destino para balanceadores de cargas HTTP(S) externos. Si configuraste varios proxies de destino que dirigen el tráfico al mismo mapa de URL para el balanceo de cargas HTTP(S) externo, Google Cloud utiliza varios sistemas de sondeo a fin de 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 proxy SSL y balanceadores de cargas de proxy TCP. Si configuraste varios proxies de destino que dirigen el tráfico al mismo servicio de backend para el balanceo de cargas de proxy SSL o el balanceo de cargas de proxy TCP, 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.

  • Suma sobre servicios de backend. Si varios servicios de backend usan un backend (como un grupo de instancias), 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, y 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 qué interfaz de red y direcciones IP de destino utilizan los sistemas de sondeo de verificación de estado según el tipo de balanceador de cargas.

Balanceador de cargas Interfaz de la red de destino Dirección IP de destino
Balanceo de cargas TCP/UDP interno La interfaz de red de la instancia ubicada en la red especificada para el servicio de backend interno. Si no se especifica, se utiliza la interfaz de red principal (nic0).

Para obtener más información, consulta este artículo sobre los servicios de backend y las interfaces de red.
La dirección IP de la regla de reenvío interna.

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.
Balanceo de cargas de red Interfaz de red principal (nic0) La dirección IP de la regla de reenvío externa.

Si hay varias reglas de reenvío que apuntan al mismo grupo de destino, 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.
Balanceo de cargas HTTP(S) externo

Balanceo de cargas HTTP(S) interno

Balanceo de cargas de proxy SSL

Balanceo de cargas de proxy TCP

Interfaz de red principal (nic0)
  • Para backends de grupo de instancias, la dirección IP interna principal asociada con la interfaz de red principal (nic0) de cada instancia.
  • Para backends de NEG zonales, la dirección IP del extremo, que es una dirección IP interna principal o un rango de alias de IP (de la interfaz de red principal, nic0, en la instancia que aloja el extremo).

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 respuesta HTTP 200 (OK) antes de que se agote el tiempo de espera del sondeo. Además, puedes seguir estos pasos:

  • 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 dentro de los primeros 1,024 bytes de la respuesta HTTP.

  • Si configuras una string de respuesta esperada, cada sondeo de verificación de estado de Google Cloud deberá encontrar la string de respuesta esperada dentro de los primeros 1,024 bytes de la respuesta real de tus backends.

Las siguientes combinaciones de ruta de solicitud y marcas de string de respuesta están disponibles para las verificaciones de estado que usan 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, /. La opción request-path no admite parámetros de consulta.
Respuesta
response
La marca de respuesta opcional te permite configurar una verificación de estado basada en 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 dentro de los primeros 1,024 bytes de la respuesta, además de recibir el estado HTTP 200 (OK).

Criterios de éxito para SSL y TCP

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

  • Cada sistema de sondeo de Google Cloud puede completar correctamente un protocolo de enlace SSL o TCP antes del tiempo de espera configurado para el sondeo.
  • Para las verificaciones de estado de TCP, el backend o el sistema de sondeo de Google Cloud finalizan correctamente la sesión de TCP, o tu backend envía un paquete de TCP RST (reset) mientras la sesión de TCP para el sistema de sondeo aún está establecida.

Ten en cuenta que el sondeo podría considerarse con errores 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 después de que el sistema de sondeo de Google Cloud inicie correctamente la finalización 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 solo es exitoso si se cumplen las condiciones básicas y si la string de respuesta que se muestra coincide exactamente con la string de respuesta esperada.

Las siguientes combinaciones de marcas de solicitud y 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 es exitoso 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 por la string de respuesta esperada. Google Cloud considera que el sondeo es exitoso cuando se cumplen las condiciones básicas y cuando la string de respuesta que se muestra coincide exactamente con la string de respuesta esperada.
Solo la respuesta especificada

Marcas especificadas: solo --response
Google Cloud aguarda por la string de respuesta esperada y considera que el sondeo es exitoso cuando se cumplen las condiciones básicas y cuando la string de respuesta que se muestra coincide exactamente con la string de respuesta esperada.

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

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

Estado

Google Cloud utiliza las siguientes marcas de configuración para determinar el estado general de cada uno de los backend a los que se aplica el balanceo de cargas.

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 exitosos para que se considere que un backend está en buen estado. Si se omite, Google Cloud utilizará 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. Si se omite, Google Cloud utilizará 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. El comportamiento específico difiere según el tipo de balanceador de cargas que uses.

Las conexiones existentes pueden no mostrar respuestas según la causa de falla del sondeo. Un backend en mal estado puede revertirse si es capaz de alcanzar el umbral de buen estado otra vez.

Notas adicionales

Verificaciones de estado basadas en 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. Utiliza 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, opcionalmente, define una ruta de solicitud. A fin de obtener más detalles, consulta este artículo sobre los 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, opcionalmente, define una string de solicitud. A fin de obtener más detalles, consulta este artículo sobre los 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 realizan la validación de certificados, incluso para protocolos que requieren que tus backends usen certificados (SSL, HTTPS y HTTP/2), por ejemplo:

  • Puedes usar certificados autofirmados o certificados firmados por cualquier autoridad certificada (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.

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 simultáneamente 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 Sondeos múltiples y frecuencia.
  2. Cada sistema de sondeo de verificación de estado realiza lo siguiente:

    1. Inicia una conexión HTTP de una de las direcciones IP de origen a la instancia de backend cada 30 segundos.
    2. Espera hasta cinco segundos por un código de respuesta HTTP 200 (OK) (los 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 esta 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 exista un 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, independientemente de 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 el tiempo de espera nunca incrementa 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.

Próximos pasos