Se usó la API de Cloud Translation para traducir esta página.

Configura las verificaciones de estado

Google Distributed Cloud (GDC) air-gapped proporciona mecanismos de verificación de estado que determinan si las instancias de backend responden de forma adecuada al tráfico. En este documento, se describe cómo crear y usar las verificaciones de estado para los balanceadores de cargas.

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.

El estado de cada backend se determina según una cantidad configurable de sondeos consecutivos exitosos o fallidos. Es decir, configuras la cantidad de sondeos correctos consecutivos necesarios para marcar un backend como en buen estado y la cantidad de errores consecutivos para marcarlo como en mal estado.

Este estado de salud determina si un backend es apto para recibir solicitudes o conexiones nuevas. Un backend en mal estado, según lo identifica la verificación de estado, no recibirá tráfico a través del balanceador de cargas. Tú defines los criterios para un sondeo exitoso. Para obtener más información, consulta la sección Cómo funcionan las verificaciones de estado.

Protocolos de verificación de estado

Las verificaciones de estado admiten los siguientes protocolos:

TCP
HTTP
HTTPS

Selecciona una verificación de estado

Las verificaciones de estado deben ser compatibles con el tipo de balanceador de cargas y los tipos de backend. Ten en cuenta los siguientes factores cuando selecciones una verificación de estado:

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

Cómo funcionan las verificaciones de estado

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

Sondeos

Cuando estableces una verificación de estado, defines o aceptas la configuración predeterminada que rige la frecuencia con la que cada sondeo evalúa el estado de los extremos asociados. Estos parámetros son fundamentales porque el balanceador de cargas deja de enrutar solicitudes a un backend que se considera en mal estado según los criterios que configuraste. La sonda persistirá en sus evaluaciones y reanudará el envío de tráfico al backend después de que se considere que está en buen estado nuevamente.

Es importante tener en cuenta que la configuración de la verificación de estado se aplica de manera uniforme a todos los backends de un servicio de backend o grupo de destino, y no se puede configurar por backend.

Marca de configuración	Explicación	Valor predeterminado
Intervalo de verificación `check-interval`	Es el tiempo (en segundos) desde el inicio de un sondeo hasta el inicio del siguiente sondeo del mismo sistema de sondeo.	`5s` (5 segundos)
timeoutSec `timeoutSec`	Es el tiempo (en segundos) que se espera para un sondeo antes de declarar una falla.	`5s` (5 segundos)
healthyThreshold `healthyThreshold`	Cantidad de sondeos secuenciales que deben realizarse con éxito para que el extremo se considere en buen estado.	2
unhealthyThreshold `unhealthyThreshold`	Cantidad de sondeos secuenciales que deben fallar para que el extremo se considere en mal estado.	2

Criterios de éxito para las verificaciones de estado de HTTP y HTTPS

Para las verificaciones de estado HTTP y HTTPS, se requiere un código de estado HTTP 200 (OK) para una respuesta exitosa antes de que se agote el tiempo de espera de la verificación de estado. Otros códigos de respuesta HTTP, incluidos los redireccionamientos (por ejemplo, 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 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 debe constar solo 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 indican las combinaciones válidas de los campos requestPath y response que están disponibles para las verificaciones de estado HTTP y HTTPS.

Marcas de configuración	Comportamiento de la sonda	Criterios para alcanzar el éxito
No se especificaron ni RequestPath ni Response	El verificador usa `/` como ruta de solicitud.	Solo el código de respuesta `200 (OK)` HTTP.
Se especificaron RequestPath 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ó RequestPath	El verificador usa la ruta de acceso de la solicitud configurada.	Solo el código de respuesta `200 (OK)` HTTP.

Criterios de éxito para las verificaciones de estado de TCP

Las verificaciones de estado de TCP 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.
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.

Antes de comenzar

Para configurar los sondeos de verificación de estado, debes tener lo siguiente:

Ser propietario del proyecto para el que configuras el balanceador de cargas Para obtener más información, consulta Cómo crear un proyecto.
Los roles de identidad y acceso necesarios son los siguientes:
- Pídele al administrador de IAM de la organización que te otorgue el rol de administrador del balanceador de cargas (load-balancer-admin).
- En el caso de los ILB globales, pídele al administrador de IAM de tu organización que te otorgue el rol de administrador de balanceador de cargas global (global-load-balancer-admin). Para obtener más información, consulta Descripciones de roles predefinidos.

Crea y administra verificaciones de estado

GDC admite verificaciones de estado globales y zonales.

API de HealthCheck

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

apiVersion zonal: networking.gdc.goog
apiVersion global: networking.global.gdc.goog

También puedes usar la CLI de gcloud para crear y administrar verificaciones de estado.

Crea un `HealthCheck` global

En el siguiente ejemplo, se muestra cómo crear un HealthCheck con 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

Crea un `HealthCheck` zonal

En el siguiente ejemplo, se muestra cómo crear un HealthCheck con 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 verificación de estado a un balanceador de cargas, consulta lo siguiente:

Verificación de la configuración

Para asegurarte de que la configuración sea correcta, verifica la condición Ready del objeto HealthCheck. Esta condición indica cualquier error de configuración. Además, confirma que los campos reflejen con precisión la configuración de HealthCheck requerida.

Notas de uso adicionales

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

Certificados y verificaciones de estado

Para protocolos como HTTPS, que exigen certificados en tus backends,

Los certificados pueden ser autofirmados o de cualquier autoridad certificadora (CA).
Se aceptan certificados vencidos o con fecha futura.

Encabezados

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

Es importante tener en cuenta que el balanceador de cargas agrega los encabezados de solicitud personalizados que configuras solo a las solicitudes del cliente, no a los sondeos de verificación 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 verificación de estado, es posible que la verificación de estado falle.

Ejemplo de verificación de estado

Si se configura una verificación de estado con los siguientes parámetros:

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

La verificación de estado funcionará de la siguiente manera:

Cada sistema de sondeo de verificación 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 muestre un código de estado HTTP 200 (OK) (los criterios de éxito designados para los protocolos HTTP y HTTPS).
Un backend se considera en mal estado si al menos un sistema de sondeo de verificación de estado hace lo siguiente:
1. No recibe una respuesta HTTP 200 (OK) para dos sondeos consecutivos debido a una conexión rechazada, un tiempo de espera de conexión o un tiempo de espera de socket.
2. Recibe dos respuestas consecutivas que no coinciden con los criterios de éxito específicos del protocolo.
Un backend se considera en buen estado cuando al menos un sistema de sondeo de verificación de estado recibe dos respuestas consecutivas que cumplen 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.

Limitaciones

Las verificaciones de estado de GDC solo atenderán los extremos de VM.
Los balanceadores de cargas con verificaciones de estado no se pueden configurar con Pods y VMs como backends mixtos. Un balanceador de cargas debe constar solo de pods o solo de VMs como sus extremos. Por el momento, un balanceador de cargas debe constar solo de pods o solo de VMs como sus extremos.
Aún no se admite la mutabilidad del balanceador de cargas ni de la verificación de estado asociada.