Configura un balanceador de cargas de aplicaciones interno regional con backends de grupos de instancias de VM.

En este documento, se proporcionan instrucciones para configurar un balanceador de cargas de aplicaciones regional interno en los servicios que se ejecutan en las VMs de Compute Engine.

Si deseas configurar el balanceo de cargas de los servicios que se ejecutan en pods de Google Kubernetes Engine (GKE), consulta Balanceo de cargas nativo del contenedor con NEG independientes y la Vincula un balanceador de cargas de aplicaciones interno regional a NEG independientes.

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

La configuración de los balanceadores de cargas de aplicaciones internos 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 un balanceador de cargas de aplicaciones 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 del balanceador de cargas de aplicaciones interno.
Componentes numerados del balanceador de cargas de aplicaciones interno (haz clic para ampliar).

Como se muestra en el diagrama, en este ejemplo se crea un balanceador de cargas de aplicaciones 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 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 aplicaciones internos. La subred de solo proxy de la región se comparte entre todos los balanceadores de cargas de aplicaciones internos de la región. Las direcciones de origen de los paquetes enviados desde el balanceador de cargas de aplicaciones 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 VM de Compute Engine de backend.

  4. Grupos de instancias administrados o no administrados para implementaciones de VM de Compute Engine.

    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.

    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 de aplicaciones interno regional, en lugar de permitir que se asigne una dirección IP interna efímera. Recomendamos reservar direcciones IP para las reglas de reenvío.

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 aplicaciones 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

Console

  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. Haz 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. Haz 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 aplicaciones 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 Políticas de firewall.

    Ir a Políticas 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. Haz 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. Haz 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. Haz 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 aplicaciones 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"
}

Reserva la dirección IP del balanceador de cargas

De forma predeterminada, se usa una dirección IP para cada regla de reenvío. Puedes reservar una dirección IP compartida, que te permite usar la misma dirección IP con varias reglas de reenvío. Sin embargo, si deseas publicar el balanceador de cargas mediante Private Service Connect, no uses una dirección IP compartida para la 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á.

Console

Puedes reservar una dirección IP interna independiente con la consola de Google Cloud.

  1. Ir a la página de redes de VPC

    Ir a las redes de VPC

  2. Haz clic en la red que se usó para configurar la conectividad híbrida entre los entornos.
  3. Haz clic en Direcciones IP internas estáticas y, luego, en Reservar dirección estática.
  4. En Nombre, ingresa l7-ilb-ip-address.
  5. En Subred, selecciona backend-subnet.
  6. Si deseas especificar qué dirección IP deseas reservar, en Dirección IP estática, selecciona Permitirme elegir y, luego, completa una Dirección IP personalizada. De lo contrario, el sistema asignará de forma automática una dirección IP en la subred.
  7. Si deseas usar esta dirección IP con varias reglas de reenvío, en Propósito, elige Compartido.
  8. Haz clic en Reservar para finalizar el proceso.

gcloud

  1. Con la CLI de gcloud, ejecuta el comando compute addresses create:

    gcloud compute addresses create l7-ilb-ip-address \
  --region=us-west1 \
  --subnet=backend-subnet

    Si deseas usar la misma dirección IP con varias reglas de reenvío, especifica --purpose=SHARED_LOADBALANCER_VIP.

  2. Usa el comando compute addresses describe para ver la dirección IP asignada:

    gcloud compute addresses describe l7-ilb-ip-address \
  --region=us-west1

Crea un backend de grupo de instancias administrado

En esta sección, se muestra cómo crear una plantilla de instancias 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 de aplicaciones interno regional 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.

Console

  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. Haz 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 12 (bookworm). En estas instrucciones, se usan comandos que solo están disponibles en Debian, como apt-get.
    4. Haz 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. Haz 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. Haz 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. Haz 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-12 \
--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-12"
         },
         "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 aplicaciones interno regional:

  • 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

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.

Console

Inicia la configuración

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

    Ir a Balanceo de cargas

  2. Haz clic en Crear balanceador de cargas.
  3. En Tipo de balanceador de cargas, selecciona Balanceador de cargas de aplicaciones (HTTP/HTTPS) y haz clic en Siguiente.
  4. En Orientado al público o interno, selecciona Interno y haz clic en Siguiente.
  5. En Implementación entre regiones o de una sola región, selecciona Ideal para cargas de trabajo regionales y haz clic en Siguiente.
  6. Haz clic en Configurar.

Configuración básica

  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

.

Reserva una subred de solo 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. Haz 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. Haz 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. Haz 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. Haz 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. Configura la Subred como backend-subnet.
  5. Configura el Puerto en 80.
  6. En la lista Dirección IP, selecciona l7-ilb-ip-address.
  7. Haz clic en Listo.

Para HTTPS:

  1. Haz 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 la lista Dirección IP, selecciona l7-ilb-ip-address.
  7. Haz clic en la lista 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.

  9. Selecciona una política de SSL de la lista Política de SSL. De manera opcional, para crear una política de SSL, haz lo siguiente:

    1. En la lista SSL Policy, selecciona Crear una política.
    2. Escribe un nombre para la política de SSL.
    3. Selecciona una Versión mínima de TLS. El valor predeterminado es TLS 1.0.
    4. Selecciona uno de los perfiles preconfigurados administrados por Google o un perfil Custom que te permita seleccionar funciones de SSL de forma individual. Se mostrarán las Funciones habilitadas y las Funciones inhabilitadas.
    5. Haz clic en Guardar.

    Si no creaste ninguna política de SSL, se aplica una política predeterminada de Google Cloud SSL.

  10. Haz 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:

    Puedes crear certificados de Compute Engine o del Administrador de certificados. Usa cualquiera de los siguientes métodos para crear certificados con el Administrador de certificados:

    • Certificados autoadministrados regionales Para obtener más información sobre cómo crear y usar certificados autoadministrados regionales, consulta Implementa un certificado autoadministrado regional. No se admiten mapas de certificados.

    • Certificados regionales administrados por Google. No se admiten mapas de certificados.

      El Administrador de certificados admite los siguientes tipos de certificados regionales administrados por Google:

      • Después de crear certificados, adjunta el certificado directamente al proxy de destino.

      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

    • 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=l7-ilb-ip-address \
  --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=l7-ilb-ip-address \
  --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": "IP_ADDRESS",
"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:

Puedes crear certificados de Compute Engine o del Administrador de certificados. Usa cualquiera de los siguientes métodos para crear certificados con el Administrador de certificados:

  • Certificados autoadministrados regionales Para obtener más información sobre cómo crear y usar certificados autoadministrados regionales, consulta Implementa un certificado autoadministrado regional. No se admiten mapas de certificados.

  • Certificados regionales administrados por Google. No se admiten mapas de certificados.

    El Administrador de certificados admite los siguientes tipos de certificados regionales administrados por Google:

    • Después de crear certificados, adjunta el certificado directamente al proxy de destino.

    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.

    from pathlib import Path
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.",
) -> dict:
    """
    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.

        Returns:
        Dictionary with information about the new regional SSL self-signed 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)

    return 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": "IP_ADDRESS",
"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

Para probar el balanceador de cargas, crea una VM de cliente. Luego, establece una sesión SSH con la VM y envía tráfico desde esta VM al balanceador de cargas.

Crea una instancia de VM para probar la conectividad

Console

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

    Ir a Instancias de VM

  2. Haz clic en Crear instancia.

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

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

  5. Haz 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-12 \
    --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 de aplicaciones interno regional 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

Obtén la dirección IP del balanceador de cargas

Usa el comando gcloud compute addresses describe para ver la dirección IP asignada:

gcloud compute addresses describe l7-ilb-ip-address \
    --region=us-west1

Verifica que la dirección IP entregue su nombre de host.

Reemplaza IP_ADDRESS por la dirección IP del balanceador de cargas.

curl IP_ADDRESS

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

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

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

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

Reemplaza IP_ADDRESS por la dirección IP del balanceador de cargas.

Para HTTP:

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl --silent IP_ADDRESS)"
  done
  echo "***"
  echo "*** Results of load-balancing: "
  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:IP_ADDRESS:443)"
  done
  echo "***"
  echo "*** Results of load-balancing: "
  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 el balanceador de cargas de aplicaciones interno regional y el balanceador de cargas de red de proxy interno regional para que sean accesibles para los clientes en todas las regiones. De cualquier manera, los backends del balanceador de cargas de ejemplo deben ubicarse en una región (us-west1).

Balanceador de cargas de aplicaciones interno regional con acceso global.
Balanceador de cargas de aplicaciones interno regional 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 y borrar la regla de reenvío anterior. 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.

Console

Crea una nueva regla de desvío para el 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 columna Nombre, haz clic en el balanceador de cargas.

  3. Haz clic en Configuración de frontend.

  4. Haz clic en Agregar IP y puerto de frontend.

  5. Ingresa el nombre y los detalles de la subred para la regla de reenvío nueva.

  6. En Subred, selecciona backend-subnet.

  7. En la dirección IP, puedes seleccionar la misma dirección IP que una regla de reenvío existente, reservar una dirección IP nueva o usar una dirección IP efímera. Compartir la misma dirección IP en varias reglas de reenvío solo es posible si configuras la marca de dirección IP --purpose como SHARED_LOADBALANCER_VIP mientras creas la dirección IP.

  8. En Número de puerto, ingresa 110.

  9. En Acceso global, selecciona Habilitar.

  10. Haz clic en Listo.

  11. Haz clic en Actualizar.

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

Console

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

    Ir a Instancias de VM

  2. Haz clic en Crear instancia.

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

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

  5. Haz 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-12 \
    --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

Estos procedimientos muestran cómo actualizar un servicio de backend para el balanceador de cargas de aplicaciones interno regional o el balanceador de cargas de aplicaciones interno entre regiones para 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 instancia o extremo de máquina virtual (VM) de backend. En este ejemplo, la cookie se llama GCILB.

Cuando se habilita la afinidad de campo de encabezado, el balanceador de cargas enruta solicitudes a VMs o extremos de backend en un grupo de terminales de red (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. Haz 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.
  6. Haz clic en Actualizar.

gcloud

Usa los siguientes comandos de Google Cloud CLI para actualizar el servicio de backend 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 backendServices/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 conectarse a un VIP de regla de reenvío del balanceador de cargas de aplicaciones interno si configuras las reglas de firewall de salida en estos clientes. Configura estas reglas de firewall en VMs 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 aplicaciones 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 direcciones IP en 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 VMs de cliente, etiqueta las VMs específicas que deseas restringir. Estas etiquetas se usan para asociar reglas de firewall con las VMs cliente etiquetadas. Luego, agrega la etiqueta al campo TARGET_TAG en los siguientes 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.

    • Nombre: 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. Haz 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 pueden acceder a la 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.

    • Nombre: 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 VMs de cliente, etiqueta las VMs 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 y una segunda regla de mayor prioridad que permite el acceso a un subconjunto de clientes etiquetados para acceder al VIP del balanceador de cargas. Solo las VMs etiquetadas pueden acceder a la 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 para controlar el acceso, usa la opción --target-service-accounts en lugar de la marca --target-tags cuando crees reglas de firewall.

Escala el acceso restringido a los backends internos del balanceador de cargas de aplicaciones según las subredes

Mantener reglas de firewall independientes o agregar direcciones 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. En el siguiente ejemplo, se usa la dirección 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, la subdivisión 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 aplicaciones regional 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. Para habilitar la subdivisión de backend, especifica la marca --subsetting-policy como CONSISTENT_HASH_SUBSETTING. Establece el esquema de balanceo de cargas en 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.

    PATCH 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 la misma dirección IP 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 SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP
Si necesitas redireccionar el tráfico HTTP a HTTPS, puedes crear dos reglas de reenvío que use 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 aplicaciones internos.

¿Qué sigue?