Configurar comprobaciones del estado

Google Distributed Cloud (GDC) air-gapped proporciona mecanismos de comprobación del estado que determinan si las instancias de backend responden adecuadamente al tráfico. En este documento se describe cómo crear y usar comprobaciones de estado para balanceadores de carga.

A menos que se indique lo contrario, Google Cloud las comprobaciones del estado se implementan mediante tareas de software específicas que se conectan a las back-ends 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.

El estado de cada backend se determina mediante un número configurable de comprobaciones consecutivas correctas o fallidas. Es decir, se configura el número de comprobaciones correctas consecutivas necesarias para marcar un backend como correcto y el número de errores consecutivos para marcarlo como incorrecto.

Este estado de salud determina si un backend puede recibir nuevas solicitudes o conexiones. Los backends que no estén en buen estado, según la comprobación del estado, no recibirán tráfico a través del balanceador de carga. Tú defines los criterios para que una petición sea correcta. Para obtener más información, consulta la sección Cómo funcionan las comprobaciones del estado.

Protocolos de comprobación del estado

Las comprobaciones de estado admiten los siguientes protocolos:

  • TCP
  • HTTP
  • HTTPS

Seleccionar una comprobación del estado

Las comprobaciones del estado deben ser compatibles con el tipo de balanceador de carga y los tipos de backend. A la hora de seleccionar una comprobación de estado, ten en cuenta los siguientes factores:

  • Protocolo: el protocolo que usa GDC para sondear los backends. Los protocolos admitidos son TCP, HTTP y HTTPS. El protocolo TCP es útil para las comprobaciones de estado básicas que validan la conectividad a un backend, mientras que los protocolos HTTP y HTTPS proporcionan mecanismos de comprobación de estado más detallados para las VMs que ya ejecutan cargas de trabajo HTTP o HTTPS.
  • Especificación de puerto: el puerto que usa GDC con el protocolo para comprobar el estado de un backend. Debes especificar un puerto para la comprobación del estado.
  • Categoría: las comprobaciones del estado pueden ser globales o zonales. Las comprobaciones del estado globales abarcan todas las zonas de una implementación de GDC, mientras que las comprobaciones del estado zonales corresponden a una zona.

Cómo funcionan las comprobaciones del estado

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

Comprobaciones

Cuando configuras una comprobación de estado, defines o aceptas los ajustes predeterminados que rigen la frecuencia con la que cada sonda evalúa el estado de los endpoints asociados. Estos ajustes son cruciales porque el balanceador de carga deja de enrutar solicitudes a un backend que se considera no apto según los criterios que hayas configurado. La sonda seguirá haciendo evaluaciones y reanudará el envío de tráfico al backend cuando se considere que está en buen estado.

Es importante tener en cuenta que los ajustes de comprobación del estado se aplican de forma uniforme a todos los backends de un servicio backend o un grupo de destino, y no se pueden configurar por backend.

Marca de configuración Explicación Valor predeterminado
Intervalo de comprobación

check-interval

 Tiempo (en segundos) que transcurre desde el inicio de una sonda hasta el inicio de la siguiente sonda del mismo comprobador. 5s (5 segundos)
timeoutSec

timeoutSec

 Tiempo (en segundos) que se espera una comprobación antes de declarar un fallo. 5s (5 segundos)
healthyThreshold

healthyThreshold

 Número de sondeos secuenciales que deben completarse correctamente para que el endpoint se considere en buen estado. 2
unhealthyThreshold

unhealthyThreshold

 Número de sondeos secuenciales que deben fallar para que el endpoint se considere en mal estado. 2

Criterios de éxito de las comprobaciones del estado de HTTP y HTTPS

En las comprobaciones del estado de HTTP y HTTPS, se necesita un código de estado HTTP 200 (OK) para que la respuesta sea correcta antes de que se agote el tiempo de espera de la comprobación del estado. Otros códigos de respuesta HTTP, incluidas las redirecciones (por ejemplo, 301 y 302), se consideran incorrectos.

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 constar de caracteres ASCII imprimibles de un solo byte, situados en los primeros 1024 bytes del cuerpo de la respuesta HTTP.

En la siguiente tabla se enumeran las combinaciones válidas de los campos requestPath y response que están disponibles para las comprobaciones de estado HTTP y HTTPS.

Marcas de configuración Comportamiento de la sonda Criterios de éxito
No se ha especificado RequestPath ni Response El verificador usa / como ruta de solicitud. Solo el código de respuesta HTTP 200 (OK).
Se han especificado tanto RequestPath como Response El comprobador usa la ruta de solicitud configurada. El código de respuesta HTTP 200 (OK) y los primeros 1024 caracteres ASCII del cuerpo de la respuesta HTTP deben coincidir con la cadena de respuesta esperada.
Solo se ha especificado Response El verificador usa / como ruta de solicitud. El código de respuesta HTTP 200 (OK) y los primeros 1024 caracteres ASCII del cuerpo de la respuesta HTTP deben coincidir con la cadena de respuesta esperada.
Solo se ha especificado RequestPath El comprobador usa la ruta de solicitud configurada. Solo el código de respuesta HTTP 200 (OK).

Criterios de éxito de las comprobaciones del estado TCP

Las comprobaciones del estado de TCP 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 las comprobaciones de estado de 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, la sonda puede considerarse fallida si el comprobador de estado ya ha enviado un paquete FIN.

Antes de empezar

Para configurar las sondas de comprobación del estado, debe tener lo siguiente:

  • Ser propietario del proyecto en el que vas a configurar el balanceador de carga. Para obtener más información, consulta Crear un proyecto.

  • Los roles de identidad y acceso necesarios:

    • Pide al administrador de gestión de identidades y accesos de tu organización que te conceda el rol Administrador de balanceadores de carga (load-balancer-admin).
    • En el caso de los ILBs globales, pide a tu administrador de gestión de identidades y accesos de la organización que te conceda el rol de administrador de balanceadores de carga globales (global-load-balancer-admin). Para obtener más información, consulta Descripciones de los roles predefinidos.

Crear y gestionar comprobaciones del estado

GDC admite comprobaciones del estado globales y zonales.

API HealthCheck

Puedes configurar un objeto HealthCheck como global o zonal. Los objetos HealthCheck globales se usan para las configuraciones de balanceadores de carga globales, mientras que los objetos HealthCheck zonales se usan para las configuraciones de balanceadores de carga zonales. Ambos tipos tienen el mismo nombre y la misma especificación. Sin embargo, usan valores de apiVersion y servidores de API diferentes:

También puedes usar la CLI de gdcloud para crear y gestionar comprobaciones del estado.

Crear un HealthCheck global

En el siguiente ejemplo se muestra cómo crear un HealthCheck mediante la API:

  kubectl --kubeconfig GLOBAL_ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.global.gdc.goog/v1 
  kind: HealthCheck 
  metadata: 
    namespace: PROJECT 
    name: my-hc 
  spec: 
    httpHealthCheck: 
      port: PORT 
      host: HOST 
      requestPath: requestPath 
      response: responseT 
  EOF

Crear un HealthCheck zonal

En el siguiente ejemplo se muestra cómo crear un HealthCheck mediante la API:

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.gdc.goog/v1
  kind: HealthCheck
  metadata:
    namespace: PROJECT
    name: my-hc
  spec:
    httpHealthCheck:
      port: PORT
      host: HOST
      requestPath: requestPath 
      response: response 
  EOF

Para vincular una comprobación del estado a un balanceador de carga, consulta lo siguiente:

Verificación de la configuración

Para asegurarse de que la configuración es correcta, verifique la condición Ready del objeto HealthCheck. Esta condición indica cualquier error de configuración. Además, confirma que los campos reflejan con precisión los HealthCheck ajustes necesarios.

Notas de uso adicionales

En las siguientes secciones se incluyen notas adicionales sobre el uso de comprobaciones del estado en Google Cloud.

Certificados y comprobaciones del estado

En el caso de protocolos como HTTPS, que requieren certificados en los backends,

  • Los certificados pueden tener una firma automática o proceder de cualquier autoridad de certificación (CA).
  • Se aceptan certificados caducados o con fecha futura.

Encabezados

Cuando configures comprobaciones de estado para protocolos HTTP o HTTPS, puedes especificar un encabezado HTTP Host mediante la marca --host.

Es importante tener en cuenta que el balanceador de carga añade los encabezados de solicitud personalizados que configures solo a las solicitudes de los clientes, no a las comprobaciones de estado. Por lo tanto, si tu backend requiere un encabezado específico para la autorización que no está presente en el paquete de comprobación del estado, es posible que la comprobación del estado falle.

Comprobación del estado de ejemplo

Si una comprobación del estado se configura con los siguientes parámetros:

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

La comprobación del estado funcionará de la siguiente manera:

  • Cada comprobador de estado hará lo siguiente:
    1. Inicia una conexión HTTP desde una dirección IP de origen a la instancia de backend cada 30 segundos.
    2. Espera hasta cinco segundos para que se devuelva un código de estado 200 (OK) HTTP (el criterio de éxito designado para los protocolos HTTP y HTTPS).
  • Un backend se considera no saludable si al menos uno de los sistemas de sondeo de comprobación del estado hace lo siguiente:
    1. No recibe una respuesta HTTP 200 (OK) en dos sondeos consecutivos debido a una conexión rechazada, a que se ha agotado el tiempo de espera de la conexión o a que se ha agotado el tiempo de espera del socket.
    2. Recibe dos respuestas consecutivas que no cumplen los criterios de éxito específicos del protocolo.
  • Se considera que un backend está en buen estado cuando al menos uno de los sistemas de sondeo de comprobación de estado recibe dos respuestas consecutivas que cumplen 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 se ha agotado el tiempo de espera de la conexión como si no). Es decir, el tiempo de espera siempre debe ser inferior o igual al intervalo, y nunca lo aumenta.

Limitaciones

  1. Las comprobaciones del estado de GDC solo se aplicarán a los endpoints de las VMs.
  2. Los balanceadores de carga con comprobaciones de estado no se pueden configurar con pods y VMs como backends mixtos. Un balanceador de carga solo puede tener pods o VMs como puntos finales. Por ahora, un balanceador de carga solo puede tener pods o VMs como puntos finales.
  3. Aún no se admite la mutabilidad del balanceador de carga ni de la comprobación de estado asociada.