Crea verificaciones de estado

Google Cloud Platform (GCP) proporciona mecanismos de verificación de estado que determinan si las instancias de VM responden al tráfico de forma correcta. En este documento, se describe cómo crear y usar las verificaciones de estado para balanceadores de cargas.

En esta página, se da por hecho que estás familiarizado con los conceptos de verificación de estado y que conoces las reglas de firewall de GCP.

Categorías, protocolos y puertos de verificación de estado

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

Hay dos categorías de verificación de estado: verificaciones de estado y verificaciones de estado heredadas. Cada categoría admite un conjunto diferente de protocolos y un medio a fin de especificar el puerto que se usa para la verificación de estado.

La mayoría de los balanceadores de cargas usan verificaciones de estado no heredadas, pero el balanceo de cargas de red requiere que uses verificaciones de estado heredadas. Consulta cómo seleccionar una verificación de estado en la página de conceptos de verificaciones de estado para determinar la categoría, el protocolo y el método de especificación de puerto adecuados.

No es necesario que el protocolo que selecciones para una verificación de estado coincida con el protocolo que usa el balanceador de cargas; además, en algunos casos, no puede hacerlo. Consulta Protocolos y balanceadores de cargas para obtener más información.

El término “verificación de estado” no hace referencia a las verificaciones de estado heredadas. En este documento, las verificaciones de estado heredadas se denominan de manera explícita como “verificaciones de estado heredadas”.

Crea verificaciones de estado

GCP te permite crear o seleccionar una verificación de estado cuando completas la configuración de backend del balanceador de cargas en GCP Console.

También puedes crear una verificación de estado sin importar la configuración del balanceador de cargas en GCP Console. Esto es útil si primero necesitas crear la verificación de estado o usar una para varios balanceadores de cargas. Puedes crear una verificación de estado con GCP Console, la herramienta de línea de comandos de gcloud o las API de REST. Una vez que revises la información general en esta sección, continúa con la creación y modificación de verificaciones de estado para obtener instrucciones.

Los balanceadores de cargas de red deben usar verificaciones de estado heredadas, que puedes crear o seleccionar cuando completas la configuración de backend del balanceador de cargas de red en GCP Console. Para crear una verificación de estado heredada de forma independiente, debes usar la herramienta de línea de comandos de gcloud o las API de REST. Para obtener más información, consulta las verificaciones de estado heredadas.

Marcas que se usan en todas las verificaciones de estado

Las marcas siguientes son comunes a todas las verificaciones de estado, independientemente del protocolo:

gcloud compute health-checks create PROTOCOL HEALTH_CHECK_NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    ...additional flags

Donde:

  • PROTOCOL define el protocolo que se usa para la verificación de estado. Las opciones válidas son http, https, http2, ssl y tcp.
  • HEALTH_CHECK_NAME es el nombre de la verificación de estado. Dentro de un proyecto determinado, cada una debe tener un nombre único.
  • DESCRIPTION es una descripción opcional.
  • CHECK_INTERVAL es la cantidad de tiempo desde el inicio de la conexión del sistema de un sondeo de verificación de estado hasta el inicio de la siguiente. Las unidades están en segundos. Si se omite, GCP usa un valor de 5s (5 segundos).
  • TIMEOUT es la cantidad de tiempo que GCP espera una respuesta de un sondeo. El valor de TIMEOUT debe ser menor o igual que CHECK_INTERVAL. Las unidades están en segundos. Si se omite, GCP usa un valor de 5s (5 segundos).
  • HEALTHY_THRESHOLD y UNHEALTHY_THRESHOLD especifican la cantidad de sondeos secuenciales que deben tener éxito o fallar para que la instancia de VM se considere en buen o mal estado. Si se omite, GCP usa un umbral predeterminado de 2.
  • …marcas adicionales son otras marcas para especificar puertos y opciones específicas de PROTOCOL. Estas marcas se describen en las secciones siguientes.

Marcas de especificación de puertos

Además de un protocolo, debes especificar un puerto para una verificación de estado. La forma en que especificas el puerto depende del tipo de balanceador de cargas y backends que usa el servicio de backend. En la tabla siguiente, se muestran las opciones de especificación de puerto para combinaciones válidas de balanceadores de cargas y backend. Como se usa en la tabla, el término grupo de instancias hace referencia a grupos de instancias no administrados, grupos de instancias zonales administrados o grupos de instancias regionales administrados.

Las verificaciones de estado solo pueden usar un tipo de especificación de puertos.

Balanceador de cargas Tipo de backend Especificación de puerto
Balanceo de cargas TCP/UDP interno Grupos de instancias Usa una de estas opciones1:
--port: especifica un puerto por número, del 1 al 65535.
--port-name: especifica cualquier puerto con nombre que exporta un grupo de instancias.
No puedes usar la marca --use-serving-port para una verificación de estado asociada a un balanceador de cargas interno porque los servicios de backend para balanceadores de cargas internos no tienen especificación de puertos de ningún tipo.
Balanceo de cargas de HTTP(S) interno
Balanceo de cargas del proxy de TCP
Balanceo de cargas del proxy de SSL
Balanceo de cargas HTTP(S)
Grupos de extremos de red Usa una de estas opciones1:
--port: especifica un puerto por número, del 1 al 65535.
--use-serving-port2: usa el puerto que especifica cada extremo del grupo de extremos de la red.
Grupos de instancias Usa una de estas opciones1:
--port: especifica un puerto por número, del 1 al 65535.
--port-name: especifica cualquier puerto con nombre que exporta un grupo de instancias.
--use-serving-port2: usa el mismo grupo de instancias llamado puerto que el servicio de backend está configurado para usar.

1Las combinaciones de especificación de puerto se resuelven de la manera siguiente:

  • Si se especifica --use-serving-port, no se pueden especificar --port ni --port-name.
  • Si se especifican --port y --port-name, prevalece --port.
  • Si no se especifica ninguna de los tres, el valor predeterminado es: --port=80

2Beta: debes usar los siguientes comandos Beta de gcloud si necesitas --use-serving-port:

Marcas opcionales para las verificaciones de estado HTTP, HTTPS y HTTP/2

Además de las marcas comunes y la especificación de puertos, puedes usar las siguientes marcas opcionales para las verificaciones de estado HTTP, HTTPS y HTTP/2. En este ejemplo, se crea una verificación de estado HTTP llamada hc-http-port-80 mediante el puerto 80 con los criterios predeterminados de intervalo, tiempo de espera y umbral de estado.

gcloud compute health-checks create http hc-http-port-80 \
    --description="Simple HTTP port 80 health check" \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2 \
    --port=80 \
    --host=HOST \
    --proxy-header=PROXY_HEADER \
    --request-path=REQUEST_PATH \
    --response=RESPONSE
  • El protocolo puede ser http (en este ejemplo), https o http2.
  • HOST te permite proporcionar un encabezado HTTP de host. Si se omite, se usa la dirección IP de la regla de reenvío del balanceador de cargas.
  • PROXY_HEADER debe ser NONE o PROXY_V1. Si se omite, GCP usa NONE. El valor de PROXY_V1 agrega el encabezado PROXY UNKNOWN\r\n.
  • REQUEST_PATH especifica la ruta de URL que usa GCP cuando envía solicitudes de verificación de estado. Si se omite este paso, la solicitud de verificación de estado se envía a /.
  • RESPONSE define una respuesta esperada opcional. Las strings de respuesta deben seguir estas reglas:
    • La string de respuesta debe constar de letras, números y espacios ASCII.
    • La string de respuesta puede tener hasta 1,024 caracteres.
    • La coincidencia con comodines no es compatible.
    • La verificación basada en contenido no admite inversión; por ejemplo, los operadores como ! en HAProxy no son compatibles.

Si GCP encuentra la string de respuesta esperada en cualquier lugar de los primeros 1,024 bytes del cuerpo de respuesta recibido y si el estado HTTP es 200 (OK), se considera que el sondeo tuvo éxito.

Las marcas --request-path y --response modifican los criterios de éxito del sondeo de verificación de estado.

Marcas opcionales para las verificaciones de estado de SSL y TCP

Además de las marcas comunes y la especificación de puerto, puedes usar las siguientes marcas opcionales para las verificaciones de estado de SSL y TCP. En este ejemplo, se crea una verificación de estado de TCP denominada hc-tcp-3268 mediante el puerto 3268 con criterios de intervalo, tiempo de espera y umbral de estado predeterminados.

gcloud compute health-checks create tcp hc-tcp-3268 \
    --description="Health check: TCP 3268" \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2 \
    --port=3268 \
    --proxy-header=PROXY_HEADER \
    --request=REQUEST_STRING \
    --response=RESPONSE_STRING
  • El protocolo puede ser tcp (en este ejemplo) o ssl.
  • PROXY_HEADER debe ser NONE o PROXY_V1. Si se omite, GCP usa NONE. El valor de PROXY_V1 agrega el encabezado PROXY UNKNOWN\r\n.
  • REQUEST_STRING: puedes proporcionar una string de hasta 1,024 caracteres ASCII para enviar una vez que se estableció la sesión TCP o SSL.
  • RESPONSE_STRING: puedes proporcionar una string de hasta 1,024 caracteres ASCII para la respuesta esperada.

Las marcas --request y --response modifican los criterios de éxito del sondeo de verificación de estado. Si usas la marca --response, sola o junto con la marca --request, la respuesta que se muestra debe coincidir de manera exacta con la string de respuesta esperada.

Crea y modifica verificaciones de estado

No se puede convertir una verificación de estado en una verificación de estado heredada ni viceversa mediante su modificación.

Console

GCP Console enumera ambas verificaciones: las de estado y las de estado heredadas. Se pueden editar las verificaciones de estado existentes y las de estado heredadas. Sin embargo, no se puede crear una verificación de estado heredada en la página de verificaciones de estado en GCP Console.

Haz lo siguiente para crear una verificación de estado:

  1. Dirígete a la página de verificaciones de estado en Google Cloud Platform Console.
    Ir a la página Verificación de estado
  2. Haz clic en Crear una verificación de estado.
  3. En la página Crear una verificación de estado, proporciona la información siguiente:
    • Nombre: proporciona un nombre para la verificación de estado.
    • Descripción: de manera opcional, puedes proporcionar una descripción.
    • Protocolo: elige un protocolo de verificación de estado.
    • Puerto: proporciona un número de puerto.
    • Protocolo de proxy: de manera opcional, puedes agregar un encabezado de proxy a las solicitudes que realizan los sistemas de sondeo de verificación de estado.
    • Solicitar ruta y respuesta: para los protocolos HTTP, HTTPS y HTTP2, de manera opcional, puedes proporcionar una ruta de URL a fin de que los sistemas de sondeo de verificación de estado se pongan en contacto. Consulta las marcas opcionales para verificaciones de estado HTTP, HTTPS y HTTP/2 a fin de obtener más información.
    • Solicitud y Respuesta: en los protocolos TCP y SSL, puedes especificar una string de texto ASCII para enviar y una string de respuesta de texto esperada. Consulta las marcas opcionales para las verificaciones de estado de SSL y TCP a fin de obtener más información.
    • Intervalo de verificación: define la cantidad de tiempo desde el inicio de un sondeo hasta el inicio del siguiente.
    • Tiempo de espera: define la cantidad de tiempo que GCP esperará la respuesta de un sondeo. Su valor debe ser menor o igual que el intervalo de verificación.
    • Umbral de buen estado: define la cantidad de sondeos secuenciales que deben realizarse con éxito para que la instancia de VM se considere en buen estado.
    • Umbral de mal estado: define la cantidad de sondeos secuenciales que deben fallar para que la instancia de VM se considere en mal estado.
  4. Haz clic en Crear.

Haz lo siguiente para editar una verificación de estado:

  1. Dirígete a la página de verificaciones de estado en Google Cloud Platform Console.
    Ir a la página Verificación de estado
  2. Haz clic en una verificación de estado para ver sus detalles.
  3. Si necesitas modificar la verificación de estado, haz clic en Editar y, luego, haz esto:
    • Realiza cambios en los parámetros según sea necesario.
    • Haz clic en Guardar.

gcloud

  1. Usa los siguientes comandos de gcloud para crear una lista de verificaciones de estado:

    gcloud compute health-checks list
    
  2. Identifica una verificación de estado y, luego, descríbela con el comando de gcloud adecuado y reemplaza HEALTH_CHECK_NAME por su nombre.

    gcloud compute health-checks describe HEALTH_CHECK_NAME
    
  3. A fin de modificar la verificación de estado, debes usar el comando de gcloud adecuado y reemplazar HEALTH_CHECK_NAME por su nombre. A excepción del nombre y protocolo de la verificación de estado, puedes modificar cualquiera de las marcas comunes, las marcas de puertos y las marcas opcionales. Cuando modificas una verificación de estado existente con el comando de gcloud compute health-checks update, la configuración ya establecida se conserva para las marcas que omites. Con el comando siguiente, se modifica una verificación de estado de ejemplo mediante el cambio del intervalo de verificación, el tiempo de espera y la ruta de solicitud:

    gcloud compute health-checks update http hc-http-port-80 \
        --check-interval=20s \
        --timeout=15s \
        --request-path="/health"
    

API

  1. Puedes enumerar las verificaciones de estado con la llamada a la API healthChecks.list .

  2. Si conoces el nombre de una verificación de estado, puedes obtener los detalles de la configuración con la llamada a la API healthChecks.get.

  3. Si necesitas modificar una verificación de estado, usa estas llamadas a la API:

Verificaciones de estado heredadas

Crea verificaciones de estado heredadas

En esta sección, se describe cómo crear verificaciones de estado heredadas que son necesarias para los balanceadores de cargas de red.

Console

Aunque la página de verificaciones de estado de GCP Console enumera ambas verificaciones, las de estado y las de estado heredadas, no se puede crear una verificación de estado heredada en GCP Console. Solo puedes crear una verificación de estado heredada con la página del balanceador de cargas de red de GCP Console.

gcloud

Usa el siguiente comando de gcloud a fin de crear una verificación de estado heredada para un balanceador de cargas de red:

gcloud compute LEGACY_CHECK_TYPE create LEGACY_HEALTH_CHECK_NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --host=HOST \
    --port=PORT \
    --request-path=REQUEST_PATH

Donde:

  • LEGACY_CHECK_TYPE es http-health-checks para una verificación de estado HTTP heredada o https-health-checks para una verificación de estado HTTPS heredada. Si creas la verificación de estado heredada para un balanceador de cargas de red, debes usar http-health-checks.
  • LEGACY_HEALTH_CHECK_NAME es el nombre de la verificación de estado heredada. Dentro de un proyecto determinado, cada verificación de estado heredada debe tener un nombre único.
  • DESCRIPTION es una descripción opcional.
  • CHECK_INTERVAL es la cantidad de tiempo desde el inicio de un sondeo hasta el inicio del siguiente. Las unidades están en segundos. Si se omite, GCP usa un valor de 5s (5 segundos).
  • TIMEOUT es la cantidad de tiempo que GCP esperará una respuesta de un sondeo. El valor de TIMEOUT debe ser menor o igual que CHECK_INTERVAL. Las unidades están en segundos. Si se omite, GCP usa un valor de 5s (5 segundos).
  • HEALTHY_THRESHOLD y UNHEALTHY_THRESHOLD especifican la cantidad de sondeos secuenciales que deben tener éxito o fallar para que una instancia de VM se considere en buen o mal estado. Si se omite, GCP usa un umbral predeterminado de 2.
  • HOST te permite proporcionar un encabezado HTTP de host. Si se omite, se usa la dirección IP de la regla de reenvío del balanceador de cargas.
  • PORT te permite proporcionar un número de puerto. Si se omite, GCP usa 80.
  • REQUEST_PATH especifica la ruta de URL que usa GCP cuando envía solicitudes de verificación de estado. Si se omite este paso, la solicitud de verificación de estado se envía a /.

API

Puedes crear una verificación de estado heredada con esta llamada a la API para un balanceador de cargas de red:

Observa y modifica las verificaciones de estado heredadas

Console

GCP Console enumera ambas verificaciones, las de estado y las de estado heredadas, en la página de verificaciones de estado. Haz esto para editar una verificación de estado heredada existente:

  1. Dirígete a la página de verificaciones de estado en Google Cloud Platform Console.
    Ir a la página Verificación de estado
  2. Haz clic en una verificación de estado para ver sus detalles.
  3. Si necesitas modificar la verificación de estado, haz clic en Editar y, luego, haz esto:
    • Realiza cambios en los parámetros según sea necesario.
    • Haz clic en Guardar.

gcloud

  1. Usa los siguientes comandos de gcloud a fin de enumerar verificaciones de estado heredadas para balanceadores de cargas de red.

    gcloud compute http-health-checks list
    
  2. Identifica una verificación de estado heredada, luego, descríbela con el comando de gcloud apropiado y reemplaza LEGACY_HEALTH_CHECK_NAME por su nombre.

    gcloud compute http-health-checks describe LEGACY_HEALTH_CHECK_NAME
    
  3. Si necesitas modificar una verificación de estado heredada, usa el comando de gcloud adecuado y reemplaza LEGACY_HEALTH_CHECK_NAME por su nombre. Cuando modificas una verificación de estado con gcloud, se conservan los ajustes existentes para las marcas que omites.

    gcloud compute http-health-checks update LEGACY_HEALTH_CHECK_NAME \
        ...other options
    

    donde …otras opciones son las opciones para crear una verificación de estado heredada.

API

  1. Usa la siguiente llamada a la API a fin de enumerar las verificaciones de estado heredadas para balanceadores de cargas de red.

  2. Si conoces el nombre de una verificación de estado heredada, puedes obtener los detalles de configuración con esta llamada a la API:

  3. Si necesitas modificar una verificación de estado heredada, usa estas llamadas a la API:

Reglas de firewall

Debes crear reglas de firewall de entrada aplicables a todas las VM cuyas cargas se balancean para permitir el tráfico de los rangos de IP de verificación de estado. En los ejemplos siguientes, se crean reglas de firewall aplicables a las instancias de VM por etiqueta de objetivo. A fin de obtener más información sobre cómo especificar objetivos para las reglas de firewall, consulta la explicación de los objetivos en Descripción general de las reglas de firewall y Cómo configurar las etiquetas de red.

Cada uno de estos ejemplos permite el envío de todo el tráfico de TCP desde los sistemas de verificación de estado de GCP a las instancias de VM (el tráfico de TCP incluye tráfico SSL, HTTP, HTTPS y HTTP/2). Si lo prefieres, puedes especificar puertos junto con el protocolo TCP. Sin embargo, si especificas puertos, las reglas de firewall pueden volverse específicas para una verificación de estado en particular. Si usas tcp:80 para el protocolo y el puerto, se permite el envío de tráfico de TCP al puerto 80, por lo que GCP podría contactar a las VM mediante HTTP en el puerto 80, pero no podría con HTTPS en el puerto 443.

Reglas de verificación de estado

En el ejemplo siguiente, se crea una regla de firewall de entrada para los balanceadores de cargas siguientes:

  • Balanceo de cargas TCP/UDP interno (verificaciones de estado)
  • Balanceo de cargas HTTP(S) interno (verificaciones de estado)
  • Balanceo de cargas de proxy TCP (verificaciones de estado)
  • Balanceo de cargas de proxy SSL (verificaciones de estado)
  • Balanceo de cargas HTTP(S) (verificaciones de estado y verificaciones de estado heredadas)

Para estos balanceadores de cargas, los rangos de IP fuente para las verificaciones de estado (incluidas las de estado heredadas si se usan para el balanceo de cargas HTTP[S]) son estos:

  • 35.191.0.0/16
  • 130.211.0.0/22

Solo para el balanceo de cargas HTTP(S) interno, el rango de IP fuente son todas las direcciones IP de la subred exclusiva del proxy.

Si necesitas crear reglas destinadas al balanceo de cargas de red, consulta la sección siguiente sobre reglas para el balanceo de cargas de red.

Console

  1. Ve a la página Reglas de firewall en Google Cloud Platform Console.
    Ir a la página Reglas de firewall
  2. Haz clic en Crear regla de firewall.
  3. En la página Crear una regla de firewall, proporciona la información siguiente:
    • Nombre: proporciona un nombre para la regla. Para este ejemplo, usa fw-allow-health-checks.
    • Red: elige una red de VPC.
    • Prioridad: ingresa un número para la prioridad. Los números más bajos tienen prioridades más altas. Asegúrate de que la regla de firewall tenga una prioridad mayor que otras normas que podrían denegar el tráfico de entrada.
    • Dirección del tráfico: elige ingreso.
    • Acción si hay coincidencia: elige permitir.
    • Objetivos: elige Etiquetas de objetivo especificadas y, luego, ingresa etiquetas en el cuadro de texto Etiquetas de objetivo. Para este ejemplo, usa allow-health-checks.
    • Filtro de fuente: elige Rangos de IP.
    • Rangos de IP fuente: 35.191.0.0/16,130.211.0.0/22
    • Protocolos y puertos permitidos: usa tcp. TCP es el protocolo subyacente para todos los protocolos de verificación de estado.
    • Haz clic en Crear.
  4. En cada instancia cuyas cargas se balancean, debes agregar la etiqueta de red para que se aplique esta regla de firewall de entrada nueva. En este ejemplo, se usa allow-health-checks para la etiqueta de red.

gcloud

  1. Usa el siguiente comando de gcloud para crear una regla de firewall llamada fw-allow-health-checks que permita establecer conexiones entrantes a instancias en la red con la etiqueta allow-health-checks. Reemplaza NETWORK_NAME por el nombre de la red.

    gcloud compute firewall-rules create fw-allow-health-checks \
        --network NETWORK_NAME \
        --action ALLOW \
        --direction INGRESS \
        --source-ranges 35.191.0.0/16,130.211.0.0/22 \
        --target-tags allow-health-checks \
        --rules tcp
  2. En cada instancia cuyas cargas se balancean, debes agregar la etiqueta de red para que se aplique esta regla de firewall de entrada nueva. En este ejemplo, se usa allow-health-checks para la etiqueta de red.

Consulta la documentación de las reglas de firewall de gcloud y la documentación de la API para obtener más detalles.

Reglas para el balanceo de cargas de red

En el ejemplo siguiente, se crea una regla de firewall de entrada para el balanceo de cargas de red, que requiere una verificación de estado heredada. Los rangos de IP fuente destinadas a las verificaciones de estado heredadas para el balanceo de cargas de red son estos:

  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22

Console

  1. Ve a la página Reglas de firewall en Google Cloud Platform Console.
    Ir a la página Reglas de firewall
  2. Haz clic en Crear regla de firewall.
  3. En la página Crear una regla de firewall, proporciona la información siguiente:
    • Nombre: proporciona un nombre para la regla. Para este ejemplo, usa fw-allow-network-lb-health-checks.
    • Red: elige una red de VPC.
    • Prioridad: ingresa un número para la prioridad. Los números más bajos tienen prioridades más altas. Asegúrate de que la regla de firewall tenga una prioridad mayor que otras normas que podrían denegar el tráfico de entrada.
    • Dirección del tráfico: elige ingreso.
    • Acción si hay coincidencia: elige permitir.
    • Objetivos: elige Etiquetas de objetivo especificadas y, luego, ingresa etiquetas en el cuadro de texto Etiquetas de objetivo. Para este ejemplo, usa allow-network-lb-health-checks.
    • Filtro de fuente: elige Rangos de IP.
    • Rangos de IP fuente: 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22
    • Protocolos y puertos permitidos: usa tcp. TCP es el protocolo subyacente para HTTP y HTTPS.
    • Haz clic en Crear.
  4. En cada instancia cuyas cargas se balancean, debes agregar la etiqueta de red para que se aplique esta regla de firewall de entrada nueva. En este ejemplo, se usa allow-network-lb-health-checks para la etiqueta de red.

gcloud

  1. Usa el siguiente comando de gcloud para crear una regla de firewall llamada fw-allow-network-lb-health-checks que permita establecer conexiones entrantes a instancias en la red con la etiqueta allow-network-lb-health-checks. Reemplaza NETWORK_NAME por el nombre de la red.

    gcloud compute firewall-rules create fw-allow-network-lb-health-checks \
        --network NETWORK_NAME \
        --action ALLOW \
        --direction INGRESS \
        --source-ranges 35.191.0.0/16,209.85.152.0/22,209.85.204.0/22 \
        --target-tags allow-network-lb-health-checks \
        --rules tcp
  2. En cada instancia cuyas cargas se balancean, debes agregar la etiqueta de red para que se aplique esta regla de firewall de entrada nueva. En este ejemplo, se usa allow-network-lb-health-checks para la etiqueta de red.

Consulta la documentación de las reglas de firewall de gcloud y la documentación de la API para obtener más detalles.

Asocia con balanceadores de cargas

Protocolos y balanceadores de cargas

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. A modo de ejemplo:

  • En el balanceo de cargas TCP/UDP interno, solo puedes usar TCP o UDP para el protocolo del servicio de backend. Si entregas tráfico HTTP desde VM detrás de un balanceador de cargas interno, tiene sentido que emplees una verificación de estado con el protocolo HTTP.

  • Una verificación de estado heredada se limita al protocolo HTTP. Si usas un balanceador de cargas de red a fin de balancear el tráfico de TCP, debes ejecutar un servicio HTTP en las VM cuyas cargas se balancean para que puedan responder a los sondeos de verificación de estado.

Verificaciones de estado para servicios de backend

En esta sección, se describe cómo asociar una verificación de estado a un servicio de backend para estos tipos de balanceadores de cargas:

  • Balanceo de cargas TCP/UDP interno
  • Balanceo de cargas de HTTP(S) interno
  • Balanceo de cargas del proxy de TCP
  • Balanceo de cargas del proxy de SSL
  • Balanceo de cargas HTTP(S)

En esta sección, se supone que hiciste esto:

Para asociar una verificación de estado a un balanceador de cargas Proxy TCP, Proxy SSL o HTTP(S) interno nuevo, consulta la guía de configuración del balanceador de cargas correspondiente.

Console

Para asociar una verificación de estado a un balanceador de cargas proxy TCP, proxy SSL o HTTP(S) interno existente, haz esto:

  1. Ve a la página Balanceo de cargas de Google Cloud Platform Console.
    Ir a la página Balanceo de cargas
  2. Haz clic en un balanceador de cargas para ver sus detalles.
  3. Haz clic en Editar y, luego, en Configuración de backend.
  4. Elige una verificación de estado en el menú Verificación de estado.
  5. Haz clic en Actualizar.

gcloud

Para asociar una verificación de estado a un balanceador de cargas proxy TCP, proxy SSL o HTTP(S) interno existente, haz esto:

  1. Identifica el servicio o los servicios de backend que usa el balanceador de cargas. Los balanceadores de cargas proxy TCP y proxy SSL internos solo tienen un servicio de backend para todo el balanceador de cargas. Los balanceadores de cargas HTTP(S) tienen uno o más servicios de backend asociados al mapa de URL.

    • A fin de enumerar los servicios de backend para los balanceadores de cargas TCP/UDP internos, ejecuta el comando siguiente. Identifica el nombre y la región del servicio de backend.

      gcloud compute backend-services list \
          --filter="loadBalancingScheme=INTERNAL"
      
    • A fin de enumerar los servicios de backend para los balanceadores de cargas HTTP(S) internos, ejecuta el comando siguiente. Identifica el nombre y la región del servicio de backend.

      gcloud compute backend-services list \
          --filter="loadBalancingScheme=INTERNAL_MANAGED"
      
    • Usa el comando siguiente a fin de enumerar los servicios de backend para los balanceadores de cargas de proxy TCP:

      gcloud compute backend-services list \
          --filter="loadBalancingScheme=EXTERNAL" \
          --filter="protocol=TCP"
      
    • Usa el comando siguiente a fin de enumerar los servicios de backend para los balanceadores de cargas proxy SSL:

      gcloud compute backend-services list \
          --filter="loadBalancingScheme=EXTERNAL" \
          --filter="protocol=SSL"
      
    • A fin de identificar los servicios de backend para el balanceo de cargas HTTP(S), debes identificar el mapa de URL, luego, describirlo y reemplazar URL_MAP_NAME por el nombre del mapa de URL. Los servicios de backend que usa se enumeran en la sección pathMatchers de la respuesta.

      gcloud compute url-maps list
      gcloud compute url-maps describe URL_MAP_NAME
      
  2. Identifica una verificación de estado. Si es necesario, consulta las verificaciones de estado.

  3. Asocia la verificación de estado al servicio de backend. En los comandos siguientes, reemplaza BACKEND_SERVICE_NAME por el nombre del servicio de backend y HEALTH_CHECK_NAME por el nombre de la verificación de estado. Con estos comandos se reemplazan todas las verificaciones de estado asociadas al servicio de backend. En la mayoría de los casos, solo tendrás una verificación de estado asociada al servicio de backend.

    • A fin de cambiar la verificación de estado de un servicio de backend para un balanceador de cargas interno, usa el comando siguiente. Los servicios de backend para balanceadores de cargas internos son regionales, por lo que debes especificar REGION, además de su nombre.

      gcloud compute backend-services update BACKEND_SERVICE_NAME \
          --region REGION \
          --health-checks HEALTH_CHECK_NAME
      
    • Usa el comando siguiente a fin de cambiar la verificación de estado de un servicio de backend para los balanceadores de cargas TCP Proxy, SSL Proxy y HTTP(S):

      gcloud compute backend-services update BACKEND_SERVICE_NAME \
          --global \
          --health-checks HEALTH_CHECK_NAME
      

API

  1. Puedes enumerar servicios de backend con la llamada a la API backendServices.list.

  2. Consulta las verificaciones de estado.

  3. Para asociar una verificación de estado a un servicio de backend, usa una de estas llamadas a la API:

Verificaciones de estado heredadas para el balanceo de cargas de red

En esta sección, se describe cómo asociar una verificación de estado heredada a un grupo de destino para el balanceo de cargas de red. En esta sección, se supone que hiciste esto:

Para asociar una verificación de estado heredada a un balanceador de cargas de red nuevo, consulta cómo configurar el balanceo de cargas de red. Debes asociar una verificación de estado heredada al grupo de destino cuando creas un balanceador de cargas de red nuevo.

Console

Haz esto para asociar una verificación de estado a un balanceador de cargas de red existente:

  1. Ve a la página Balanceo de cargas de Google Cloud Platform Console.
    Ir a la página Balanceo de cargas
  2. Haz clic en un balanceador de cargas de red para ver sus detalles.
  3. Haz clic en Editar y, luego, en Configuración de backend.
  4. Elige una verificación de estado heredada en el menú Verificación de estado (solo se muestran las verificaciones de estado heredadas elegibles).
  5. Haz clic en Actualizar.

gcloud

Haz esto para asociar una verificación de estado a un balanceador de cargas de red existente:

  1. Identifica los grupos de destino. Los balanceadores de cargas de red tienen, al menos, un grupo de destino y pueden tener un grupo de copia de seguridad secundario.

    gcloud compute target-pools list
    
  2. Identifica una verificación de estado heredada con el protocolo HTTP. Si es necesario, consulta las verificaciones de estado heredadas.

  3. Asocia la verificación de estado heredada a los grupos de destino. En los comandos siguientes, reemplaza TARGET_POOL_NAME por el nombre del grupo de destino, REGION por la región y LEGACY_HEALTH_CHECK_NAME por el nombre de la verificación de estado heredada. La verificación de estado heredada debe usar el protocolo HTTP.

    • Usa este comando para quitar una verificación de estado HTTP heredada de un grupo de destino:

      gcloud compute target-pools remove-health-checks TARGET_POOL_NAME \
          --region REGION \
          --http-health-check LEGACY_HEALTH_CHECK_NAME
      
    • Usa este comando para agregar una verificación de estado HTTP heredada a un grupo de destino:

      gcloud compute target-pools add-health-checks TARGET_POOL_NAME \
          --region REGION \
          --http-health-check LEGACY_HEALTH_CHECK_NAME
      

API

  1. Puedes enumerar los grupos de destino con la llamada a la API targetPools.list.

  2. Observa verificaciones de estado heredadas y, además, identifica una verificación de estado HTTP heredada.

  3. Para asociar una verificación de estado HTTP heredada a un grupo de destino, usa la llamada a la API targetPools.addHealthCheck.

Soluciona problemas de verificaciones de estado mediante el bloqueo de rangos de direcciones IP

En ciertas circunstancias, es útil hacer que las verificaciones de estado fallen a propósito. Es posible que tengas que forzar una VM específica para que falle las verificaciones de estado como parte de una actividad de solución de problemas, o tal vez quieras que falle las verificaciones de estado como parte del procedimiento de apagado.

Puedes forzar el error de una verificación de estado o estado heredada si bloqueas de manera temporal el acceso a los rangos de IP de verificación de estado. En este ejemplo, se muestra cómo hacer fallar las verificaciones de estado con el software de firewall iptables que se ejecuta en una VM de Linux.

Para hacer que una VM falle los sondeos de verificación de estado y estado heredadas, conéctate a ella y ejecuta un comando iptables como el ejemplo siguiente y reemplaza HEALTH_CHECK_PORT por el número de puerto TCP apropiado. Si necesitas que una VM falle de manera deliberada mientras se apaga, puedes agregar comandos iptables como estos a una secuencia de comandos de apagado, seguida de un retraso apropiado según el intervalo de verificación y el umbral de mal estado de la verificación de estado.

$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 35.191.0.0/16 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 130.211.0.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 209.85.152.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 209.85.204.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset

Para quitar las reglas de iptables, reemplaza HEALTH_CHECK_PORT por el puerto TCP de la verificación de estado en los comandos siguientes y ejecútalos.

$ sudo iptables -D INPUT -m state --state NEW \
-s 35.191.0.0/16 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 130.211.0.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 209.85.152.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 209.85.204.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…