Configura el balanceo de cargas HTTP(S) interno con backends de grupos de instancias de VM

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

En este documento, se proporcionan instrucciones para configurar el balanceo de cargas de HTTP(S) interno en los servicios que se ejecutan en las VM de Compute Engine.

Si deseas configurar el balanceo de cargas de los servicios que se ejecutan en pods de GKE, consulta Balanceo de cargas nativo del contenedor con NEG independientes y la sección Vincula un balanceador de cargas de HTTP(S) interno a NEG independientes.

Para configurar el balanceo de cargas a fin de acceder a los servicios y las API de Google mediante Private Service Connect, consulta Configura Private Service Connect con controles de servicio de HTTP(S) de consumidor.

La configuración del balanceo de cargas de HTTP(S) interno tiene dos partes:

  • Realiza tareas de requisitos previos, como garantizar que las cuentas obligatorias tengan los permisos correctos y preparar la red de nube privada virtual (VPC).
  • Configura los recursos del balanceador de cargas.

Antes de seguir con esta guía, familiarízate con lo siguiente:

Permisos

Para seguir esta guía, debes poder crear instancias y modificar una red en un proyecto. Debes ser propietario o editor de un proyecto o tener todas las siguientes funciones de IAM de Compute Engine:

Tarea Función requerida
Crear redes, subredes y componentes del balanceador de cargas Administrador de red de Compute
Agrega y quita reglas de firewall Administrador de seguridad de Compute
Crea instancias Administrador de instancias de Compute

Si deseas obtener más información, consulta las siguientes guías:

Descripción general de la configuración

Puedes configurar el balanceo de cargas HTTP(S) interno como se describe en el siguiente flujo de configuración de alto nivel. Los pasos numerados se refieren a los números en el diagrama.

Componentes numerados de balanceo de cargas HTTP(S) interno (haz clic para ampliar)
Componentes numerados del balanceo de cargas de HTTP(S) interno (haz clic para ampliar)

Como se muestra en el diagrama, en este ejemplo se crea un balanceador de cargas de HTTP(S) interno en una red de VPC en la región us-west1, con un servicio de backend y dos grupos de backend.

En el diagrama se muestra lo siguiente:

  1. Una red de VPC con dos subredes:

    1. Una subred se usa para backends (grupos de instancias y NEG) y la regla de reenvío. Su rango de direcciones IP principal es 10.1.2.0/24.

    2. Una subred es una subred de solo proxy en la región us-west1. Debes crear una subred de solo proxy en cada región de una red de VPC en la que uses balanceadores de cargas de HTTP(S) internos. La subred de solo proxy de la región se comparte entre todos los balanceadores de cargas de HTTP(S) internos de la región. Las direcciones de origen de los paquetes enviados desde el balanceador de cargas de HTTP(S) interno a los backends de tu servicio se asignan desde la subred de solo proxy. En este ejemplo, el rango principal de direcciones IP de la subred de solo proxy para la región es 10.129.0.0/23, que es el tamaño de subred recomendado. Para obtener más información, consulta Subredes de solo proxy.

  2. Una regla de firewall que permite flujos de tráfico de subred de solo proxy en tu red. Esto significa que se agrega una regla que permita el tráfico de los puertos TCP 80, 443 y 8080 desde 10.129.0.0/23 (el rango de la subred de solo proxy en este ejemplo). Otra regla de firewall para las sondas de verificación de estado.

  3. Instancias de backend. En este diagrama de ejemplo, se muestran las siguientes implementaciones de backend:

    1. VM de Compute Engine
    2. Backends de Google Kubernetes Engine (GKE) agregados a grupos de extremos de red (NEG) independientes

  4. Grupos de instancias y NEG:

    1. Grupos de instancias administrados o no administrados para implementaciones de VM de Compute Engine
    2. NEG para implementaciones de GKE

    En cada zona, puedes tener una combinación de tipos de grupo de backend según los requisitos de tu implementación.

  5. Una verificación de estado regional que informa la preparación de tus backends.

  6. Un servicio de backend regional que supervisa el uso y el estado de los backends.

  7. Un mapa de URL regional que analiza la URL de una solicitud y reenvía las solicitudes a servicios de backend específicos en función del host y la ruta de acceso de la URL de la solicitud.

  8. Un proxy HTTP o HTTPS de destino regional, que recibe una solicitud del usuario y la reenvía al mapa de URL. Para HTTPS, configura un recurso de certificado SSL regional. El proxy de destino usa el certificado SSL para desencriptar el tráfico SSL si configuras el balanceo de cargas de HTTPS. El proxy de destino puede reenviar tráfico a tus instancias mediante HTTP o HTTPS.

  9. Una regla de reenvío, que tiene la dirección IP interna de tu balanceador de cargas, para reenviar cada solicitud entrante al proxy de destino.

    La dirección IP interna asociada con la regla de reenvío puede provenir de cualquier subred en la misma red y región. Ten en cuenta las siguientes condiciones:

    • La dirección IP puede (pero no es necesario) provenir de la misma subred que los grupos de instancias de backend.
    • La dirección IP no debe provenir de la subred de solo proxy reservada que tiene la marca --purpose configurada como REGIONAL_MANAGED_PROXY.
    • Si deseas compartir la dirección IP interna con varias reglas de reenvío, configura la marca --purpose de la dirección IP como SHARED_LOADBALANCER_VIP.

Configura la red y las subredes

Necesitas una red de VPC con dos subredes: una para los backends del balanceador de cargas y la otra para los proxies del balanceador de cargas. Un balanceador de cargas de HTTP(S) interno es regional. El tráfico dentro de la red de VPC se enruta al balanceador de cargas si la fuente de tráfico está en una subred en la misma región que el balanceador de cargas.

Este ejemplo usa la siguiente red de VPC, región y subredes:

  • Red. Es una red de VPC de modo personalizado con el nombre lb-network.

  • Subred para backends. Una subred llamada backend-subnet en la región us-west1 usa 10.1.2.0/24 en su rango de IP principal.

  • Subred para proxies. Una subred llamada proxy-only-subnet en la región us-west1 usa 10.129.0.0/23 en su rango de IP principal.

Para demostrar el acceso global, en este ejemplo, se crea también una segunda VM de cliente de prueba en una región y una subred diferentes:

  • Región: europe-west1
  • Subred: europe-subnet, con el rango de direcciones IP principales 10.3.4.0/24

Configura la red y las subredes

Consola

  1. En la consola de Google Cloud, ve a la página Redes de VPC.

    Ir a las redes de VPC

  2. Haz clic en Crear red de VPC.

  3. En Nombre, ingresa lb-network.

  4. En la sección Subredes, establece Modo de creación de subred como Personalizado.

  5. Crea una subred para los backends del balanceador de cargas. En la sección Nueva subred, ingresa la siguiente información:

    • Nombre: backend-subnet
    • Región: us-west1
    • Rangos de direcciones IP: 10.1.2.0/24

  6. Haga clic en Listo.

  7. Haz clic en Agregar subred.

  8. Crea una subred para demostrar el acceso global. En la sección Nueva subred, ingresa la siguiente información:

    • Nombre: europe-subnet
    • Región: europe-west1
    • Rangos de direcciones IP: 10.3.4.0/24

  9. Haz clic en Listo.

  10. Haz clic en Crear.

gcloud

  1. Crea la red de VPC personalizada con el comando gcloud compute networks create:

    gcloud compute networks create lb-network --subnet-mode=custom

  2. Crea una subred en la red lb-network en la región us-west1 con el comando gcloud compute networks subnets create:

    gcloud compute networks subnets create backend-subnet \
    --network=lb-network \
    --range=10.1.2.0/24 \
    --region=us-west1

  3. Crea una subred en la red lb-network en la región europe-west1 con el comando gcloud compute networks subnets create:

    gcloud compute networks subnets create europe-subnet \
    --network=lb-network \
    --range=10.3.4.0/24 \
    --region=europe-west1

API

Realiza una solicitud POST al método networks.insert. Reemplaza PROJECT_ID con el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
 "routingConfig": {
   "routingMode": "REGIONAL"
 },
 "name": "lb-network",
 "autoCreateSubnetworks": false
}

Realiza una solicitud POST al método subnetworks.insert. Reemplaza PROJECT_ID con el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks

{
 "name": "backend-subnet",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/us-west1",
}

Realiza una solicitud POST al método subnetworks.insert. Reemplaza PROJECT_ID con el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/europe-west1/subnetworks

{
 "name": "europe-subnet",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "ipCidrRange": "10.3.4.0/24",
 "region": "projects/PROJECT_ID/regions/europe-west1",
}

Configura la subred de solo proxy

Esta subred de solo proxy es para todos los balanceadores de cargas regionales basados en Envoy en la región us-west1 de lb-network.

Console

Si usas la consola de Google Cloud, puedes esperar y crear la subred de solo proxy más adelante en la página Balanceo de cargas.

Si quieres crear la subred de solo proxy ahora, sigue estos pasos:

  1. En la consola de Google Cloud, ve a la página Redes de VPC.

    Ir a las redes de VPC

  2. Haz clic en el nombre de la red de VPC: lb-network.

  3. Haz clic en Agregar subred.

  4. En Nombre, ingresa proxy-only-subnet.

  5. En Región, selecciona us-west1.

  6. Configura Propósito como Proxy administrado regional.

  7. En Rango de direcciones IP, ingresa 10.129.0.0/23.

  8. Haga clic en Agregar.

gcloud

Crea la subred de solo proxy con el comando gcloud compute networks subnets create.

gcloud compute networks subnets create proxy-only-subnet \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/23

API

Crea la subred de solo proxy con el método subnetworks.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "region": "projects/PROJECT_ID/regions/us-west1",
  "purpose": "REGIONAL_MANAGED_PROXY",
  "role": "ACTIVE"
}

Configura reglas de firewall

En este ejemplo, se usan las siguientes reglas de firewall:

  • fw-allow-ssh. Es una regla de entrada, aplicable a las instancias con balanceo de cargas, y que permite la conectividad SSH entrante en el puerto TCP 22 desde cualquier dirección. Puedes elegir un rango de IP de origen más restrictivo para esta regla; por ejemplo, puedes especificar solo los rangos de IP del sistema desde el que inicias sesiones SSH. En este ejemplo, se usa la etiqueta de destino allow-ssh para identificar las VMs a las que se aplica la regla de firewall.

  • fw-allow-health-check. Una regla de entrada aplicable a las instancias con balanceo de cargas y que permite todo el tráfico de TCP de los sistemas de verificación de estado de Google Cloud (en 130.211.0.0/22 y 35.191.0.0/16). En este ejemplo, se usa la etiqueta de destino load-balanced-backend para identificar las VMs a las que se aplica la regla de firewall.

  • fw-allow-proxies. Es una regla de entrada, aplicable a las instancias con balanceo de cargas, que permite el tráfico de TCP en los puertos 80, 443 y 8080, y desde los proxies administrados del balanceador de cargas de HTTP(S) interno. En este ejemplo, se usa la etiqueta de destino load-balanced-backend para identificar las VMs a las que se aplica la regla de firewall.

Sin estas reglas de firewall, la regla predeterminada de denegación de entrada bloquea el tráfico entrante a las instancias de backend.

Las etiquetas de destino definen las instancias de backend. Sin las etiquetas de destino, las reglas de firewall se aplican a todas las instancias de backend en la red de VPC. Cuando crees las VM de backend, asegúrate de incluir las etiquetas de destino especificadas, como se muestra en Crea un grupo de instancias administrado.

Console

  1. En la consola de Google Cloud, ve a la página Reglas de firewall.

    Ir a Reglas de firewall

  2. Haz clic en Crear regla de firewall para crear la regla que permite conexiones SSH entrantes:

    • Nombre: fw-allow-ssh
    • Red: lb-network
    • Dirección del tráfico: Entrada
    • Acción en caso de coincidencia: Permitir
    • Destinos: Etiquetas de destino especificadas
    • Etiquetas de destino: allow-ssh
    • Filtro de fuente: Rangos de IPv4
    • Rangos de IPv4 de origen: 0.0.0.0/0
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Selecciona la casilla de verificación TCP y, luego, ingresa 22 para el número de puerto.

  3. Haga clic en Crear.

  4. Haz clic en Crear regla de firewall por segunda vez para crear la regla que permita las verificaciones de estado de Google Cloud:

    • Nombre: fw-allow-health-check
    • Red: lb-network
    • Dirección del tráfico: Entrada
    • Acción en caso de coincidencia: Permitir
    • Destinos: Etiquetas de destino especificadas
    • Etiquetas de destino: load-balanced-backend
    • Filtro de fuente: Rangos de IPv4
    • Rangos de IPv4 de origen: 130.211.0.0/22 y 35.191.0.0/16
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Selecciona la casilla de verificación TCP y, luego, ingresa 80 para el número de puerto.
        Como práctica recomendada, limita esta regla solo a los protocolos y puertos que coincidan con los que usa tu verificación de estado. Si usas tcp:80 en el protocolo y el puerto, Google Cloud puede usar HTTP en el puerto 80 a fin de contactar las VM, pero no puede usar HTTPS en el puerto 443 para comunicarse con ellas.

  5. Haga clic en Crear.

  6. Haz clic en Crear regla de firewall por tercera vez para crear la regla a fin de permitir que los servidores proxy del balanceador de cargas conecten los backends:

    • Nombre: fw-allow-proxies
    • Red: lb-network
    • Dirección del tráfico: Entrada
    • Acción en caso de coincidencia: Permitir
    • Destinos: Etiquetas de destino especificadas
    • Etiquetas de destino: load-balanced-backend
    • Filtro de fuente: Rangos de IPv4
    • Rangos de IPv4 de origen: 10.129.0.0/23
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Selecciona la casilla de verificación TCP y, luego, ingresa 80, 443, 8080 para los números de puerto.

  7. Haga clic en Crear.

gcloud

  1. Crea la regla de firewall fw-allow-ssh para permitir la conectividad SSH a las VM con la etiqueta de red allow-ssh. Cuando omites source-ranges, Google Cloud interpreta que la regla significa cualquier fuente.

    gcloud compute firewall-rules create fw-allow-ssh \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  2. Crea la regla fw-allow-health-check para permitir las verificaciones de estado de Google Cloud. Este ejemplo permite todo el tráfico de TCP proveniente de la verificación de estado. Sin embargo, puedes configurar un conjunto más limitado de puertos según tus necesidades.

    gcloud compute firewall-rules create fw-allow-health-check \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp

  3. Crea la regla fw-allow-proxies para permitir que los proxies del balanceador de cargas de HTTP(S) interno se conecten con los backends. Configura source-ranges en los rangos asignados de tu subred de solo proxy, por ejemplo, 10.129.0.0/23.

    gcloud compute firewall-rules create fw-allow-proxies \
  --network=lb-network \
  --action=allow \
  --direction=ingress \
  --source-ranges=source-range \
  --target-tags=load-balanced-backend \
  --rules=tcp:80,tcp:443,tcp:8080

API

Crea la regla de firewall fw-allow-ssh mediante una solicitud POST al método firewalls.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-allow-ssh",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "sourceRanges": [
   "0.0.0.0/0"
 ],
 "targetTags": [
   "allow-ssh"
 ],
 "allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [
      "22"
    ]
  }
 ],
"direction": "INGRESS"
}

Crea la regla de firewall fw-allow-health-check mediante una solicitud POST al método firewalls.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-allow-health-check",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "sourceRanges": [
   "130.211.0.0/22",
   "35.191.0.0/16"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   }
 ],
 "direction": "INGRESS"
}

Crea la regla de firewall fw-allow-proxies a fin de permitir el tráfico de TCP dentro de la subred de proxy para el método firewalls.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-allow-proxies",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "sourceRanges": [
   "10.129.0.0/23"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "80"
     ]
   },
 {
     "IPProtocol": "tcp",
     "ports": [
       "443"
     ]
   },
   {
     "IPProtocol": "tcp",
     "ports": [
       "8080"
     ]
   }
 ],
 "direction": "INGRESS"
}

Configura el balanceo de cargas HTTP(S) interno con un servicio basado en VM

En esta sección, se muestra la configuración que se requiere para los servicios que se ejecutan en las VMs de Compute Engine. Las VM cliente se conectan a la dirección IP y al puerto que configuras en la regla de reenvío. Cuando las aplicaciones cliente envían tráfico a esta dirección IP y al puerto, sus solicitudes se reenvían a tus máquinas virtuales (VM) de backend según el mapa de URL del balanceador de cargas de HTTP(S) interno.

El ejemplo en esta página configura de manera explícita una dirección IP interna reservada para la regla de reenvío del balanceador de cargas HTTP(S) interno, en lugar de permitir que se asigne una dirección IP interna efímera. Recomendamos reservar direcciones IP para las reglas de reenvío.

Para la dirección IP de la regla de reenvío, usa backend-subnet. Si intentas usar la subred de solo proxy, la creación de la regla de reenvío fallará.

Cree un grupo de instancias administrado

En esta sección, se muestra cómo crear una plantilla y un grupo de instancias administrado. El grupo de instancias administrado proporciona instancias de VM que ejecutan los servidores de backend de un balanceador de cargas HTTP(S) interno de ejemplo. En tu grupo de instancias, puedes definir un servicio HTTP y asignar un nombre al puerto pertinente. El servicio de backend del balanceador de cargas reenvía el tráfico a los puertos con nombre. Las cargas del tráfico de los clientes se balancean a servidores de backend. A modo de demostración, los backends entregan sus propios nombres de host.

Consola

  1. Cree una plantilla de instancias. En la consola de Google Cloud, ve a la página Plantillas de instancia.

    Ir a Plantillas de instancia

    1. Haga clic en Crear plantilla de instancias.
    2. En Nombre, ingresa l7-ilb-backend-template.
    3. Asegúrate de que el disco de arranque esté configurado como una imagen de Debian, como Debian GNU/Linux 10 (buster). En estas instrucciones, se usan comandos que solo están disponibles en Debian, como apt-get.
    4. Haga clic en Opciones avanzadas.
    5. Haz clic en Herramientas de redes y configura los siguientes campos:
      1. En Etiquetas de red, ingresa allow-ssh y load-balanced-backend.
      2. En Interfaces de red, selecciona lo siguiente:
        • Red: lb-network
        • Subred: backend-subnet

    6. Haga clic en Administración. Ingresa la siguiente secuencia de comandos en el campo Secuencia de comandos de inicio.

      #! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://metadata.google.internal/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2

    7. Haz clic en Crear.

  2. Cree un grupo de instancias administrado. En la consola de Google Cloud, ve a la página Grupos de instancias.

    Ir a Grupos de instancias

    1. Haga clic en Crear grupo de instancias.
    2. Selecciona Nuevo grupo de instancias administrado (sin estado). Para obtener más información, consulta MIG sin estado o con estado.
    3. En Nombre, ingresa l7-ilb-backend-example.
    4. En Ubicación, selecciona Zona única.
    5. En Región, selecciona us-west1.
    6. En Zona, selecciona us-west1-a.
    7. En Plantilla de instancias, selecciona l7-ilb-backend-template.

    8. Especifica la cantidad de instancias que quieres crear en el grupo.

      En este ejemplo, especifica las siguientes opciones en Ajuste de escala automático:

      • En Modo de ajuste de escala automático, selecciona Off:do not autoscale.
      • En Cantidad máxima de instancias, ingresa 2.

      De manera opcional, en la sección de Ajuste de escala automático de la IU, puedes configurar el grupo de instancias para que agregue o quite instancias de forma automática en función del uso de CPU de la instancia.

    9. Haga clic en Crear.

gcloud

En las instrucciones de gcloud que se incluyen en esta guía, se supone que usas Cloud Shell o algún otro entorno con bash instalado.

  1. Crea una plantilla de instancias de VM con el servidor de HTTP con el comando gcloud compute instance-templates create.

    gcloud compute instance-templates create l7-ilb-backend-template \
--region=us-west1 \
--network=lb-network \
--subnet=backend-subnet \
--tags=allow-ssh,load-balanced-backend \
--image-family=debian-10 \
--image-project=debian-cloud \
--metadata=startup-script='#! /bin/bash
  apt-get update
  apt-get install apache2 -y
  a2ensite default-ssl
  a2enmod ssl
  vm_hostname="$(curl -H "Metadata-Flavor:Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/name)"
  echo "Page served from: $vm_hostname" | \
  tee /var/www/html/index.html
  systemctl restart apache2'

  2. Crea un grupo de instancias administrado en la zona con el comando gcloud compute instance-groups managed create.

    gcloud compute instance-groups managed create l7-ilb-backend-example \
    --zone=us-west1-a \
    --size=2 \
    --template=l7-ilb-backend-template

API

Crea la plantilla de instancias con el método instanceTemplates.insert y reemplaza PROJECT_ID por el ID de tu proyecto.


POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates
{
  "name":"l7-ilb-backend-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
            \\\nhttp://metadata.google.internal/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/lb-network",
         "subnetwork":"regions/us-west1/subnetworks/backend-subnet",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-10"
         },
         "autoDelete":true
       }
     ]
  }
}

Crea un grupo de instancias administrado en cada zona con el método instanceGroupManagers.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers
{
  "name": "l7-ilb-backend-example",
  "zone": "projects/PROJECT_ID/zones/us-west1-a",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/l7-ilb-backend-template",
  "baseInstanceName": "l7-ilb-backend-example",
  "targetSize": 2
}

Configura el balanceador de cargas

En este ejemplo, se muestra cómo crear los siguientes recursos del balanceador de cargas de HTTP(S) interno:

  • Verificación de estado de HTTP
  • Servicio de backend con un grupo de instancias administrado como backend
  • Un mapa de URL
    • Asegúrate de hacer referencia a un mapa de URL regional si se define una región para el proxy de HTTP(S) de destino. Un mapa de URL regional enruta las solicitudes a un servicio de backend regional en función de las reglas que definas para el host y la ruta de acceso de una URL entrante. Solo se puede hacer referencia a un mapa de URL regional mediante una regla regional de proxy de destino en la misma región.
  • Certificado SSL (para HTTPS)
  • Proxy de destino
  • Regla de reenvío

Para la dirección IP de la regla de reenvío, usa backend-subnet. Si intentas usar la subred de solo proxy, la creación de la regla de reenvío fallará.

Disponibilidad del proxy

En ocasiones, las regiones de Google Cloud no tienen suficiente capacidad de proxy para un nuevo balanceador de cargas. Si esto sucede, la consola de Google Cloud muestra un mensaje de advertencia de disponibilidad del proxy cuando creas el balanceador de cargas. Para resolver este problema, puedes realizar una de las siguientes acciones:

  • Selecciona una región diferente para el balanceador de cargas. Esta puede ser una opción práctica si tienes backends en otra región.
  • Selecciona una red de VPC que ya tenga asignada una subred de solo proxy.

  • Espera a que se resuelva el problema de capacidad.

Consola

Selecciona un tipo de balanceador de cargas

  1. En la consola de Google Cloud, ve a la página Balanceo de cargas.

    Ir a Balanceo de cargas

  2. En la sección Balanceo de cargas de HTTP(S), haz clic en Iniciar configuración.

  3. En la sección Orientado a Internet o solo interno selecciona Solo entre mis VMs. Esta configuración significa que el balanceador de cargas es interno.

  4. Haga clic en Continuar.

Prepara el balanceador de cargas

  1. Para el Nombre del balanceador de cargas, ingresa l7-ilb-map.
  2. En Región, selecciona us-west1.
  3. En Red, selecciona lb-network.

Reserva una subred de solo proxy

Para el balanceo de cargas de HTTP(S) interno, reserva una subred de proxy:

  1. Haz clic en Reservar una subred.
  2. En Nombre, ingresa proxy-only-subnet.
  3. En Rango de direcciones IP, ingresa 10.129.0.0/23.
  4. Haga clic en Agregar.

Configura el servicio de backend

  1. Haz clic en Configuración de backend.
  2. En el menú Crear o seleccionar servicios de backend, selecciona Crear un servicio de backend.
  3. Configura el nombre del servicio de backend como l7-ilb-backend-service.
  4. Configura el Tipo de backend como grupo de instancias.
  5. En la sección Nuevo backend, sigue estos pasos:
    1. Establece Grupo de instancias en l7-ilb-backend-example.
    2. Establece Números de puerto en 80.
    3. Establece el campo Modo de balanceo en Uso.
    4. Haga clic en Listo.
  6. En el menú desplegable Verificación de estado, haz clic en Crear una verificación de estado con los siguientes parámetros:
    1. Nombre: l7-ilb-basic-check
    2. Protocolo: HTTP
    3. Puerto: 80
    4. Haz clic en Guardar.
  7. Haga clic en Crear.

Configura el mapa de URL

  1. Haz clic en Reglas de host y ruta.

  2. En Modo, selecciona Regla sencilla de host y ruta de acceso.

  3. Asegúrate de que l7-ilb-backend-service sea el único servicio de backend para los hosts y rutas de acceso no coincidentes.

Para obtener información sobre la administración del tráfico, consulta Configura la administración del tráfico.

Configura el frontend

Para HTTP:

  1. Haga clic en Configuración de frontend.
  2. Configura el nombre de la regla de reenvío como l7-ilb-forwarding-rule.
  3. Establece el Protocolo en HTTP.
  4. Establece Subred en backend-subnet.
  5. Configura el Puerto en 80.
  6. En el menú desplegable Dirección IP, selecciona Crear dirección IP e ingresa los siguientes valores:
    1. Nombre: l7-ilb-ip
    2. Dirección IP estática: permíteme elegir
    3. Dirección IP personalizada: 10.1.2.99
    4. Haga clic en Reservar.
  7. Haga clic en Listo.

Para HTTPS:

Si usas HTTPS entre el cliente y el balanceador de cargas, necesitas uno o más recursos de certificado SSL para configurar el proxy. Para obtener información sobre cómo crear recursos de certificados SSL, consulta Certificados SSL. Por el momento, los certificados administrados por Google no son compatibles con los balanceadores de cargas de HTTP(S) internos.

  1. Haga clic en Configuración de frontend.
  2. Configura el nombre de la regla de reenvío como l7-ilb-forwarding-rule.
  3. Establece el Protocolo en HTTPS (includes HTTP/2).
  4. Configura la Subred como backend-subnet.
  5. Asegúrate de que el Puerto esté establecido en 443 para permitir el tráfico HTTPS.
  6. En el menú desplegable Dirección IP, selecciona Crear dirección IP e ingresa los siguientes valores:
    1. Nombre: l7-ilb-ip
    2. Dirección IP estática: permíteme elegir
    3. Dirección IP personalizada: 10.1.2.99
    4. Haga clic en Reservar.
  7. Haz clic en el menú desplegable Certificado.
    1. Si ya tienes un recurso de certificado SSL autoadministrado que deseas usar como certificado SSL principal, selecciónalo en la lista.
    2. De lo contrario, selecciona Crear un nuevo certificado.
      1. Configura el nombre del certificado como l7-ilb-cert.
      2. En los campos correspondientes, sube los archivos con formato PEM:
        • Certificado de clave pública
        • Cadena de certificado
        • Clave privada
      3. Haz clic en Crear.
  8. Para agregar otros recursos de certificado, además del recurso de certificado SSL principal, haz lo siguiente:
    1. Haz clic en Agregar certificado.
    2. Selecciona un certificado de la lista Certificados o haz clic en Crear un certificado nuevo y sigue las instrucciones anteriores.
  9. Selecciona una política de SSL de la lista Política de SSL. Si no creaste ninguna política de SSL, se aplica una política de SSL de GCP predeterminada.
  10. Haga clic en Listo.

Revisa la configuración

  1. Haz clic en Revisar y finalizar.
  2. Revisa la configuración del balanceador de cargas.
  3. Opcional: Haz clic en Código equivalente a fin de ver la solicitud a la API de REST que se usará para crear el balanceador de cargas.
  4. Haz clic en Crear.

gcloud

  1. Define la verificación de estado de HTTP con el comando gcloud compute health-checks create http.

    gcloud compute health-checks create http l7-ilb-basic-check \
   --region=us-west1 \
   --use-serving-port

  2. Define el servicio de backend con el comando gcloud compute backend-services create.

    gcloud compute backend-services create l7-ilb-backend-service \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --health-checks=l7-ilb-basic-check \
  --health-checks-region=us-west1 \
  --region=us-west1

  3. Agrega backends al servicio de backend con el comando gcloud compute backend-services add-backend.

    gcloud compute backend-services add-backend l7-ilb-backend-service \
  --balancing-mode=UTILIZATION \
  --instance-group=l7-ilb-backend-example \
  --instance-group-zone=us-west1-a \
  --region=us-west1

  4. Crea el mapa de URL con el comando gcloud compute url-maps create.

    gcloud compute url-maps create l7-ilb-map \
  --default-service=l7-ilb-backend-service \
  --region=us-west1

  5. Crea el proxy de destino.

    Para HTTP:

    Para un balanceador de cargas de HTTP interno, crea el proxy de destino con el comando gcloud compute target-http-proxies create.

    gcloud compute target-http-proxies create l7-ilb-proxy \
  --url-map=l7-ilb-map \
  --url-map-region=us-west1 \
  --region=us-west1

    Para HTTPS:

    Para obtener información sobre cómo crear recursos de certificados SSL, consulta Certificados SSL. Por el momento, los certificados administrados por Google no son compatibles con los balanceadores de cargas de HTTP(S) internos.

    Asigna tus rutas de archivos a nombres de variables.

    export LB_CERT=path to PEM-formatted file

    export LB_PRIVATE_KEY=path to PEM-formatted file

    Crea un certificado SSL regional con el comando gcloud compute ssl-certificates create.

    gcloud compute ssl-certificates create l7-ilb-cert \
  --certificate=$LB_CERT \
  --private-key=$LB_PRIVATE_KEY \
  --region=us-west1

    Usa el certificado SSL regional para crear un proxy de destino con el comando gcloud compute target-https-proxies create.

    gcloud compute target-https-proxies create l7-ilb-proxy \
  --url-map=l7-ilb-map \
  --region=us-west1 \
  --ssl-certificates=l7-ilb-cert

  6. Crea la regla de reenvío.

    Para redes personalizadas, debes hacer referencia a la subred en la regla de reenvío. Ten en cuenta que esta es la subred de VM, no la subred de proxy.

    Para HTTP:

    Usa el comando gcloud compute forwarding-rules create con las marcas correctas.

    gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=lb-network \
  --subnet=backend-subnet \
  --address=10.1.2.99 \
  --ports=80 \
  --region=us-west1 \
  --target-http-proxy=l7-ilb-proxy \
  --target-http-proxy-region=us-west1

    Para HTTPS:

    Crea la regla de reenvío con el comando gcloud compute forwarding-rules create con las marcas correctas.

    gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=lb-network \
  --subnet=backend-subnet \
  --address=10.1.2.99 \
  --ports=443 \
  --region=us-west1 \
  --target-https-proxy=l7-ilb-proxy \
  --target-https-proxy-region=us-west1

API

Para crear la verificación de estado, realiza una solicitud POST al método regionHealthChecks.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/{region}/healthChecks

{
"name": "l7-ilb-basic-check",
"type": "HTTP",
"httpHealthCheck": {
  "portSpecification": "USE_SERVING_PORT"
}
}

Para crear el servicio de backend regional, realiza una solicitud POST al método regionBackendServices.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices

{
"name": "l7-ilb-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/us-west1-a/instanceGroups/l7-ilb-backend-example",
    "balancingMode": "UTILIZATION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/us-west1/healthChecks/l7-ilb-basic-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

Para crear el mapa de URL, realiza una solicitud POST al método regionUrlMaps.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/urlMaps

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/regions/us-west1/backendServices/l7-ilb-backend-service"
}

Para HTTP:

Para crear el proxy HTTP de destino, realiza una solicitud POST al método regionTargetHttpProxies.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/targetHttpProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map",
"region": "us-west1"
}

Para crear la regla de reenvío, realiza una solicitud POST al método forwardingRules.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
"name": "l7-ilb-forwarding-rule",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/regions/us-west1/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/us-west1/subnetworks/backend-subnet",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"networkTier": "PREMIUM"
}

Para HTTPS:

Lee el certificado y los archivos de claves privadas y, luego, crea el certificado SSL. En el siguiente ejemplo, se muestra cómo hacer esto con Python.

compute/load_balancing/create_regional_certificate.py 
from pprint import pprint
from typing import Union

from googleapiclient import discovery

def create_regional_certificate(
    project_id: str,
    region: str,
    certificate_file: Union[str, Path],
    private_key_file: Union[str, Path],
    certificate_name: str,
    description: str = "Certificate created from a code sample."
) -> None:
    """
    Create a regional SSL self-signed certificate within your Google Cloud project.

    Args:
        project_id: project ID or project number of the Cloud project you want to use.
        region: name of the region you want to use.
        certificate_file: path to the file with the certificate you want to create in your project.
        private_key_file: path to the private key you used to sign the certificate with.
        certificate_name: name for the certificate once it's created in your project.
        description: description of the certificate.
    """
    service = discovery.build("compute", "v1")

    # Read the cert into memory
    with open(certificate_file) as f:
        _temp_cert = f.read()

    # Read the private_key into memory
    with open(private_key_file) as f:
        _temp_key = f.read()

    # Now that the certificate and private key are in memory, you can create the
    # certificate resource
    ssl_certificate_body = {
        "name": certificate_name,
        "description": description,
        "certificate": _temp_cert,
        "privateKey": _temp_key,
    }
    request = service.regionSslCertificates().insert(
        project=project_id, region=region, body=ssl_certificate_body
    )
    response = request.execute()
    pprint(response)

Para crear el proxy de HTTPS de destino, realiza una solicitud POST al método regionTargetHttpsProxies.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/regionTargetHttpsProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/regions/us-west1/urlMaps/l7-ilb-map",
"sslCertificates": /projects/PROJECT_ID/regions/us-west1/sslCertificates/SSL_CERT_NAME
}

Para crear la regla de reenvío, realiza una solicitud POST al método forwardingRules.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
"name": "l7-ilb-forwarding-rule",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/regions/us-west1/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/us-west1/subnetworks/backend-subnet",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"networkTier": "PREMIUM",
}

Prueba el balanceador de cargas

Crea una instancia de VM para probar la conectividad

Consola

  1. En la consola de Google Cloud, ve a la página Instancias de VM.

    Ir a Instancias de VM

  2. Haga clic en Crear instancia.

  3. Establece el Nombre como l7-ilb-client-us-west1-a.

  4. Establece la Zona en us-west1-a.

  5. Haga clic en Opciones avanzadas.

  6. Haz clic en Herramientas de redes y configura los siguientes campos:

    1. En Etiquetas de red, ingresa allow-ssh.
    2. En Interfaces de red, selecciona lo siguiente:
      1. Red: lb-network
      2. Subred: backend-subnet

  7. Haz clic en Crear.

gcloud 

gcloud compute instances create l7-ilb-client-us-west1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --network=lb-network \
    --subnet=backend-subnet \
    --zone=us-west1-a \
    --tags=allow-ssh

Envía tráfico al balanceador de cargas

Accede a la instancia que acabas de crear y prueba que los servicios HTTP(S) en los backends sean accesibles a través de la dirección IP de la regla de reenvío del balanceador de cargas HTTP(S) interno y que las cargas del tráfico se balanceen en las instancias de backend.

Conéctate mediante SSH a cada instancia de cliente

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

Verifica que la IP entregue su nombre de host

curl 10.1.2.99

Para la prueba de HTTPS, reemplaza curl por lo siguiente:

curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443

La marca -k hace que curl omita la validación del certificado.

Ejecuta 100 solicitudes y confirma que sus cargas estén balanceadas

Para HTTP:

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl --silent 10.1.2.99)"
  done
  echo "***"
  echo "*** Results of load-balancing to 10.1.2.99: "
  echo "***"
  echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
  echo
}

Para HTTPS:

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)"
  done
  echo "***"
  echo "*** Results of load-balancing to 10.1.2.99: "
  echo "***"
  echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
  echo
}

Opciones de configuración adicionales

En esta sección se expande el ejemplo de configuración para proporcionar opciones de configuración alternativas y adicionales. Todas las tareas son opcionales. Puedes realizarlas en cualquier orden.

Habilitar el acceso global

Puedes habilitar el acceso global para tu balanceador de cargas a fin de que sea accesible a los clientes en todas las regiones. De todos modos, los backends del balanceador de cargas de ejemplo deben ubicarse en una región (us-west1).

Balanceador de cargas HTTP(S) interno con acceso global (haz clic para ampliar)
Balanceador de cargas HTTP(S) interno con acceso global (haz clic para ampliar)

No puedes modificar una regla de reenvío regional existente para habilitar el acceso global. Debes crear una nueva regla de reenvío para este fin. Además, después de crear una regla de reenvío con acceso global habilitado, no se puede modificar. Para inhabilitar el acceso global, debes crear una nueva regla de reenvío de acceso regional y borrar la regla anterior.

Para configurar el acceso global, realiza los siguientes cambios de configuración.

Consola

No puedes usar la consola de Google Cloud para habilitar el acceso global. En su lugar, usa la CLI de gcloud o la API de REST.

gcloud

  1. Crea una regla de reenvío nueva para el balanceador de cargas con la marca --allow-global-access.

    Para HTTP:

    gcloud compute forwarding-rules create l7-ilb-forwarding-rule-global-access \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=lb-network \
  --subnet=backend-subnet \
  --address=10.1.2.99 \
  --ports=80 \
  --region=us-west1 \
  --target-http-proxy=l7-ilb-proxy \
  --target-http-proxy-region=us-west1 \
  --allow-global-access

    Para HTTPS:

    gcloud compute forwarding-rules create l7-ilb-forwarding-rule-global-access \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=lb-network \
  --subnet=backend-subnet \
  --address=10.1.2.99 \
  --ports=443 \
  --region=us-west1 \
  --target-https-proxy=l7-ilb-proxy \
  --target-https-proxy-region=us-west1 \
  --allow-global-access

  2. Puedes usar el comando gcloud compute forwarding-rules describe para determinar si una regla de reenvío tiene habilitado el acceso global. Por ejemplo:

    gcloud compute forwarding-rules describe l7-ilb-forwarding-rule-global-access \
  --region=us-west1 \
  --format="get(name,region,allowGlobalAccess)"

    Cuando el acceso global está habilitado, la palabra True aparece en el resultado después del nombre y la región de la regla de reenvío.

Crea una VM de cliente para probar el acceso global

Consola

  1. En la consola de Google Cloud, ve a la página Instancias de VM.

    Ir a Instancias de VM

  2. Haga clic en Crear instancia.

  3. Establece el Nombre como europe-client-vm.

  4. Establece la Zona en europe-west1-b.

  5. Haga clic en Opciones avanzadas.

  6. Haz clic en Herramientas de redes y configura los siguientes campos:

    1. En Etiquetas de red, ingresa allow-ssh.
    2. En Interfaces de red, selecciona lo siguiente:
      • Red: lb-network
      • Subred: europe-subnet

  7. Haz clic en Crear.

gcloud

Crea una VM de cliente en la zona europe-west1-b.

gcloud compute instances create europe-client-vm \
    --zone=europe-west1-b \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=europe-subnet

Conéctate al cliente de VM y prueba la conectividad

  1. Usa ssh para conectarte a la instancia de cliente.

    gcloud compute ssh europe-client-vm \
    --zone=europe-west1-b

  2. Prueba las conexiones al balanceador de cargas como lo hiciste desde vm-client en la región us-west1.

    curl http://10.1.2.99

Habilita la afinidad de sesión

Con estos procedimientos, se muestra cómo actualizar un servicio de backend para el balanceador de cargas de HTTP(S) interno de ejemplo a fin de que el servicio de backend use afinidad de cookie generada, afinidad de campo de encabezado o afinidad de cookie HTTP.

Cuando se habilita la afinidad de cookie generada, el balanceador de cargas emite una cookie en la primera solicitud. Para cada solicitud posterior con la misma cookie, el balanceador de cargas dirige la solicitud a la misma VM o extremo de backend. Para los balanceadores de cargas de HTTP(S) internos, la cookie se llama GCILB.

Cuando se habilita la afinidad de campo de encabezado, el balanceador de cargas enruta solicitudes a VM o extremos de backend en un NEG según el valor del encabezado de HTTP que se indica en la marca --custom-request-header. La afinidad de campo de encabezado solo es válida si la política de localidad de balanceo de cargas es RING_HASH o MAGLEV y el hash coherente del servicio de backend especifica el nombre del encabezado de HTTP.

Cuando la afinidad de cookie HTTP está habilitada, el balanceador de cargas enruta las solicitudes a VM o extremos de backend en un NEG, según una cookie HTTP a la que se hace referencia en la marca HTTP_COOKIE con la marca opcional --affinity-cookie-ttl. Si el cliente no proporciona la cookie en la solicitud de HTTP, el proxy genera la cookie y la muestra al cliente en un encabezado Set-Cookie. La afinidad de cookie HTTP solo es válida si la política de localidad de balanceo de cargas es RING_HASH o MAGLEV y el hash coherente del servicio de backend especifica la cookie HTTP.

Console

Para habilitar o cambiar la afinidad de sesión de un servicio de backend, sigue estas instrucciones:

  1. En la consola de Google Cloud, ve a la página Balanceo de cargas.

    Ir a Balanceo de cargas

  2. Haga clic en Backends.

  3. Haz clic en l7-ilb-backend-service (el nombre del servicio de backend que creaste para este ejemplo) y haz clic en Editar.

  4. En la página Detalles del servicio de backend, haz clic en Configuración avanzada.

  5. En Afinidad de sesión, selecciona el tipo de afinidad de sesión que desees del menú.

  6. Haz clic en Actualizar.

gcloud

Usa los siguientes comandos de gcloud para actualizar el servicio de backend de l7-ilb-backend-service a diferentes tipos de afinidad de sesión:

gcloud compute backend-services update l7-ilb-backend-service \
    --session-affinity=[GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | CLIENT_IP]
    --region=us-west1

API

Para configurar la afinidad de sesión, realiza una solicitud PATCH al método regionBackendServices/patch.

PATCH https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/regionBackendServices/l7-ilb-backend-service
{
"sessionAffinity": ["GENERATED_COOKIE" | "HEADER_FIELD" | "HTTP_COOKIE" | "CLIENT_IP" ]
}

Restringe qué clientes pueden enviar tráfico al balanceador de cargas

Puedes restringir los clientes para que no puedan comunicarse con un VIP de regla de reenvío del balanceador de cargas de HTTP(S) interno si configuras las reglas de firewall de salida en estos clientes. Configura estas reglas de firewall en VM de cliente específicas según cuentas de servicio o etiquetas.

No puedes usar reglas de firewall para restringir el tráfico entrante a VIP de la regla de reenvío del balanceador de cargas de HTTP(S) interno específico. Cualquier cliente en la misma red de VPC y en la misma región que la VIP de la regla de reenvío puede enviar tráfico a la VIP de la regla de reenvío.

Además, todas las solicitudes a los backends provienen de proxies que usan el rango de subred de solo proxy. No es posible crear reglas de firewall que permitan o denieguen el tráfico de entrada en estos backends según la VIP de la regla de reenvío que usa un cliente.

Estos son algunos ejemplos de cómo usar las reglas de firewall de salida para restringir el tráfico a la VIP de la regla de reenvío del balanceador de cargas.

Console

Para identificar las VM de cliente, deberás etiquetar las VM específicas que deseas restringir. Estas etiquetas se usan para asociar reglas de firewall con las VM cliente etiquetadas. Luego, agrega la etiqueta al campo TARGET_TAG en estos pasos.

Usa una sola regla de firewall o varias reglas para configurarla.

Una regla de firewall de salida

Puedes configurar una regla de salida de firewall para rechazar todo el tráfico de salida desde las VMs de cliente etiquetadas hacia la VIP del balanceador de cargas.

  1. En la consola de Google Cloud, ve a la página Reglas de firewall.

    Ir a Reglas de firewall

  2. Haz clic en Crear regla de firewall para crear la regla que deniega el tráfico de salida de las VMs de cliente etiquetadas a la VIP del balanceador de cargas.

    • Name: fr-deny-access
    • Red: lb-network
    • Prioridad: 100
    • Dirección del tráfico: Salida
    • Acción si hay coincidencia: Denegar
    • Destinos: Etiquetas de destino especificadas
    • Etiquetas de destino: TARGET_TAG
    • Filtro de destino: Rangos de IP
    • Rangos de IP de destino: 10.1.2.99
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Selecciona la casilla de verificación tcp y, luego, ingresa 80 para el número de puerto.

  3. Haga clic en Crear.

Varias reglas de firewall de salida

Un enfoque más escalable implica establecer dos reglas. Una regla predeterminada de baja prioridad que restringe el acceso a los VIP de los balanceadores de cargas. Una segunda regla de mayor prioridad que permite que un subconjunto de clientes etiquetados acceda a la VIP del balanceador de cargas. Solo las VMs etiquetadas podrán acceder a las VIP.

  1. En la consola de Google Cloud, ve a la página Reglas de firewall.

    Ir a Reglas de firewall

  2. Haz clic en Crear regla de firewall para crear la regla de menor prioridad a fin de denegar el acceso de forma predeterminada:

    • Nombre: fr-deny-all-access-low-priority
    • Red: lb-network
    • Prioridad: 200
    • Dirección del tráfico: Salida
    • Acción si hay coincidencia: Denegar
    • Destinos: Etiquetas de destino especificadas
    • Etiquetas de destino: TARGET_TAG
    • Filtro de destino: Rangos de IP
    • Rangos de IP de destino: 10.1.2.99
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Selecciona la casilla de verificación TCP y, luego, ingresa 80 para el número de puerto.

  3. Haz clic en Crear.

  4. Haz clic en Crear regla de firewall para crear la regla de mayor prioridad a fin de permitir el tráfico desde instancias etiquetadas específicas.

    • Name: fr-allow-some-access-high-priority
    • Red: lb-network
    • Prioridad: 100
    • Dirección del tráfico: Salida
    • Acción en caso de coincidencia: Permitir
    • Destinos: Etiquetas de destino especificadas
    • Etiquetas de destino: TARGET_TAG
    • Filtro de destino: Rangos de IP
    • Rangos de IP de destino: 10.1.2.99
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Selecciona la casilla de verificación TCP y, luego, ingresa 80 para el número de puerto.

  5. Haz clic en Crear.

gcloud

Para identificar las VM de cliente, deberás etiquetar las VM específicas que deseas restringir. Luego, agrega la etiqueta al campo TARGET_TAG en estos pasos.

Usa una sola regla de firewall o varias reglas para configurarla.

Una regla de firewall de salida

Puedes configurar una regla de salida de firewall para rechazar todo el tráfico de salida desde las VMs de cliente etiquetadas hacia la VIP del balanceador de cargas.

gcloud compute firewall-rules create fr-deny-access \
  --network=lb-network \
  --action=deny \
  --direction=egress \
  --rules=tcp \
  --priority=100 \
  --destination-ranges=10.1.2.99 \
  --target-tags=TARGET_TAG

Varias reglas de firewall de salida

Un enfoque más escalable implica establecer dos reglas. Una regla predeterminada de baja prioridad que restringe el acceso a los VIP de los balanceadores de cargas. Una segunda regla de mayor prioridad que permite que un subconjunto de clientes etiquetados acceda a la VIP del balanceador de cargas. Solo las VM etiquetadas podrán acceder a las VIP.

  1. Crea la regla de prioridad más baja:

    gcloud compute firewall-rules create fr-deny-all-access-low-priority \
--network=lb-network \
--action=deny \
--direction=egress \
--rules=tcp \
--priority=200 \
--destination-ranges=10.1.2.99

  2. Crea la regla de prioridad más alta:

    gcloud compute firewall-rules create fr-allow-some-access-high-priority \
--network=lb-network \
--action=allow \
--direction=egress \
--rules=tcp \
--priority=100 \
--destination-ranges=10.1.2.99 \
--target-tags=TARGET_TAG

Para usar cuentas de servicio en lugar de etiquetas a fin de controlar el acceso, usa la marca --target-service-accounts en lugar de la marca --target-tags cuando crees reglas de firewall.

Escala el acceso restringido a los backends del balanceador de cargas HTTP(S) interno según las subredes

Mantener reglas de firewall independientes o agregar IP nuevas con balanceo de cargas a las reglas existentes como se describe en la sección anterior se vuelve poco conveniente a medida que aumenta la cantidad de reglas de reenvío. Una forma de evitar esto es asignar direcciones IP de reglas de reenvío desde una subred reservada. Luego, se puede permitir o bloquear el tráfico de las instancias etiquetadas o las cuentas de servicio mediante la subred reservada como rango de destino para las reglas de firewall. Esto te permite controlar de manera eficaz el acceso a un grupo de VIP de reglas de reenvío sin tener que mantener reglas de salida de firewall por VIP.

Estos son los pasos de alto nivel para configurarlo, en el caso de que crearás todos los demás recursos del balanceador de cargas necesarios por separado.

gcloud

  1. Crea una subred regional que se usará para asignar direcciones IP con balanceo de cargas a las reglas de reenvío:

    gcloud compute networks subnets create l7-ilb-restricted-subnet \
  --network=lb-network \
  --region=us-west1 \
  --range=10.127.0.0/24

  2. Crea una regla de reenvío que tome una dirección de la subred recién asignada. Para este ejemplo, seleccionamos 10.127.0.1 de la subred creada en el paso anterior.

    gcloud compute forwarding-rules create l7-ilb-forwarding-rule-restricted \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=lb-network \
  --subnet=l7-ilb-restricted-subnet \
  --address=10.127.0.1 \
  --ports=80 \
  --region=us-west1 \
  --target-http-proxy=l7-ilb-proxy \
  --target-http-proxy-region=us-west1

  3. Crea una regla de firewall para restringir el tráfico destinado a las direcciones IP de rango en la subred de reglas de reenvío (l7-ilb-restricted-subnet):

    gcloud compute firewall-rules create restrict-traffic-to-subnet \
  --network=lb-network \
  --action=deny \
  --direction=egress \
  --rules=tcp:80 \
  --priority=100 \
  --destination-ranges=10.127.0.0/24 \
  --target-tags=TARGET_TAG

Configura la subdivisión de backend

La subdivisión del backend mejora el rendimiento y la escalabilidad mediante la asignación de un subconjunto de backends a cada una de las instancias de proxy. Cuando se habilita en un servicio de backend, ajusta la cantidad de backends que usa cada instancia de proxy de la siguiente manera:

  • A medida que aumenta la cantidad de instancias de proxy que participan en el balanceador de cargas, disminuye el tamaño del subconjunto.

  • Cuando la cantidad total de backends en una red excede la capacidad de una sola instancia de proxy, el tamaño del subconjunto se reduce de forma automática para cada servicio que tiene habilitado el subconjunto de backend.

En este ejemplo, se muestra cómo crear los recursos del balanceador de cargas de HTTP(S) interno y habilitar la subdivisión de backend:

  1. Usa la configuración de ejemplo para crear un servicio de backend regional l7-ilb-backend-service.

  2. Especifica el --subsetting-policy como CONSISTENT_HASH_SUBSETTING para habilitar la subdivisión de backend. El esquema de balanceo de cargas es INTERNAL_MANAGED.

    gcloud

    Usa el siguiente comando de gcloud para actualizar l7-ilb-backend-service con subdivisión de backend:

    gcloud beta compute backend-services update l7-ilb-backend-service \
   --region=us-west1 \
   --subsetting-policy=CONSISTENT_HASH_SUBSETTING

    API

    Realiza una solicitud PATCH al método regionBackendServices/patch.

    APLICA EL PARCHE https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/regions/us-west1/backendServices/l7-ilb-backend-service

    {
 "subsetting":
{
 "policy": CONSISTENT_HASH_SUBSETTING
}
}

También puedes definir mejor el balanceo de cargas de backend mediante la configuración de la política localityLbPolicy. Para obtener más información, consulta Políticas de tráfico.

Usa una dirección IP común entre varias reglas de reenvío internas

Para que varias reglas de reenvío interno compartan una dirección IP interna común, debes reservar la dirección IP y establecer su marca --purpose en SHARED_LOADBALANCER_VIP.

gcloud 

gcloud compute addresses create IP_ADDRESS_NAME \
    --region=us-west1 \
    --subnet=backend-subnet \
    --purpose=SHARED_LOADBALANCER_VIP

Si necesitas redireccionar el tráfico HTTP a HTTPS, puedes crear dos reglas de reenvío con una dirección IP común. Si deseas obtener más información, consulta Configura el redireccionamiento de HTTP a HTTPS para balanceadores de cargas de HTTP(S) internos.

¿Qué sigue?