Crea verificaciones de estado

Google Cloud proporciona mecanismos de verificación de estado que determinan si las instancias de backend responden correctamente al tráfico. En este documento, se describe cómo crear y usar las verificaciones de estado para balanceadores de cargas y Traffic Director.

En esta página, se supone que estás familiarizado con los siguientes conceptos:

Protocolos, puertos y categorías de verificación de estado

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

Existen 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.

Traffic Director y 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 descripción general de las 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”.

Enumera las verificaciones de estado

Console

  1. Ve a la página Verificaciones de estado en Google Cloud Console.
    Ir a la página Verificaciones de estado
  2. Haz clic en una verificación de estado para ver los detalles.

gcloud

Para enumerar las verificaciones de estado, usa el comando compute health-checks list:

  • Para enumerar las verificaciones de estado globales, haz lo siguiente:

    gcloud compute health-checks list \
       --global
    
  • Para enumerar las verificaciones de estado regionales, reemplaza region-list por una lista delimitada por comas de las regiones de Google Cloud a consultar.

    gcloud compute health-checks list \
       --regions=region-list
    

Una vez que sepas el nombre y el alcance de una verificación de estado, usa el comando compute health-checks describe para ver la configuración actual.

  • Para describir una verificación de estado global, reemplaza name por su nombre.

    gcloud compute health-checks describe name \
       --global
    
  • Para describir una verificación de estado regional, reemplaza name por su nombre y region por la región en la que se encuentra.

    gcloud compute health-checks describe name \
       --region=region
    

API

Para enumerar las verificaciones de estado, usa estas llamadas a la API:

Para describir la configuración actual de una verificación de estado, usa estas llamadas a la API:

Crea verificaciones de estado

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

También puedes crear una verificación de estado sin importar la configuración del balanceador de cargas en Cloud Console. Esto es útil si necesitas crear la verificación de estado primero o usar una para varios balanceadores de cargas. Puedes crear una verificación de estado mediante Cloud Console, la herramienta de línea de comandos de gcloud o las API de REST.

Console

  1. Ve a la página Verificaciones de estado en Google Cloud Console.
    Ir a la página Verificaciones de estado
  2. Haz clic en Crear una verificación de estado.
  3. En la página Crea una verificación de estado, proporciona la siguiente información:
    • 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. Cuando creas una verificación de estado en Cloud Console, debes especificar el puerto mediante 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.
    • Ruta de solicitud 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. A fin de obtener más información, consulta Marcas adicionales para verificaciones de estado de HTTP, HTTPS y HTTP/2.
    • Solicitud y Respuesta: En los protocolos TCP y SSL, puedes especificar una string de texto ASCII para enviar una string de respuesta de texto esperada. A fin de obtener más información, consulta Marcas adicionales para verificaciones de estado de SSL y TCP.
    • 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 Google Cloud espera una respuesta a 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 se deben realizar de forma correcta 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.

gcloud

  • Para crear una verificación de estado global, usa el comando compute health-checks create adecuado:

    gcloud compute health-checks create protocol name \
        --global \
        --description=description \
        --check-interval=check-interval \
        --timeout=timeout \
        --healthy-threshold=healthy-threshold \
        --unhealthy-threshold=unhealthy-threshold \
        port specification \
        ...additional flags
    
  • Para crear una verificación de estado regional, usa el comando compute health-checks create adecuado:

    gcloud compute health-checks create protocol name \
        --region=region \
        --description=description \
        --check-interval=check-interval \
        --timeout=timeout \
        --healthy-threshold=healthy-threshold \
        --unhealthy-threshold=unhealthy-threshold \
        port specification \
        ...additional flags
    

En el ejemplo anterior, se ilustra lo siguiente:

  • protocol define el protocolo que se usa para la verificación de estado. Las opciones válidas son http, https, http2, ssl y tcp.
  • name es el nombre de la verificación de estado. Dentro de un proyecto determinado, cada verificación de estado global debe tener un nombre único, y las verificaciones de estado regionales deben tener nombres únicos dentro de una región determinada.
  • region: Todos los balanceadores de cargas, excepto los balanceadores de cargas de HTTP(S) internos, usan verificaciones de estado globales (--global). Los balanceadores de cargas de HTTP(S) internos usan verificaciones de estado regionales cuya región debe coincidir con la del servicio de backend.
  • description es una descripción opcional.
  • check-interval es la cantidad de tiempo desde el inicio de la conexión de un sistema de sondeo de verificación de estado hasta el inicio de la siguiente. Las unidades son segundos. Si se omite, Google Cloud usa un valor de 5s (5 segundos).
  • timeout es la cantidad de tiempo que Google Cloud espera una respuesta a un sondeo. El valor de timeout debe ser menor o igual que check-interval. Las unidades son segundos. Si se omite, Google Cloud 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 alguno, Google Cloud usa un límite predeterminado de 2.
  • port specification define la especificación de puerto mediante una de las marcas de especificación de puerto.
  • ...additional flags son otras marcas para especificar puertos y opciones específicas de protocol. Consulta Marcas adicionales para verificaciones de estado HTTP, HTTPS y HTTP/2 o Marcas adicionales para verificaciones de estado SSL y TCP.

API

Modifica las verificaciones de estado

No se puede convertir una verificación de estado en una verificación de estado heredada (o viceversa) mediante la modificación de la verificación de estado. Tampoco puedes cambiar el nombre o el alcance de una verificación de estado (por ejemplo, de global a regional).

Console

  1. Ve a la página Verificaciones de estado en Google Cloud Console.
    Ir a la página Verificaciones de estado
  2. Haz clic en una verificación de estado para ver los detalles.
  3. Si necesitas modificar la verificación de estado, haz clic en Editar y, luego, haz lo siguiente:
    • Realiza cambios en los parámetros según sea necesario.
    • Haz clic en Guardar.

gcloud

  1. Identifica el nombre y el alcance de la verificación de estado. Para obtener instrucciones, consulta Enumera verificaciones de estado.

  2. Excepto por el nombre, el protocolo y el alcance de una verificación de estado, puedes modificar cualquiera de las marcas comunes, las marcas de especificación de puerto y las marcas opcionales. Para modificar una verificación de estado existente, usa el comando compute health-checks update adecuado. Para las marcas que omites, se conservan los parámetros de configuración que se establecieron de forma previa.

    • Ejemplo de modificación de una verificación de estado global: Con el siguiente comando, se modifica una verificación de estado de HTTP global llamada hc-http-port-80 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 \
          --global \
          --check-interval=20s \
          --timeout=15s \
          --request-path="/health"
      
    • Ejemplo de modificación de una verificación de estado regional: Con el siguiente comando, se modifica una verificación de estado de TCP regional en us-west1 llamada hc-west1-tcp-ldap mediante el cambio de la especificación de puerto.

      gcloud compute health-checks update tcp hc-west1-tcp-ldap \
          --region=us-west1 \
          --port=631
      

API

  1. Identifica el nombre y el alcance de la verificación de estado. Consulta Enumera verificaciones de estado para obtener instrucciones.

  2. Excepto por el nombre, el protocolo y el alcance de una verificación de estado, puedes modificar cualquiera de las marcas comunes, las marcas de especificación de puerto y las marcas opcionales con estas llamadas a la API. Usa las llamadas a la API de patch para conservar la configuración ya establecida que no se determina de forma explícita en la solicitud.

Marcas adicionales

En esta sección, se describen marcas adicionales que puedes usar cuando creas o modificas una verificación de estado. Algunas marcas, como la especificación de puerto, deben configurarse mediante gcloud o la API.

Marcas de especificación de puerto

Si creas una verificación de estado mediante la herramienta de línea de comandos de gcloud o la API, tienes dos opciones para especificar el puerto de la verificación de estado. En la tabla siguiente, se muestran las opciones de especificación de puerto para combinaciones válidas de balanceadores de cargas y backend. El término grupo de instancias se refiere a grupos de instancias no administrados, administrados zonales o administrados regionales.

Cada verificación de estado solo puede usar un tipo de especificación de puerto.

Producto Tipo de backend Opciones de especificación de puerto
Balanceo de cargas de TCP/UDP interno Grupos de instancias --port: Especifica un puerto TCP por número, del 1 al 65535
No puedes usar la marca --use-serving-port para una verificación de estado asociada con un balanceador de cargas de TCP/UDP interno porque los servicios de backend para esos balanceadores no tienen una especificación de puerto.
Balanceo de cargas de HTTP(S) interno
Balanceo de cargas de proxy TCP
Balanceo de cargas de proxy SSL
Balanceo de cargas de HTTP(S) externo
Traffic Director
NEG zonales --port: Especifica un puerto TCP por número, del 1 al 65535
--use-serving-port: Usa el puerto de cada extremo en el grupo de extremos de red.
Grupos de instancias --port: Especifica un puerto TCP por número, del 1 al 65535
--use-serving-port: Usa el puerto con nombre del mismo grupo de instancias al que se suscribe el servicio de backend.

Si omites la especificación de puerto, Google Cloud usa los siguientes valores predeterminados:

  • Si el protocolo de verificación de estado es TCP o HTTP, usa --port=80.
  • Si el protocolo de verificación de estado es SSL, HTTPS o HTTP2, usa --port=443.
  • Si el protocolo de verificación de estado es GRPC, no hay un valor predeterminado implícito; debes incluir la especificación del puerto.

Marcas adicionales para las verificaciones de estado de 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 límite de estado.

gcloud compute health-checks create http-protocol hc-http-port-80 \
    common flags... \
    port specification \
    --host=host \
    --proxy-header=proxy-header \
    --request-path=request-path \
    --response=response
  • http-protocol puede ser http (HTTP/1.1 sin TLS), https (HTTP/1.1 con TLS) o http2 (HTTP/2 con TLS).
  • common flags... define las marcas comunes. Consulta Procedimiento de creación.
  • port specification define la especificación de puerto mediante una de las marcas de especificación de puerto.
  • host te permite proporcionar un encabezado HTTP 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, Google Cloud usa NONE. El valor de PROXY_V1 agrega el encabezado PROXY UNKNOWN\r\n.
  • request-path especifica la ruta de URL que usa Google Cloud 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 el contenido no admite la inversión; por ejemplo, los operadores como ! en HAProxy no están admitidos.

Si Google Cloud encuentra la string de respuesta esperada en cualquier lugar en los primeros 1,024 bytes del cuerpo de respuesta recibido, y el estado HTTP es 200 (OK), el sondeo se considera correcto.

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

Marcas adicionales 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 llamada hc-tcp-3268 mediante el puerto 3268 con los criterios predeterminados de intervalo, tiempo de espera y límite de estado.

gcloud compute health-checks create tcp hc-tcp-3268 \
    common flags... \
    port specification \
    --proxy-header=proxy-header \
    --request=request-string \
    --response=response-string
  • El protocolo puede ser tcp (en este ejemplo) o ssl.
  • common flags... define las marcas comunes. Consulta Procedimiento de creación.
  • port specification define la especificación de puerto mediante una de las marcas de especificación de puerto.
  • proxy-header debe ser NONE o PROXY_V1. Si se omite, Google Cloud 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 haya establecido 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 para el sondeo de verificación de estado. Si usas la marca --response, ya sea sola o junto con la marca --request, la respuesta que se muestra debe coincidir de manera exacta con la string de respuesta esperada.

Marca adicional para las verificaciones de estado de gRPC

El servidor de gRPC de backend debe implementar el servicio de estado de gRPC como se describe en el protocolo de verificación de estado de gRPC. Google Cloud envía un mensaje de HealthCheckRequest a tus backends mediante una llamada al método Check del servicio de estado en tu backend. El parámetro de servicio en la solicitud se configura como una string vacía, a menos que se especifique un nombre de servicio de gRPC.

Una verificación de estado de gRPC puede comprobar el estado de un servicio de gRPC. Puedes incluir una string de hasta 1,024 caracteres ASCII, que es el nombre de un servicio de gRPC específico que se ejecuta en una VM de backend o NEG. Si deseas hacerlo, usa la siguiente marca opcional para las verificaciones de estado de gRPC:

--grpc-service-name=GRPC_SERVICE_NAME

Por ejemplo, puedes tener los siguientes servicios y estados que el servidor de backend registra con el servicio de estado de gRPC de tu backend.

  • MyPackage.ServiceA con el estado de publicación SERVING
  • MyPackage.ServiceB con el estado de publicación NOT_SERVING
  • Nombre de servicio vacío con el estado de publicación NOT_SERVING

Si creas una verificación de estado en MyPackage.ServiceA, de la siguiente manera, el sondeo de verificación de estado muestra HEALTHY, porque el estado del servicio es SERVING.

gcloud beta compute health-checks create grpc MyGrpcHealthCheckServiceA \
    --grpc-service-name=MyPackage.ServiceA

Si creas una verificación de estado en MyPackage.ServiceB, el sondeo de verificación de estado muestra UNHEALTHY porque el estado del servicio es NOT_SERVING.

Si creas una verificación de estado en MyPackage.ServiceC, que no está registrado con el servicio de estado de gRPC, el sondeo de verificación de estado muestra el estado NOT_FOUND de gRPC, que es el equivalente a UNHEALTHY.

Si creas una verificación de estado en el nombre del servicio vacío, el sondeo de verificación de estado muestra el estado UNHEALTHY, porque el nombre del servicio vacío se registra con el estado NOT_SERVING.

Verificaciones de estado heredadas

En esta sección, se describe cómo enumerar, crear y modificar verificaciones de estado de HTTP heredadas y verificaciones de estado de HTTPS heredadas. Ten en cuenta que un balanceador de cargas de red solo puede usar una verificación de estado de HTTP heredada, no una de HTTPS heredada.

Enumera las verificaciones de estado heredadas

Console

  1. Ve a la página Verificaciones de estado en Google Cloud Console.
    Ir a la página Verificaciones de estado
  2. Haz clic en una verificación de estado heredada para ver los detalles.

gcloud

  1. Para enumerar las verificaciones de estado de HTTP heredadas, usa el comando compute http-health-checks list.

    gcloud compute http-health-checks list
    

    Para enumerar las verificaciones de estado de HTTPS heredadas, usa el comando compute https-health-checks list.

    gcloud compute https-health-checks list
    
  2. Para describir una verificación de estado de HTTP heredada, usa el comando compute http-health-checks describe y reemplaza name por su nombre.

    gcloud compute http-health-checks describe name
    

    Para describir una verificación de estado de HTTPS heredada, usa el comando compute https-health-checks describe y reemplaza name por su nombre.

    gcloud compute https-health-checks describe name
    

API

  1. Para enumerar las verificaciones de estado heredadas, haz lo siguiente:

  2. Para describir una verificación de estado heredada, haz lo siguiente:

Crea verificaciones de estado heredadas

Console

Aunque la página de verificaciones de estado de Cloud Console te permite editar las verificaciones de estado y las verificaciones de estado heredadas, no puedes crear una verificación de estado heredada nueva desde esa página.

Para crear una verificación de estado heredada, usa la página del balanceador de cargas de red de Cloud Console, las instrucciones de gcloud de esta sección o las de la API.

gcloud

Para crear una verificación de estado heredada, usa el comando compute http-health-checks create:

gcloud compute legacy-check-type create 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

En el ejemplo anterior, se ilustra lo siguiente:

  • legacy-check-type es http-health-checks para una verificación de estado de HTTP heredada o https-health-checks para una verificación de estado de HTTPS heredada. Si quieres crear la verificación de estado heredada para un balanceador de cargas de red, debes usar http-health-checks.
  • 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 son segundos. Si se omite, Google Cloud usa un valor de 5s (5 segundos).
  • timeout es la cantidad de tiempo que Google Cloud esperará una respuesta a un sondeo. El valor de timeout debe ser menor o igual que check-interval. Las unidades son segundos. Si se omite, Google Cloud 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 alguno, Google Cloud usa un límite 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, Google Cloud usa 80.
  • request-path especifica la ruta de URL que usa Google Cloud 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

Modifica las verificaciones de estado heredadas

Console

  1. Ve a la página Verificaciones de estado en Google Cloud Console.
    Ir a la página Verificaciones de estado
  2. Haz clic en una verificación de estado para ver sus detalles.
  3. Haz clic en Editar , realiza los cambios y, luego, haz clic en Guardar.

gcloud

  • Para modificar una verificación de estado de HTTP heredada, usa el comando compute http-health-checks update y reemplaza name por su nombre. Cuando se modifica una verificación de estado heredada con gcloud, se conserva la configuración ya establecida para las marcas que omites. Las ...other options son las opciones que se describen en Crea una verificación de estado heredada.

    gcloud compute http-health-checks update name \
      ...other options
    
  • Para modificar una verificación de estado de HTTPS heredada, usa el comando compute https-health-checks update y reemplaza name por su nombre. Cuando se modifica una verificación de estado heredada con gcloud, se conserva la configuración ya establecida para las marcas que omites. Las ...other options son las opciones que se describen en Crea una verificación de estado heredada.

    gcloud compute https-health-checks update name \
      ...other options
    

API

Puedes modificar cualquiera de las marcas usadas para crear una verificación de estado heredada, a excepción del nombre y del tipo. Las llamadas a la API patch conservan cualquier configuración ya establecida que no se determine de forma explícita en la solicitud de parche.

Reglas de firewall obligatorias

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 la Descripción general de las reglas de firewall y Configura las etiquetas de red.

Cada uno de estos ejemplos permite que todo el tráfico de TCP de los sistemas de verificación de estado de Google Cloud se aplique 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, esto permite el tráfico de TCP en el puerto 80, por lo que Google Cloud podría comunicarse con las VM mediante HTTP en el puerto 80, pero no podría comunicarse con ellas mediante HTTPS en el puerto 443.

Reglas de firewall para las verificaciones 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)

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

  • 35.191.0.0/16
  • 130.211.0.0/22

Solo para el balanceo de cargas HTTP(S) interno, el rango de IP de origen 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, Reglas para el balanceo de cargas de red.

Console

  1. Ve a la página Firewall en Google Cloud Console.
    Ir a la página 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.
    • Destinos: Elige Etiquetas de destino especificadas y, luego, ingresa etiquetas en el cuadro de texto Etiquetas de destino. Para este ejemplo, usa allow-health-checks.
    • Filtro de origen: Elige Rangos de IP.
    • Rangos de IP de origen: 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 conexiones de TCP entrantes de sistemas de verificación de estado de Google Cloud a instancias en la red de VPC con la etiqueta allow-health-checks. Reemplaza network-name por el nombre de la red de VPC.

    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 Firewall en Google Cloud Console.
    Ir a la página 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.
    • Destinos: Elige Etiquetas de destino especificadas y, luego, ingresa etiquetas en el cuadro de texto Etiquetas de destino. Para este ejemplo, usa allow-network-lb-health-checks.
    • Filtro de origen: Elige Rangos de IP.
    • Rangos de IP de origen: 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 conexiones de TCP entrantes de sistemas de verificación de estado de Google Cloud a instancias en la red de VPC con la etiqueta allow-network-lb-health-checks. Reemplaza network-name por el nombre de la red de VPC.

    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 verificaciones de estado con balanceadores de cargas y Traffic Director

En esta sección, se describen ciertas recomendaciones de verificación de estado y los requisitos que se deben cumplir antes de asociar una verificación de estado con un balanceador de cargas o Traffic Director.

Haz coincidir el protocolo

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 continuación, se mencionan ejemplos:

  • En el balanceo de cargas de 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 de TCP/UDP interno, tiene sentido que emplees una verificación de estado con el protocolo HTTP.

  • Un balanceador de cargas de red debe usar una verificación de estado de HTTP heredada. No puede usar una verificación de estado de HTTPS heredada ni ninguna verificación de estado moderna. 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.

  • 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 HTTP(S) o HTTP/2.

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 da por sentado que hiciste esto:

Para asociar una verificación de estado con un nuevo balanceador de cargas, ya sea de TCP/UDP interno, de proxy TCP, de proxy SSL o de HTTP(S) externo, consulta la guía de configuración del balanceador de cargas correspondiente.

Console

Para asociar una verificación de estado con un balanceador de cargas existente, ya sea de TCP/UDP interno, de proxy TCP, de proxy SSL o de HTTP(S) externo, haz lo siguiente:

  1. Ve a la página Balanceo de cargas en Google Cloud 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 con un servicio de backend existente, sigue estos pasos.

  1. Identifica el nombre y el alcance del servicio de backend. Los balanceadores de cargas de TCP/UDP interno, los balanceadores de cargas de proxy TCP y los balanceadores de cargas de proxy SSL tienen solo un backend por balanceador de cargas. Los balanceadores de cargas de HTTP(S) internos y externos tienen uno o más servicios de backend asociados con un solo mapa de URL.

    • A fin de enumerar los servicios de backend para los balanceadores de cargas de TCP/UDP internos, ejecuta el siguiente comando y reemplaza region-list por una lista delimitada por comas de las regiones de Google Cloud que se consultarán.

      gcloud compute backend-services list \
          --regions=region-list \
          --filter="loadBalancingScheme=INTERNAL"
      
    • Para enumerar los servicios de backend de los balanceadores de cargas de proxy TCP, ejecuta el siguiente comando. Los servicios de backend para los balanceadores de cargas de proxy TCP son siempre globales, sin importar el nivel de servicio de red.

      gcloud compute backend-services list \
          --global \
          --filter="loadBalancingScheme=EXTERNAL" \
          --filter="protocol=TCP"
      
    • A fin de enumerar los servicios de backend para los balanceadores de cargas de proxy SSL, ejecuta el siguiente comando. Los servicios de backend para los balanceadores de cargas de proxy SSL son siempre globales, sin importar el nivel de servicio de red.

      gcloud compute backend-services list \
          --global \
          --filter="loadBalancingScheme=EXTERNAL" \
          --filter="protocol=SSL"
      
    • A fin de identificar los servicios de backend para un balanceador de cargas de HTTP(S) externo, primero debes identificar un mapa de URL y, luego, describirlo. Los mapas de URL y los servicios de backend para balanceadores de cargas de HTTP(S) externos siempre son globales, sin importar el nivel de servicio de red. Reemplaza url-map-name por el nombre del mapa de URL. Los servicios de backend que usa el balanceador de cargas se enumeran en la respuesta.

      gcloud compute url-maps list \
          --global
      
      gcloud compute url-maps describe url-map-name \
          --global
      
    • A fin de identificar los servicios de backend para un balanceador de cargas de HTTP(S) interno, primero debes identificar un mapa de URL y, luego, describirlo. Los mapas de URL y los servicios de backend para balanceadores de cargas de HTTP(S) internos son regionales. Reemplaza region-list por una lista delimitada por comas de regiones de Google Cloud a consultar. Reemplaza url-map-name por el nombre del mapa de URL y region por la región. Los servicios de backend que usa el balanceador de cargas se enumeran en la respuesta.

      gcloud compute url-maps list \
          --regions=region-list
      
      gcloud compute url-maps describe url-map-name \
          --region=region
      
  2. Identifica una verificación de estado. Consulta Enumera las verificaciones de estado.

  3. Asocia una verificación de estado con el servicio de backend mediante el comando compute backend-services update. Cada servicio de backend debe hacer referencia a una sola verificación de estado. En los siguientes comandos, reemplaza backend-service-name por el nombre del servicio de backend, health-check-name por el nombre de la verificación de estado y, si es necesario, region por la región de Google Cloud del servicio de backend, la verificación de estado o ambas opciones.

    • Para cambiar la verificación de estado de un balanceador de cargas TCP/UDP interno: un servicio de backend del balanceador de cargas TCP/UDP interno es regional. Puede hacer referencia a una verificación de estado global o regional. En el siguiente ejemplo, se muestra una referencia de verificación de estado regional. Si usas una verificación de estado global con tu balanceador de cargas TCP/UDP interno, usa --global-health-checks en lugar de --health-checks-region.

      gcloud compute backend-services update backend-service-name \
          --region=region \
          --health-checks=health-check-name \
          --health-checks-region=region
      
    • Para cambiar la verificación de estado de un balanceador de cargas de proxy TCP, de proxy SSL o de HTTP(S) externo: El servicio de backend y la verificación de estado son globales para estos balanceadores de cargas. Un balanceador de cargas de HTTP(S) externo puede hacer referencia a más de una verificación de estado si hace referencia a más de un servicio de backend.

      gcloud compute backend-services update backend-service-name \
          --global \
          --health-checks health-check-name \
          --global-health-checks
      
    • Para cambiar la verificación de estado de un balanceador de cargas de HTTP(S) interno: El servicio de backend y la verificación de estado son regionales. Un balanceador de cargas de HTTP(S) interno puede hacer referencia a más de una verificación de estado si hace referencia a más de un servicio de backend.

      gcloud compute backend-services update backend-service-name \
          --region=region \
          --health-checks=health-check-name \
          --health-checks-region=region
      

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 Configura 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 en Google Cloud 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 mediante 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-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-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-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.

Comprueba el estado de la verificación de estado

Después de asociar una verificación de estado con un servicio de backend o un grupo de destino, puedes obtener el estado instantáneo de la verificación para los backends del balanceador de cargas.

Console

  1. Dirígete a la página de resumen del balanceo de cargas.
    Ir a la página Balanceo de cargas
  2. Haz clic en el nombre de un balanceador de cargas.
  3. En Backend, inspecciona la columna En buen estado. El estado se informa para cada grupo de instancias de backend o grupo de extremos de red.

gcloud

  • Para todos los balanceadores de cargas, excepto los balanceadores de cargas de red, identifica el nombre y el alcance del servicio de backend. Los balanceadores de cargas de TCP/UDP internos y los de HTTP(S) internos usan servicios de backend regionales. Los balanceadores de cargas de proxy TCP, de proxy SSL y de HTTP(S) externos usan servicios de backend globales.

    Usa el comando compute backend-services get-health y reemplaza name por el nombre del servicio de backend y region por su región, si es necesario.

    • Para obtener el estado instantáneo de un servicio de backend global, ejecuta este comando:

      gcloud compute backend-services get-health name \
          --global \
          --format=get(name, healthStatus)
      
    • Para obtener el estado instantáneo de un servicio de backend regional, ejecuta este comando:

      gcloud compute backend-services get-health name \
          --region=region \
          --format=get(name, healthStatus)
      
  • Para los balanceadores de cargas de red, identifica el nombre y la región del grupo de destino del balanceador de cargas. Luego, usa el comando compute target-pools get-health, y reemplaza name por el nombre del grupo de destino y region por la región.

    gcloud compute target-pools get-health name \
            --region=region \
        --format=get(name, healthStatus)
    

API

  • Para todos los balanceadores de cargas, excepto los balanceadores de cargas de red, identifica el nombre y el alcance del servicio de backend. Los balanceadores de cargas de TCP/UDP internos y los de HTTP(S) internos usan servicios de backend regionales. Los balanceadores de cargas de proxy TCP, de proxy SSL y de HTTP(S) externos usan servicios de backend globales.

  • Para balanceadores de cargas de red, usa targetPools.getHealth.