Google Cloud ofrece verificaciones de estado configurables para los backends de Google Cloud balanceador de cargas, 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, Google Cloud las verificaciones de estado se implementan mediante tareas de software dedicadas que se conectan a los backends según 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:
Verificaciones de estado
Verificaciones de estado heredadas
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 regionales basados en grupos de destino requieren verificaciones de estado heredadas. Para todos los demás productos, usarás verificaciones de estado normales.
- 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:
--porty--use-serving-port. En las verificaciones de estado heredadas, hay un método:--port. Para obtener más información sobre los requisitos de puertos de verificación de estado por balanceador de cargas, consulta Marcas de especificación de puertos.
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 y el alcance de la verificación de estado admitidos para cada tipo de 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:
|
| Balanceador de cargas de aplicaciones externo regional | No |
Notas de uso adicionales
En el caso de los grupos de instancias de backend, los NEG zonales con extremos
GCE_VM_IPy los NEG zonales con extremosGCE_VM_IP_PORT, los verificadores solo intentan conectarse a instancias de VM (o instancias de VM que contienen extremos) si las VMs están en ejecución. Los verificadores no intentan conectarse a instancias (o instancias de VM que contienen extremos) si están detenidas.Un balanceador de cargas de red de transferencia externo regional 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 regional 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_PORTyNON_GCP_PRIVATE_IP_PORTdifiere 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 (extremosINTERNET_FQDN_PORT) y NEG híbridos (extremosNON_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.
Rangos de IP del sondeo
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 o a otros recursos. Ten en cuenta lo siguiente cuando crees estas reglas de firewall:
Los rangos de IP de sondeo son un conjunto completo de direcciones IP posibles que utilizan los sistemas de sondeo deGoogle Cloud . Si usas
tcpdumpo 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 nuevos sistemas de sondeo automáticamente sin notificación.Como práctica recomendada, limita estas reglas solo a los protocolos y puertos que coincidan con los que usan tus verificaciones de estado.
Si no tienes reglas de firewall de entrada allow que permitan que los verificadores de estado se conecten a los backends del balanceador de cargas, la acción de firewall de entrada de denegación implícita bloquea el tráfico, lo que provoca que los backends no estén en buen estado. Para obtener más información, consulta Políticas y reglas de firewall.
Rangos de IP de sondeo para backends de balanceador de cargas basados en GFE
Los balanceadores de cargas de aplicaciones externos y los balanceadores de cargas de red de proxy externos que usan Google Front End (GFE) son los siguientes:
- Balanceadores de cargas de aplicaciones externos globales
- Balanceadores de cargas de aplicaciones clásicos
- Balanceadores de cargas de red del proxy externo global
- Balanceadores de cargas de red del proxy clásicos
Las verificaciones de estado de los backends de estos balanceadores de cargas provienen de los rangos de direcciones IP que se indican en la siguiente tabla:
| Tipo de backend | Rangos de IP de origen de los sondeos de verificación de estado |
|---|---|
|
Para las verificaciones de estado de IPv4 a los backends, haz lo siguiente:
Para las verificaciones de estado de IPv6 a los backends, haz lo siguiente:
|
|
No aplicable (estos backends no admiten verificaciones de estado) |
Rangos de IP de sondeo para los backends de Cloud Service Mesh
Las verificaciones de estado de los backends de Cloud Service Mesh provienen de los rangos de direcciones IP que se indican en la siguiente tabla:
| Tipo de backend | Rangos de IP de origen de los sondeos de verificación de estado |
|---|---|
|
Para las verificaciones de estado de IPv4 a los backends, haz lo siguiente:
Para las verificaciones de estado de IPv6 a los backends, haz lo siguiente:
|
|
Verificaciones de estado distribuidas de Envoy desde las direcciones IP de tus proxies de Envoy autoadministrados |
Rangos de IP de sondeo para backends de balanceador de cargas administrados basados en Envoy
Los balanceadores de cargas de aplicaciones y los balanceadores de cargas de red de proxy que usan proxies de Envoy administrados son los siguientes:
Balanceadores de cargas de aplicaciones regionales externos
Balanceadores de cargas de aplicaciones internos regionales
- Balanceadores de cargas de aplicaciones internos entre regiones
Balanceadores de cargas de red del proxy externos regionales
Balanceadores de cargas de red de proxy internos regionales
- Balanceadores de cargas de red de proxy internos entre regiones
Las verificaciones de estado de los backends de estos balanceadores de cargas provienen de los rangos de direcciones IP que se indican en la siguiente tabla:
| Tipo de backend | Rangos de IP de origen de los sondeos de verificación de estado |
|---|---|
|
Para las verificaciones de estado de IPv4 a los backends, haz lo siguiente:
Para las verificaciones de estado de IPv6 a los backends, haz lo siguiente:
|
|
Verificaciones de estado distribuidas de Envoy desde las direcciones IP de la subred de solo proxy |
|
No aplicable (estos backends no admiten verificaciones de estado) |
Rangos de IP de sondeo para frontends de balanceador de cargas administrados basados en Envoy seleccionados
Los siguientes balanceadores de cargas de aplicaciones y balanceadores de cargas de red de proxy usan proxies de Envoy administrados y también admiten reglas de firewall que controlan el acceso a los proxies de Envoy administrados:
- Balanceadores de cargas de aplicaciones internos regionales
- Balanceadores de cargas de aplicaciones internos entre regiones
- Balanceadores de cargas de red de proxy internos regionales
- Balanceadores de cargas de red de proxy internos entre regiones
Para obtener más información sobre esta opción, consulta Usa políticas de firewall de red regionales para proteger los balanceadores de cargas de aplicaciones internos y los balanceadores de cargas de red de proxy internos.
Si decides crear reglas de firewall de permiso de entrada y denegación de entrada para controlar el acceso a una regla de reenvío de uno de estos balanceadores de cargas, debes crear reglas de firewall de permiso de entrada para permitir que los sistemas de Google supervisen el estado de los proxies de Envoy administrados.
Para las verificaciones de estado de IPv4 en la regla de reenvío, haz lo siguiente:
35.191.0.0/16
Para las verificaciones de estado de IPv6 en la regla de reenvío:
2600:2d00:1:b029::/64
Las verificaciones de estado que usa Google para supervisar los proxies de Envoy administrados son un detalle de implementación interno, no una verificación de estado que el usuario puede configurar.
Rangos de IP de sondeo para los backends del balanceador de cargas de red de transferencia
Las verificaciones de estado de los backends de los balanceadores de cargas de red de transferencia provienen de los rangos de direcciones IP que se indican en la siguiente tabla:
| Tipo de balanceador de cargas y backend | Rangos de IP de origen de los sondeos de verificación de estado |
|---|---|
Balanceadores de cargas de red de transferencia externos globales que usan uno de los siguientes backends:
|
Para las verificaciones de estado de IPv4 a los backends, haz lo siguiente:
Para las verificaciones de estado de IPv6 a los backends, haz lo siguiente:
|
Balanceadores de cargas de red de transferencia externos regionales que usan uno de los siguientes backends1:
|
Para las verificaciones de estado de IPv4 a los backends, haz lo siguiente:
Para las verificaciones de estado de IPv6 a los backends, haz lo siguiente:
|
Balanceadores de cargas de red de transferencia internos que usan uno de los siguientes backends:
|
Para las verificaciones de estado de IPv4 a los backends, haz lo siguiente:
Para las verificaciones de estado de IPv6 a los backends, haz lo siguiente:
|
1 Los balanceadores de cargas de red de transferencia externos 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.
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 balanceador de cargas de red de transferencia externo regional 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óncheck-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 esperatimeout |
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) |
Consideraciones de seguridad para los rangos de IP de sondeo
Considera la siguiente información cuando planifiques las verificaciones de estado y las reglas de firewall necesarias:
Los rangos de IP de sondeo 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 la comunicación entre los sistemas de sondeo de verificación de estado y las VMs de backend.
Los rangos de IP de sondeo se usan exclusivamente dentro de la red de producción de Google para la verificación de estado y el balanceo de cargas. Google Cloud y la red de producción de Google evitan que los rangos de IP de sondeo se usen para cualquier otro propósito, ya que aplican lo siguiente:
Los routers perimetrales de Google descartan los paquetes de Internet si estos suplantan direcciones IP de origen de un rango de IP de sondeo.
No puedes usar los rangos de IP de sondeo para las subredes en tus redes de VPC. Para obtener más información, consulta Rangos de subredes IPv4 prohibidos y Especificaciones de IPv6.
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:
Los rangos de IP de sondeo son un conjunto completo de direcciones IP posibles que utilizan los sistemas de sondeo deGoogle Cloud . Si usas
tcpdumpo 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 nuevos sistemas de sondeo automáticamente sin notificación.Como práctica recomendada, limita estas reglas solo a los protocolos y puertos que coincidan con los que usan tus verificaciones de estado.
Si no tienes reglas de firewall de entrada allow que permitan la verificación de estado, la regla de entrada deny implícita bloquea el tráfico entrante. Cuando los verificadores no pueden comunicarse con los backends, el balanceador de cargas los considera en mal estado.
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 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 Google Cloud usa 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 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. Si configuraste varias reglas de reenvío (con diferentes direcciones IP) que tienen el mismo grupo de instancias o NEG zonal como backend, Google Cloud utiliza varios sistemas de sondeo para verificar el estado de cada dirección IP en el backend. La frecuencia de sondeo en cada instancia de backend o extremo se multiplica por la cantidad de direcciones IP de reglas de reenvío únicas a las que presta servicio. Por ejemplo:
Si creas dos reglas de reenvío regionales del balanceador de cargas de red de transferencia externo con diferentes direcciones IP que apuntan al mismo servicio de backend, la frecuencia de sondeo en cada instancia de backend o extremo del servicio de backend se multiplica por 2.
Si creas un balanceador de cargas de red de transferencia externo global, un balanceador de cargas de red de transferencia externo regional y una regla de reenvío del balanceador de cargas de red de transferencia interno que comparten el mismo grupo de instancias como backend, la frecuencia de sondeo en cada instancia de backend del grupo de instancias se multiplica por 4. Esto se debe a que a una regla de reenvío del balanceador de cargas de red de transferencia externo global se le asignan dos direcciones IP y, por lo tanto, la frecuencia de sondeo de sus instancias o extremos de backend siempre es el doble de la frecuencia de verificación de estado configurada.
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, 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 |
|---|---|---|
|
|
|
|
|
|
|
Para los backends de grupo de instancias, la interfaz de red principal ( Para los backends de NEG zonales con extremos |
Son las direcciones IP asociadas a la regla de reenvío. Si configuras varias reglas de reenvío (con diferentes direcciones IP) que tienen el mismo grupo de instancias o NEG zonal como backend, Google Cloud utiliza varios sistemas de sondeo para verificar el estado de cada dirección IP, lo que aumenta la frecuencia de sondeo en cada instancia de backend o extremo del backend. Para obtener más información, consulta Varios sondeos y frecuencia. |
|
Es la interfaz de red en la red de VPC que coincide con la especificación de red del servicio de backend. |
Es la dirección IP asociada a la regla de reenvío. Si configuras varias reglas de reenvío (con diferentes direcciones IP) que tienen el mismo grupo de instancias o NEG zonal como backend, Google Cloud utiliza varios sistemas de sondeo para verificar el estado de cada dirección IP, lo que aumenta la frecuencia de sondeo en cada instancia de backend o extremo del backend. Para obtener más información, consulta Varios sondeos y frecuencia. |
Criterios de éxito para HTTP, HTTPS y HTTP/2
Las verificaciones de estado HTTP, HTTPS y HTTP/2 siempre requieren que se reciba un código de respuesta 200 (OK) HTTP antes de que se agote el tiempo de espera de la verificación de estado. Todos los demás códigos de respuesta HTTP, incluidos los códigos de respuesta de redireccionamiento, como 301 y 302, se consideran en mal estado.
Además de requerir un código de respuesta 200 (OK) HTTP, puedes hacer lo siguiente:
Configura cada sistema de sondeo de verificación de estado para que envíe solicitudes HTTP a una ruta de solicitud específica en lugar de la ruta de solicitud predeterminada,
/.Configura cada sistema de sondeo de verificación de estado para que compruebe la presencia de una cadena de respuesta esperada en el cuerpo de la respuesta HTTP. La cadena de respuesta esperada solo debe constar de caracteres ASCII imprimibles de un solo byte, ubicados dentro de los primeros 1,024 bytes del cuerpo de la respuesta HTTP.
En la siguiente tabla, se enumeran las combinaciones válidas de ruta de solicitud y marcas de respuesta que están disponibles para las verificaciones de estado de HTTP, HTTPS y HTTP/2.
| Marcas de configuración | Comportamiento de la sonda | Criterios para alcanzar el éxito |
|---|---|---|
No se especificaron --request-path ni --response.
|
El verificador usa / como ruta de solicitud. |
Solo el código de respuesta 200 (OK) HTTP. |
Se especificaron --request-path y --response
|
El verificador usa la ruta de acceso de la solicitud configurada. | El código de respuesta 200 (OK) HTTP y hasta los primeros 1,024 caracteres ASCII del cuerpo de la respuesta HTTP deben coincidir con la cadena de respuesta esperada. |
Solo se especificó --response
|
El verificador usa / como ruta de solicitud. |
El código de respuesta 200 (OK) HTTP y hasta los primeros 1,024 caracteres ASCII del cuerpo de la respuesta HTTP deben coincidir con la cadena de respuesta esperada. |
Solo se especificó --request-path
|
El verificador usa la ruta de acceso de la solicitud configurada. | Solo el código de respuesta 200 (OK) HTTP. |
Criterios de éxito para SSL y TCP
Las verificaciones de estado de TCP y SSL tienen los siguientes criterios de éxito básicos:
En el caso de las verificaciones de estado de TCP, un sistema de sondeo de verificación de estado debe abrir correctamente una conexión TCP al backend antes de que se agote el tiempo de espera de la verificación de estado.
En el caso de las verificaciones de estado SSL, un sistema de sondeo de verificación de estado debe abrir correctamente una conexión TCP al backend y completar el protocolo de enlace TLS/SSL antes de que se agote el tiempo de espera de la verificación de estado.
Para las verificaciones de estado de TCP, la conexión TCP debe cerrarse de una de las siguientes maneras:
- El sistema de sondeo de verificación de estado envía un paquete FIN o RST (reset).
- El backend envía un paquete FIN. Si un backend envía un paquete RST de TCP, es posible que el sondeo se considere incorrecto si el sistema de sondeo de verificación de estado ya envió un paquete FIN.
En la siguiente tabla, se enumeran las combinaciones válidas de marcas de solicitud y respuesta que están disponibles para las verificaciones de estado de TCP y SSL. Las marcas de solicitud y respuesta deben constar solo de caracteres ASCII imprimibles de un solo byte, y cada cadena no debe tener más de 1,024 caracteres de longitud.
| Marcas de configuración | Comportamiento de la sonda | Criterios para alcanzar el éxito |
|---|---|---|
No se especificaron --request ni --response
|
El verificador no envía ninguna cadena de solicitud. | Solo se basan en los criterios de éxito. |
Se especificaron --request y --response
|
El verificador envía la cadena de solicitud configurada. | Los criterios de éxito básicos y la cadena de respuesta que recibe el verificador deben coincidir exactamente con la cadena de respuesta esperada. |
Solo se especificó --response
|
El verificador no envía ninguna cadena de solicitud. | Los criterios de éxito básicos y la cadena de respuesta que recibe el verificador deben coincidir exactamente con la cadena de respuesta esperada. |
Solo se especificó --request
|
El verificador envía la cadena de solicitud configurada. | Solo criterios de éxito básicos (no se verifica ninguna cadena de respuesta). |
Criterios de éxito para gRPC
Las verificaciones de estado de gRPC solo se usan con aplicaciones de gRPC, Google Cloud balanceadores de cargas y Cloud Service Mesh. Google Cloud admite dos tipos de verificaciones de estado de gRPC:
- Las verificaciones de estado de
grpc_with_tlsse usan para verificar el estado de los backends de gRPC con TLS habilitado. Admiten la encriptación TLS sin autenticación, lo que significa que las verificaciones de estado no verifican la identidad del servidor. - Las verificaciones de estado
grpcse usan para verificar el estado de los backends de gRPC no seguros. No admiten la autenticación ni la encriptación, por lo que no se pueden usar para backends de gRPC con TLS habilitado.
Si usas verificaciones de estado de gRPC (con o sin TLS), 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.
Para obtener más información, consulta lo siguiente:
- Marca adicional para las verificaciones de estado de gRPC
- Documentación de gRPC para las verificaciones de estado
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 (301, 302), se consideran en mal estado.
Estado
Google Cloud usa las siguientes marcas de configuración de umbral de buen estado y mal estado 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 estadohealthy-threshold |
El umbral de buen estado especifica la cantidad de resultados de sondeos secuenciales correctos para que un backend que estaba en mal estado1 se considere en buen estado. Los backends que antes estaban en mal estado pueden revertirse si son capaces de alcanzar el umbral de buen estado otra vez. 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. Es posible que los backends recién agregados se consideren en buen estado después de un solo sondeo exitoso. |
Un umbral de 2 sondeos. |
Umbral de mal estadounhealthy-threshold |
El umbral de mal estado especifica la cantidad de resultados de sondeos secuenciales fallidos para que un backend que estaba en buen estado2 se considere en mal estado. Google Cloud considera que los backends están en mal estado cuando se alcanza 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. |
Un umbral de 2 sondeos. |
1 El backend que anteriormente estaba en mal estado hace referencia a los backends que se encontraban en los estados detallados de verificación de estado UNHEALTHY o TIMEOUT.
2 Backend en buen estado anteriormente hace referencia a los backends que se encontraban en los estados de verificación de estado detallados HEALTHY o DRAINING.
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 de cargas de aplicaciones externo global Balanceador de cargas de aplicaciones interno entre regiones Balanceador de cargas de aplicaciones externo regional Balanceador de cargas de aplicaciones interno regional |
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 de proxy | Finaliza las conexiones TCP de clientes nuevos cuando todos los backends están en mal estado. |
| Balanceadores de cargas de red de transferencia externos globales |
Si todos los backends están en mal estado en la región más cercana al usuario, se realiza automáticamente la conmutación por error del tráfico a la siguiente región más cercana con backends en buen estado y capacidad disponible. Si todos los backends están en mal estado a nivel global, como último recurso, distribuye el tráfico entre los backends en mal estado según la configuración de backend preferida y las capacidades objetivo. |
| Balanceador de cargas de red de transferencia interno Balanceadores de cargas de red de transferencia externos regionales basados en servicios de backend |
Si la política de conmutación por error está configurada para descartar conexiones nuevas cuando todos los backends principales y de conmutación por error están en mal estado, descarta todo el tráfico entrante. De lo contrario, como último recurso, distribuye el tráfico entre los backends en mal estado según la configuración de conmutación por error y los pesos de los backends. Para obtener detalles, consulta: |
| Balanceadores de cargas de red de transferencia externos regionales basados en grupos de destino | Como último recurso, distribuye el tráfico entre todos los backends en mal estado. |
Notas adicionales
En las siguientes secciones, se incluyen algunas notas adicionales sobre el uso de verificaciones de estado en Google Cloud.
Certificados y verificaciones de estado
Google Cloud Los sistemas de sondeo de verificación de estado 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 certificada (CA).
- Se aceptan certificados caducados o que aún no son válidos.
- Ni los atributos
CNnisubjectAlternativeNamedeben coincidir con un encabezadoHosto 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:
- 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.
Cada sistema de sondeo de verificación de estado hace lo siguiente:
- Inicia una conexión HTTP desde una de las direcciones IP de origen hasta la instancia de backend cada 30 segundos.
- Espera hasta cinco segundos por un código de estado
200 (OK)(criterios de éxito para los protocolos HTTP, HTTPS y HTTP/2).
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:
- 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. - Recibe dos respuestas consecutivas que no coinciden con los criterios de éxito específicos del protocolo.
- No recibe un código de respuesta
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:
- t=0: Iniciar el sondeo A.
- t=5: Detener el sondeo A.
- t=30: Iniciar el sondeo B.
- t=35: Detener el sondeo B.
- t=60: Iniciar el sondeo C.
- t=65: Detener el sondeo C.
¿Qué sigue?
- Para crear, modificar y usar verificaciones de estado, consulta Usa verificaciones de estado.
- Para solucionar problemas de verificación de estado, habilita los registros de verificaciones de estado.