Descripción general de las comprobaciones del estado (original) (raw)

Google Cloud ofrece comprobaciones de estado configurables para los backends de Google Cloud balanceadores de carga, los backends de Cloud Service Mesh y la autorreparación basada en aplicaciones para grupos de instancias gestionados. En este documento se explican los conceptos clave de las comprobaciones de estado.

A menos que se indique lo contrario,las Google Cloud comprobaciones del estado se implementan mediante tareas de software específicas que se conectan a los backends según los parámetros especificados en un recurso de comprobación del estado. Cada intento de conexión se denomina sondeo. Google Cloud registra si cada sondeo se ha realizado correctamente o no.

En función de un número configurable de sondeos correctos o fallidos consecutivos, se calcula un estado de salud general para cada backend. Los backends que responden correctamente el número de veces configurado se consideran en buen estado. Los back-ends que no responden correctamente un número de veces configurable por separado se consideran no aptos.

El estado general de cada backend determina si puede recibir nuevas solicitudes o conexiones. Puede configurar los criterios que definen una prueba correcta. Este tema se trata en detalle en la sección Cómo funcionan las comprobaciones de estado.

Las comprobaciones de estado implementadas por tareas de software específicas usan rutas especiales que no están definidas en tu red de nube privada virtual (VPC). Para obtener más información, consulta Rutas de las comprobaciones del estado.

Categorías, protocolos y puertos de comprobación del estado

Las comprobaciones de estado tienen una categoría y un protocolo. Las dos categorías son comprobaciones del estado y comprobaciones del estado antiguas, y sus protocolos admitidos son los siguientes:

• Comprobaciones del estado
  • Regional (gRPC, TCP, SSL, HTTP, HTTPS o HTTP/2)
  • gRPC regional (con TLS) (vista previa)
  • Global (gRPC, TCP, SSL, HTTP, HTTPS o HTTP/2)
  • gRPC global (con TLS) (vista previa)
• Comprobaciones del estado antiguas:
  • Global antiguo (HTTP)
  • Global antiguo (HTTPS)

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

No puedes convertir una comprobación del estado antigua en una comprobación del estado ni viceversa.

Seleccionar una comprobación del estado

Las comprobaciones del estado deben ser compatibles con el tipo de balanceador de carga (o Cloud Service Mesh) y los tipos de backend. A la hora de seleccionar una comprobación de estado, debes tener en cuenta los siguientes factores:

• Categoría: comprobación del estado o comprobación del estado antigua. Solo los balanceadores de carga de red de paso a través externos basados en grupos de destino requieren comprobaciones de estado antiguas. En el resto de los productos, utilizarás comprobaciones de estado normales.
• Protocolo: protocolo que usa Google Cloud para sondear los backends. Es mejor usar una comprobación del estado (o una comprobación del estado antigua) cuyo protocolo coincida con el protocolo que usa el servicio de backend o el grupo de destino del balanceador de carga. Sin embargo, los protocolos de comprobación del estado y los protocolos del balanceador de carga no tienen que ser los mismos.
• Especificación de puerto: puertos que usa Google Cloud con el protocolo. Debes especificar un puerto para la comprobación del estado. Las comprobaciones de estado tienen dos métodos de especificación de puertos: --port y --use-serving-port. En el caso de las comprobaciones de estado antiguas, solo hay un método: --port. Para obtener más información sobre los requisitos de los puertos de comprobación del estado por balanceador de carga, consulta las marcas de especificación de puertos.

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

Guía del balanceador de carga

En esta tabla se muestran la categoría y el ámbito de comprobación de estado admitidos para cada tipo de balanceador de carga.

*En el caso de los balanceadores de carga de aplicación externos, no se recomiendan las comprobaciones de estado antiguas, pero a veces se admiten, en función del modo del balanceador de carga.

Notas de uso adicionales

• En el caso de los grupos de instancias de backend, los NEG zonales con GCE_VM_IP endpoints y los NEG zonales con GCE_VM_IP_PORT endpoints, los verificadores solo intentan conectarse a instancias de VM (o a instancias de VM que contengan endpoints) si las VMs están en ejecución. Los verificadores no intentan conectarse a instancias (o instancias de VM que contengan endpoints) si están detenidas.
• Un balanceador de carga de red de paso a través externo basado en un grupo de destino debe usar una comprobación de estado HTTP antigua. No puede usar una comprobación del estado de HTTPS antigua ni ninguna comprobación del estado no antigua. Si usas un balanceador de carga de red de transferencia externo basado en un grupo de destino para balancear el tráfico TCP, debes ejecutar un servicio HTTP en las VMs que se están balanceando para que puedan responder a las sondas de comprobación del estado.
  En el caso de casi todos los demás tipos de balanceadores de carga, debes usar comprobaciones de estado normales (no antiguas) en las que el protocolo coincida con el protocolo del servicio de backend del balanceador de carga.
• En el caso de los servicios de backend que usan el protocolo gRPC, utilice solo comprobaciones de estado de gRPC o TCP. No uses comprobaciones de estado HTTP(S) ni HTTP/2.
• Algunos balanceadores de carga basados en Envoy que usan back-ends de NEG híbridos no admiten comprobaciones de estado de gRPC. Para obtener más información, consulta la descripción general de los NEGs híbridos.

Comprobación del estado con Cloud Service Mesh

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

• Con Cloud Service Mesh, el comportamiento de la comprobación del estado de los puntos finales de red de los tipos INTERNET_FQDN_PORT y NON_GCP_PRIVATE_IP_PORT es diferente del de otros tipos de puntos finales de red. En lugar de usar las tareas de software específicas, Cloud Service Mesh programa proxies de Envoy para realizar comprobaciones de estado de NEGs de Internet (puntos finales INTERNET_FQDN_PORT) y NEGs híbridos (puntos finales NON_GCP_PRIVATE_IP_PORT).
  Envoy admite los siguientes protocolos para las comprobaciones de estado:
  • HTTP
  • HTTPS
  • HTTP/2
  • TCP
• Cuando Cloud Service Mesh se integra con Service Directory y vinculas un servicio de Service Directory a un servicio de backend de Cloud Service Mesh, no puedes definir una comprobación de estado en el servicio de backend.

Cómo funcionan las comprobaciones del estado

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

Comprobaciones

Cuando creas una comprobación de estado o una comprobación de estado antigua, especificas las siguientes marcas o aceptas sus valores predeterminados. Cada comprobación del estado o comprobación del estado antigua que crees se implementa mediante varias sondas. Estas marcas controlan la frecuencia con la que _cada_prueba evalúa las instancias de los grupos de instancias o los endpoints de los NEGs de zona.

Los ajustes de una comprobación de estado no se pueden configurar por backend. Las comprobaciones de estado se asocian a un servicio de backend completo. En el caso de un balanceador de carga de red de paso a través externo basado en grupos de destino, se asocia una comprobación del estado HTTP antigua a todo el grupo de destino. Por lo tanto, los parámetros de la sonda son los mismos para todos los backends a los que hace referencia un servicio de backend o un grupo de destino determinado.

Intervalos de IP y reglas de cortafuegos de sondeos

Para que las comprobaciones de estado funcionen, debes crear reglas de cortafuegos de entrada allow para que el tráfico de los Google Cloud probers pueda conectarse a tus backends. Para obtener instrucciones, consulta el artículo Crear reglas de cortafuegos obligatorias.

En la siguiente tabla se muestran los intervalos de IPs de origen que se deben permitir para cada balanceador de carga:

1No es necesario permitir el tráfico de los intervalos de sondeo de comprobación del estado de Google para los NEGs híbridos. Sin embargo, si utilizas una combinación de NEGs híbridos y zonales en un mismo servicio de backend, debes permitir el tráfico de los intervalos de sondeo de comprobación de estado de Google para los NEGs zonales.

2En el caso de los NEGs de Internet regionales, las comprobaciones del estado son opcionales. El tráfico de los balanceadores de carga que usan NEGs de Internet regionales procede de la subred solo de proxy y, a continuación, se traduce mediante NAT (con Cloud NAT) a direcciones IP de NAT asignadas de forma manual o automática. Este tráfico incluye tanto las comprobaciones del estado como las solicitudes de los usuarios del balanceador de carga a los backends. Para obtener más información, consulta NEGs regionales: usar una pasarela de Cloud NAT.

3 Los balanceadores de carga de red de paso a través externos basados en grupos de destino solo admiten tráfico IPv4 y pueden proxy las comprobaciones de estado a través del servidor de metadatos. En este caso, las fuentes de paquetes de comprobación del estado coinciden con la dirección IP del servidor de metadatos: 169.254.169.254. No es necesario que cree reglas de cortafuegos para permitir el tráfico del servidor de metadatos. Los paquetes del servidor de metadatos siempre están permitidos.

Consideraciones de seguridad para los intervalos de IPs de sondeo

Ten en cuenta la siguiente información al planificar las comprobaciones de estado y las reglas de cortafuegos necesarias:

• Los intervalos de IP de las sondas pertenecen a Google. Google Cloud usa rutas especiales fuera de tu red de VPC, pero dentro de la red de producción de Google, para comunicarse entre las sondas de comprobación de estado y las máquinas virtuales de backend.
• Los intervalos de IPs de sondeo se usan exclusivamente en la red de producción de Google para comprobaciones de estado y balanceo de carga. Google Cloud La red de producción de Google impide que los intervalos de IPs de sondeo se usen para cualquier otro fin aplicando lo siguiente:
  • Los routers perimetrales de Google descartan los paquetes de Internet si estos falsifican las direcciones IP de origen de un intervalo de IPs de sondeo.
  • No puedes usar los intervalos de IPs de las sondas en las subredes de tus redes de VPC. Para obtener más información, consulta los intervalos de subredes IPv4 prohibidos y las especificaciones de IPv6.

Importancia de las reglas de cortafuegos

Google Cloud requiere que crees las reglas de cortafuegos de entrada allownecesarias para permitir el tráfico de los verificadores a tus backends:

• Los intervalos de IP de las sondas son un conjunto completo de direcciones IP posibles que usan las sondas deGoogle Cloud . Si usas tcpdump o una herramienta similar, es posible que no veas el tráfico de todas las direcciones IP de todos los intervalos de IPs de sondeo. Como práctica recomendada, cree reglas de cortafuegos de entrada que permitan todos los intervalos de IPs de la sonda como fuentes. Google Cloud puede implementar nuevas sondas automáticamente sin notificación.
• Como práctica recomendada, limita estas reglas a los protocolos y puertos que coincidan con los que usan tus comprobaciones de estado.

Si no tienes reglas de cortafuegos de entrada allow que permitan la comprobación del estado, la regla de entrada deny implícita bloquea el tráfico entrante. Cuando los verificadores no pueden ponerse en contacto con tus backends, el balanceador de carga considera que estos no están en buen estado.

Varias sondas y frecuencia

Google Cloud Envía sondeos de comprobación de estado desde varios sistemas redundantes llamados "sondas". Los verificadores usan intervalos de IPs de origen específicos. Google Cloud no se basa en un solo verificador para implementar una comprobación de estado: varios verificadores evalúan simultáneamente las instancias de los backends de grupos de instancias o los endpoints de los backends de NEGs zonales. Si falla una sonda, Google Cloud sigue monitorizando el estado de los back-ends.

Los ajustes de intervalo y de tiempo de espera que configures para una comprobación de estado se aplican a cada comprobador. En un backend determinado, los registros de acceso al software y tcpdump muestran sondeos más frecuentes que los ajustes configurados.

Es un comportamiento esperado y no puedes configurar el número de sondas que Google Cloud usa para las comprobaciones del estado. Sin embargo, puedes estimar el efecto de varias sondas simultáneas teniendo en cuenta los siguientes factores.

• Para estimar la frecuencia de las sondas por servicio de backend, ten en cuenta lo siguiente:
  • Frecuencia base por servicio de backend. Cada comprobación del estado tiene una frecuencia de comprobación asociada, que es inversamente proporcional al intervalo de comprobación configurado:
    1/(intervalo de comprobación)
    Cuando asocias una comprobación del estado a un servicio de backend, estableces una frecuencia base que usa cada comprobador para los backends de ese servicio de backend.
  • Factor de escala de la sonda. La frecuencia base del servicio de backend se multiplica por el número de sondas simultáneas que usa Google Cloud . Este número puede variar, pero suele estar entre 5 y 10.
• Varias reglas de reenvío para balanceadores de carga de red de paso a través internos. Si has configurado 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 verificadores para comprobar cada dirección IP. La frecuencia de la sonda por servicio de backend se multiplica por el número de reglas de reenvío configuradas.
• Varias reglas de reenvío para balanceadores de carga de red de paso a través externos. Si has configurado varias reglas de reenvío que apuntan al mismo servicio de backend o al mismo grupo de destino, Google Cloud se usan varios verificadores para comprobar cada dirección IP. La frecuencia de la sonda por VM de backend se multiplica por el número de reglas de reenvío configuradas.
• **Varios proxies de destino para balanceadores de carga de aplicación externos.**Si tienes varios proxies de destino que dirigen el tráfico al mismo mapa de URLs, Google Cloud usa varios verificadores para comprobar la dirección IP asociada a cada proxy de destino. La frecuencia de las sondas por servicio de backend se multiplica por el número de proxies de destino configurados.
• **Varios proxies de destino para balanceadores de carga de red de proxy externo y balanceadores de carga de red de proxy interno regional.**Si has configurado varios proxies de destino que dirigen el tráfico al mismo servicio de backend,Google Cloud utiliza varios verificadores para comprobar la dirección IP asociada a cada proxy de destino. La frecuencia de la sonda por servicio de backend se multiplica por el número de proxies de destino configurados.
• Suma de los servicios de backend. Si varios servicios de backend usan un backend, se contacta con las instancias del backend con la misma frecuencia que la suma de las frecuencias de la comprobación de estado de cada servicio de backend.
  Con los back-ends de NEG zonales, es más difícil determinar el número exacto de sondeos de comprobación de estado. Por ejemplo, el mismo endpoint puede estar en varios NEG zonales. Esos NEGs zonales no tienen necesariamente el mismo conjunto de endpoints y diferentes endpoints pueden apuntar al mismo backend.

Destino de los paquetes de sondeo.

En la siguiente tabla se muestran la interfaz de red y las direcciones IP de destino a las que envían paquetes los verificadores de comprobación del estado, en función del tipo de balanceador de carga.

En el caso de los balanceadores de carga de red de paso a través externos e internos, la aplicación debe enlazarse a la dirección IP del balanceador de carga (o a cualquier dirección IP 0.0.0.0).

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

Las comprobaciones del estado de HTTP, HTTPS y HTTP/2 siempre requieren que se reciba un código de respuesta HTTP 200 (OK) antes de que se agote el tiempo de espera de la comprobación del estado. Todos los demás códigos de respuesta HTTP, incluidos los códigos de respuesta de redirección, como 301 y 302, se consideran no saludables.

Además de requerir un código de respuesta HTTP 200 (OK), puedes hacer lo siguiente:

• Configura cada comprobador de estado para que envíe solicitudes HTTP a una ruta de solicitud específica en lugar de a la ruta de solicitud predeterminada, /.
• Configura cada comprobador de estado para que compruebe si hay una cadena de respuesta esperada en el cuerpo de la respuesta HTTP. La cadena de respuesta esperada solo debe contener caracteres ASCII imprimibles de un byte, que se encuentren en los primeros 1024 bytes del cuerpo de la respuesta HTTP.

En la siguiente tabla se muestran las combinaciones válidas de ruta de solicitud y marcas de respuesta que están disponibles para las comprobaciones de estado HTTP, HTTPS y HTTP/2.

Criterios de éxito de SSL y TCP

Las comprobaciones del estado de TCP y SSL tienen los siguientes criterios de éxito básicos:

• En el caso de las comprobaciones de estado de TCP, un comprobador de estado debe abrir correctamente una conexión TCP con el backend antes de que se agote el tiempo de espera de la comprobación de estado.
• En el caso de las comprobaciones de estado de SSL, un comprobador de estado debe abrir correctamente una conexión TCP con el backend y completar el handshake de TLS/SSL antes de que se agote el tiempo de espera de la comprobación de estado.
• En el caso de las comprobaciones de estado TCP, la conexión TCP debe cerrarse de una de las siguientes formas:
  • El verificador de comprobación de estado envía un paquete FIN o RST (restablecimiento).
  • El backend envía un paquete FIN. Si un backend envía un paquete TCP RST, puede que la sonda se considere fallida si el comprobador de estado ya ha enviado un paquete FIN.

En la siguiente tabla se indican las combinaciones válidas de marcas de solicitud y respuesta que están disponibles para las comprobaciones de estado de TCP y SSL. Las marcas de solicitud y respuesta solo pueden contener caracteres ASCII imprimibles de un byte. La longitud de cada cadena no puede superar los 1024 caracteres.

Criterios de éxito de gRPC

Las comprobaciones de estado de gRPC solo se usan con aplicaciones gRPC, Google Cloud balanceadores de carga y Cloud Service Mesh. Google Cloud admite dos tipos de comprobaciones de estado de gRPC:

• Las comprobaciones de estado GRPC_WITH_TLS se usan para comprobar el estado de los back-ends de gRPC con TLS habilitado. Admiten el cifrado TLS no autenticado, lo que significa que las comprobaciones de estado no verifican la identidad del servidor.
• Las comprobaciones del estado GRPC se usan para comprobar el estado de los backends de gRPC no seguros. No admiten la autenticación ni el cifrado, por lo que no se pueden usar en back-ends de gRPC con TLS habilitado.

Si usas comprobaciones de estado de gRPC (con o sin TLS), asegúrate de que el servicio gRPC envíe la respuesta RPC con el estado OK y el campo de estado definido como SERVING o NOT_SERVING, según corresponda.

Para obtener más información, consulta las siguientes secciones:

• Marca adicional para comprobaciones de estado de gRPC
• Documentación de gRPC sobre comprobaciones de estado

Criterios de éxito de las comprobaciones del estado antiguas

Si la respuesta recibida por la sonda de comprobación del estado antigua es HTTP 200 OK, se considera que la sonda se ha realizado correctamente. Todos los demás códigos de respuesta HTTP, incluida una redirección (301, 302), se consideran incorrectos.

Estado de salud

Google Cloud usa las siguientes marcas de configuración de umbral de estado correcto y incorrecto para determinar el estado general de cada backend al que se balancea la carga del tráfico.

El comportamiento específico cuando todas las back-ends no están en buen estado varía en función del tipo de balanceador de carga que utilice:

Notas adicionales

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

Certificados y comprobaciones del estado

Los verificadores de estado deGoogle Cloud no validan los certificados, ni siquiera en los 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 de certificación (AC).
• Se aceptan certificados que hayan caducado o que aún no sean válidos.
• No es necesario que los atributos CN ni subjectAlternativeName coincidan con un registro PTR de DNS o encabezado Host.

Las comprobaciones del estado que usan cualquier protocolo, excepto las antiguas, te permiten definir un encabezado de proxy mediante la marca --proxy-header.

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

Si usas encabezados de solicitud personalizados, ten en cuenta que el balanceador de carga añade estos encabezados solo a las solicitudes de los clientes, no a las sondas de comprobación del estado. Si tu backend requiere un encabezado específico para la autorización que falta en el paquete de comprobación del estado, es posible que la comprobación del estado falle.

Comprobación del estado de ejemplo

Supongamos que configura una comprobación de estado con los siguientes ajustes:

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

Con estos ajustes, la comprobación de estado se comporta de la siguiente manera:

1. Se configuran simultáneamente varios sistemas redundantes con los parámetros de comprobación del estado. Los ajustes de intervalo y de tiempo de espera se aplican a cada sistema. Para obtener más información, consulta Varias sondas y frecuencia.
2. Cada comprobador de estado hace lo siguiente:
   1. Inicia una conexión HTTP desde una de las direcciones IP de origen a la instancia de backend cada 30 segundos.
   2. Espera hasta cinco segundos para obtener un código de estado 200 (OK) HTTP (el criterio de éxito de los protocolos HTTP, HTTPS y HTTP/2).
3. Un backend se considera en mal estado cuando al menos una sonda de comprobación del estado del sistema hace lo siguiente:
   1. No recibe un código de respuesta HTTP 200 (OK) en dos sondeos consecutivos. Por ejemplo, puede que se rechace la conexión o que se agote el tiempo de espera de la conexión o del socket.
   2. Recibe dos respuestas consecutivas que no cumplen los criterios de éxito específicos del protocolo.
4. Se considera que un backend está en buen estado cuando al menos un sistema de comprobación de estado recibe dos respuestas consecutivas que coinciden con los criterios de éxito específicos del protocolo.

En este ejemplo, cada prober inicia una conexión cada 30 segundos. Transcurren 30 segundos entre los intentos de conexión de un comprobador, independientemente de la duración del tiempo de espera (tanto si la conexión se ha agotado como si no). En otras palabras, el tiempo de espera siempre debe ser inferior o igual al intervalo, y nunca lo aumenta.

En este ejemplo, los tiempos de cada sonda son los siguientes (en segundos):

1. t=0: inicia la sonda A.
2. t=5: detiene la sonda A.
3. t=30: inicia la sonda B.
4. t=35: detiene la comprobación B.
5. t=60: inicia la comprobación C.
6. t=65: detiene la sonda C.

Siguientes pasos

• Para crear, modificar y usar comprobaciones del estado, consulta Usar comprobaciones del estado.
• Para solucionar problemas de las comprobaciones del estado, habilita el registro de comprobaciones del estado.