Configurar un balanceador de carga de aplicación interno regional con backends de grupos de instancias de VM

En este documento se proporcionan instrucciones para configurar un balanceador de carga de aplicaciones interno regional para los servicios que se ejecutan en máquinas virtuales de Compute Engine.

Para configurar el balanceo de carga de los servicios que se ejecutan en pods de Google Kubernetes Engine (GKE), consulta el artículo Balanceo de carga nativo de contenedores mediante NEGs independientes y la sección Asociar un balanceador de carga de aplicación interno a NEGs independientes.

Para configurar el balanceo de carga para acceder a las APIs y los servicios de Google mediante Private Service Connect, consulta Acceder a las APIs de Google regionales mediante backends.

La configuración de los balanceadores de carga de aplicación internos consta de dos partes:

• Realiza las tareas previas necesarias, como asegurarte de que las cuentas requeridas tengan los permisos correctos y preparar la red de nube privada virtual (VPC).
• Configura los recursos del balanceador de carga.

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

• Descripción general del balanceador de carga de aplicación interno, incluida la sección Limitaciones
• Descripción general de las reglas de cortafuegos de VPC

Permisos

Para seguir esta guía, debes poder crear instancias y modificar una red en un proyecto. Debes ser propietario o editor del proyecto, o bien tener todos los roles de gestión de identidades y accesos de Compute Engine que se indican a continuación.

Tarea	Rol necesario
Crear redes, subredes y componentes de balanceador de carga	Administrador de redes de Compute (roles/compute.networkAdmin)
Añadir y eliminar reglas de cortafuegos	Administrador de seguridad de Compute (roles/compute.securityAdmin)
Crear instancias	Administrador de instancias de Compute (roles/compute.instanceAdmin.v1)

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

• Roles y permisos
• Condiciones de IAM para reglas de reenvío

Descripción general de la configuración

Puede configurar un balanceador de carga de aplicaciones interno tal como se describe en el siguiente flujo de configuración de alto nivel. Los pasos numerados hacen referencia a los números del diagrama.

Componentes numerados del balanceador de carga de aplicación interno (haz clic para ampliar).

Como se muestra en el diagrama, en este ejemplo se crea un balanceador de carga de aplicaciones interno en una red de VPC de 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:

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

   • 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 carga de aplicaciones internos. La subred de solo proxy de la región se comparte entre todos los balanceadores de carga de aplicaciones internos de la región. Las direcciones de origen de los paquetes enviados desde el balanceador de carga de aplicaciones interno a los backends de tu servicio se asignan desde la subred solo proxy. En este ejemplo, la subred de solo proxy de la región tiene un intervalo de direcciones IP principal de 10.129.0.0/23, que es el tamaño de subred recomendado. Para obtener más información, consulta Subredes de solo proxy para balanceadores de carga basados en Envoy.

2. Dos reglas de cortafuegos:

   • Una regla de cortafuegos que permita el flujo de tráfico de la subred de solo proxy en tu red. Esto significa añadir una regla que permita el tráfico de los puertos TCP 80, 443 y 8080 desde 10.129.0.0/23 (el intervalo de la subred de solo proxy en este ejemplo).
   • Otra regla de cortafuegos para las sondas de comprobación del estado.

3. Instancias de VM de Compute Engine de backend.

4. Grupos de instancias gestionados o sin gestionar para implementaciones de VMs de Compute Engine.

   En cada zona, puedes tener una combinación de tipos de grupos de backend en función de los requisitos de tu implementación.

   Nota: En esta configuración se muestra cómo balancear la carga de las solicitudes solo a los backends de grupos de instancias de VM. Para saber cómo balancear la carga de las solicitudes a los pods de GKE, consulta Ingress de GKE para balanceadores de carga de aplicaciones.

5. Una comprobación del estado regional que informa sobre la disponibilidad de tus backends.

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

7. Un mapa de URLs 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 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 URLs. En el caso de HTTPS, configura un recurso de certificado SSL regional. El proxy de destino usa el certificado SSL para descifrar el tráfico SSL si configuras el balanceo de carga HTTPS. El proxy de destino puede reenviar tráfico a tus instancias mediante HTTP o HTTPS.

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

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

   • La dirección IP puede (pero no tiene por qué) proceder de la misma subred que los grupos de instancias de backend.
   • La dirección IP no debe proceder de una subred reservada de solo proxy que tenga el valor REGIONAL_MANAGED_PROXY en su marca --purpose.
   • Si quiere compartir la dirección IP interna con varias reglas de reenvío, defina el valor --purpose de la dirección IP como SHARED_LOADBALANCER_VIP.

   En el ejemplo de esta página se usa una dirección IP interna reservada para la regla de reenvío del balanceador de carga de aplicaciones interno regional, en lugar de permitir que se asigne una dirección IP interna efímera. Como práctica recomendada, te sugerimos que reserves direcciones IP para las reglas de reenvío.

Configurar la red y las subredes

Necesitas una red de VPC con dos subredes: una para los backends del balanceador de carga y otra para los proxies del balanceador de carga. Un balanceador de carga de aplicación interno es regional. El tráfico de la red de VPC se dirige al balanceador de carga si la fuente del tráfico se encuentra en una subred de la misma región que el balanceador de carga.

En este ejemplo se usan la siguiente red VPC, región y subredes:

• Red. La red es una red de VPC en modo personalizado llamada lb-network.

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

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

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

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

Nota: Puedes cambiar el nombre de la red, la región y los parámetros de las subredes. Sin embargo, en los pasos siguientes de esta guía se utilizan los parámetros de red, región y subred que se indican aquí.

Configurar la red y las subredes

Consola

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

   Ir a redes de VPC

2. Haz clic en Crear red VPC.

3. En Nombre, escribe lb-network.

4. En la sección Subredes, selecciona Personalizado en Modo de creación de subredes.

5. Crea una subred para los back-ends del balanceador de carga. En la sección Nueva subred, introduce la siguiente información:

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

6. Haz clic en Listo.

7. Haz clic en Añadir subred.

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

   • Nombre: europe-subnet
   • Región: europe-west1
   • Intervalo 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 de 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 de 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. Sustituye PROJECT_ID por el ID de tu 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. Sustituye PROJECT_ID por el ID de tu 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. Sustituye PROJECT_ID por el ID de tu 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",
}

Configurar la subred de solo proxy

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

Importante: No intentes asignar direcciones de la subred de solo proxy a la regla de reenvío o a los backends de tu balanceador de carga. Asigna la dirección IP de la regla de reenvío y las direcciones IP de la instancia de backend desde otro intervalo (u otros intervalos) de subred, no desde este.Google Cloud reserva este intervalo de subred para los proxies gestionados por Google Cloud.

Consola

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

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

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

   Ir a redes de VPC

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

3. Haz clic en Añadir subred.

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

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

6. En Propósito, selecciona Proxy gestionado regional.

7. En Intervalo de direcciones IP, introduce 10.129.0.0/23.

8. Haz clic en Añadir.

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. Sustituye PROJECT_ID por el ID de tu 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"
}

Configurar reglas de cortafuegos

En este ejemplo se usan las siguientes reglas de cortafuegos:

• fw-allow-ssh. Una regla de entrada aplicable a las instancias que se van a balancear de carga que permita la conectividad SSH entrante en el puerto TCP 22 desde cualquier dirección. Puede elegir un intervalo de IPs de origen más restrictivo para esta regla. Por ejemplo, puede especificar solo los intervalos de IPs del sistema desde el que inicia 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 cortafuegos.

• fw-allow-health-check. Una regla de entrada aplicable a las instancias que se están balanceando de carga, que permite todo el tráfico TCP de los sistemas de comprobación del estado 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 cortafuegos.

• fw-allow-proxies. Una regla de entrada, aplicable a las instancias que se van a balancear, que permite el tráfico TCP en los puertos 80, 443 y 8080 desde los proxies gestionados del balanceador de carga 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 cortafuegos.

Sin estas reglas de cortafuegos, la regla denegar predeterminada de entrada bloquea el tráfico entrante a las instancias de backend.

Las etiquetas de destino definen las instancias de backend. Si no se incluyen las etiquetas de destino, las reglas de cortafuegos se aplican a todas las instancias de backend de la red de VPC. Cuando cree las VMs de backend, asegúrese de incluir las etiquetas de destino especificadas, tal como se muestra en Crear un backend de grupo de instancias de VM gestionadas.

Consola

1. En la Google Cloud consola, ve a la página Políticas de cortafuegos.

   Ir a Políticas de cortafuegos

2. Haz clic en Crear regla de cortafuegos para crear la regla que permita las conexiones SSH entrantes:

   • Nombre: fw-allow-ssh
   • Red: lb-network
   • Sentido del tráfico: entrada
   • Acción tras coincidencia: Permitir
   • Objetivos: Etiquetas de destino especificadas
   • Etiquetas de destino: allow-ssh
   • Filtro de origen: Intervalos de IPv4
   • Intervalos de IPv4 de origen: 0.0.0.0/0
   • Protocolos y puertos:
     • Elige Protocolos y puertos especificados.
     • Selecciona la casilla TCP y, a continuación, introduce 22 como número de puerto.

3. Haz clic en Crear.

4. Vuelve a hacer clic en Crear regla de cortafuegos para crear la regla que permita las comprobaciones del estado deGoogle Cloud :

   • Nombre: fw-allow-health-check
   • Red: lb-network
   • Sentido del tráfico: entrada
   • Acción tras coincidencia: Permitir
   • Objetivos: Etiquetas de destino especificadas
   • Etiquetas de destino: load-balanced-backend
   • Filtro de origen: Intervalos de IPv4
   • Intervalos 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 TCP y, a continuación, introduce 80 como número de puerto.
       Como práctica recomendada, limita esta regla a los protocolos y puertos que coincidan con los que usa tu comprobación de estado. Si usas tcp:80 para el protocolo y el puerto, Google Cloud puede usar HTTP en el puerto 80 para ponerse en contacto con tus VMs, pero no puede usar HTTPS en el puerto 443 para hacerlo.

5. Haz clic en Crear.

6. Haz clic en Crear regla de cortafuegos por tercera vez para crear la regla que permita que los servidores proxy del balanceador de carga se conecten a los backends:

   • Nombre: fw-allow-proxies
   • Red: lb-network
   • Sentido del tráfico: entrada
   • Acción tras coincidencia: Permitir
   • Objetivos: Etiquetas de destino especificadas
   • Etiquetas de destino: load-balanced-backend
   • Filtro de origen: Intervalos de IPv4
   • Intervalos de IPv4 de origen: 10.129.0.0/23
   • Protocolos y puertos:
     • Elige Protocolos y puertos especificados.
     • Selecciona la casilla TCP y, a continuación, introduce 80, 443, 8080 en los números de puerto.

7. Haz clic en Crear.

gcloud

1. Crea la regla de cortafuegos fw-allow-ssh para permitir la conectividad SSH a las VMs con la etiqueta de red allow-ssh. Si omite source-ranges, Google Cloud interpreta que la regla se aplica a 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 Google Cloud las comprobaciones del estado. En este ejemplo, se permite todo el tráfico TCP de los verificadores de comprobación del estado. Sin embargo, puede configurar un conjunto de puertos más reducido para satisfacer sus 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. Cree la regla fw-allow-proxies para permitir que los proxies del balanceador de carga de aplicaciones interno se conecten a sus backends. Asigna source-ranges a los intervalos 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 cortafuegos fw-allow-ssh haciendo una solicitud POST al método firewalls.insert y sustituyendo PROJECT_ID por el ID de tu 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 cortafuegos fw-allow-health-check haciendo una solicitud POST al método firewalls.insert y sustituyendo PROJECT_ID por el ID de tu 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 cortafuegos fw-allow-proxies para permitir el tráfico TCP en la subred de proxy del método firewalls.insert. Sustituye PROJECT_ID por el ID de tu 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"
}

Reservar la dirección IP del balanceador de carga

De forma predeterminada, se usa una dirección IP para cada regla de reenvío. Puede reservar una dirección IP compartida, lo que le permite usar la misma dirección IP con varias reglas de reenvío. Sin embargo, si quieres publicar el balanceador de carga mediante Private Service Connect, no uses una dirección IP compartida para la regla de reenvío.

En la dirección IP de la regla de reenvío, usa backend-subnet. Si intentas usar la subred solo proxy, no se podrá crear la regla de reenvío.

Consola

Puedes reservar una dirección IP interna independiente mediante la consolaGoogle Cloud .

1. Ve a la página Redes de VPC.

   Ir a redes de VPC

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

gcloud

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

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

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

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

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

Crear un backend de grupo de instancias de máquina virtual gestionada

En esta sección se muestra cómo crear una plantilla de grupo de instancias y un grupo de instancias gestionado. El grupo de instancias gestionado proporciona instancias de VM que ejecutan los servidores backend de un balanceador de carga de aplicaciones interno regional de ejemplo. En tu grupo de instancias, puedes definir un servicio HTTP y asignar un nombre de puerto al puerto correspondiente. El servicio de backend del balanceador de carga reenvía el tráfico a los puertos con nombre. El tráfico de los clientes se balancea entre los servidores de backend. A efectos de demostración, los backends sirven sus propios nombres de host.

Consola

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

   Ir a Plantillas de instancia

   1. Haz clic en Crear plantilla de instancia.
   2. En Nombre, escribe l7-ilb-backend-template.
   3. Asegúrate de que el disco de arranque esté configurado con 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 Advanced options (Opciones avanzadas).
   5. Haga clic en Redes y configure los siguientes campos:
      1. En Etiquetas de red, introduce allow-ssh y load-balanced-backend.
      2. En Interfaces de red, selecciona lo siguiente:
         • Red: lb-network
         • Subred: backend-subnet

   6. Haz clic en Gestión. Introduce 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. Crea un grupo de instancias gestionado. 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 gestionado (sin reconocimiento del estado). Para obtener más información, consulta Grupos de instancias gestionadas con estado.
   3. En Nombre, escribe l7-ilb-backend-example.
   4. En Ubicación, selecciona Una sola zona.
   5. En Región, selecciona us-west1.
   6. En Zona, selecciona us-west1-a.
   7. En Plantilla de instancia, selecciona l7-ilb-backend-template.

   8. Especifica el número de instancias que quieres crear en el grupo.

      En este ejemplo, especifica las siguientes opciones en Escalado automático:

      • En Modo de autoescalado, selecciona Off:do not autoscale.
      • En Número máximo de instancias, introduce 2.

      Opcionalmente, en la sección Auto escalado de la interfaz de usuario, puede configurar el grupo de instancias para que añada o elimine instancias automáticamente en función del uso de la CPU de las instancias.

   9. Haz clic en Crear.

gcloud

En las gcloud instrucciones de esta guía se presupone que usas Cloud Shell u otro entorno con bash instalado.

1. Crea una plantilla de instancia de VM con un servidor 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 gestionado 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 instancia con el método instanceTemplates.insert y sustituye 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 gestionadas en cada zona con el método instanceGroupManagers.insert. Sustituye PROJECT_ID por el ID de tu 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
}

Configurar el balanceador de carga

En este ejemplo se muestra cómo crear los siguientes recursos de balanceador de carga de aplicaciones interno regional:

• Comprobación del estado de HTTP
• Servicio de backend con un grupo de instancias gestionado como backend
• Una asignación de URLs
  • Asegúrate de hacer referencia a un mapa de URLs regional si se ha definido una región para el proxy HTTP(S) de destino. Un mapa de URLs 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 una URL entrante. Un mapa de URLs regional solo puede hacer referencia a una regla de proxy de destino regional de la misma región.
• Certificado SSL (para HTTPS)
• Proxy de destino
• Regla de reenvío

Disponibilidad de proxy

A veces, las Google Cloud regiones no tienen suficiente capacidad de proxy para un nuevo balanceador de carga. Si esto ocurre, la Google Cloud consola proporciona un mensaje de advertencia de disponibilidad del proxy cuando creas el balanceador de carga. Para solucionar este problema, puedes hacer una de las siguientes cosas:

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

• Espera a que se resuelva el problema de capacidad.

Consola

Selecciona el tipo de balanceador de carga

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

   Ir a Balanceo de carga

2. Haga clic en Crear balanceador de carga.
3. En Tipo de balanceador de carga, selecciona Balanceador de carga de aplicación (HTTP/HTTPS) y haz clic en Siguiente.
4. En Público o interno, selecciona Interno y haz clic en Siguiente.
5. En Implementación en una sola región o en varias regiones, selecciona La mejor opción para cargas de trabajo regionales y haz clic en Siguiente.
6. Haz clic en Configurar.

Configuración básica

1. En Name (Nombre) del balanceador de carga, introduce l7-ilb-map.
2. En Región, selecciona us-west1.
3. En Red, selecciona lb-network.

Reservar una subred de solo proxy

Nota: Si ya has reservado una subred solo proxy, tal como se indica en la configuración de preparación, no se muestra el botón Reservar una subred, por lo que debes saltarte esta sección y seguir los pasos para configurar el servicio backend.

Reserva una subred de solo proxy:

1. Haz clic en Reservar una subred.
2. En Nombre, escribe proxy-only-subnet.
3. En Intervalo de direcciones IP, introduce 10.129.0.0/23.
4. Haz clic en Añadir.

Configurar 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. Asigna el nombre l7-ilb-backend-service al servicio de backend.
4. En Tipo de backend, seleccione Grupo de instancias.
5. En la sección Nuevo backend, haz lo siguiente:
   1. Define Grupo de instancias como l7-ilb-backend-example.
   2. Define Port numbers (Transferir números) en 80.
   3. En Modo de balanceo, selecciona Utilización.
   4. Haz clic en Listo.
6. En la lista Comprobación del estado, haz clic en Crear comprobación del estado con los siguientes parámetros:
   1. Nombre: l7-ilb-basic-check
   2. Protocolo: HTTP
   3. Puerto: 80
   4. Haz clic en Guardar.

7. Opcional: Configura una política de seguridad de backend predeterminada. La política de seguridad predeterminada limita el tráfico por encima de un umbral configurado por el usuario. Para obtener más información sobre las políticas de seguridad predeterminadas, consulta el artículo Descripción general de la limitación de frecuencia.

   1. Para inhabilitar la política de seguridad predeterminada de Cloud Armor, selecciona None en la lista Política de seguridad de backend de Cloud Armor.
   2. Para configurar la política de seguridad predeterminada de Cloud Armor, selecciona Política de seguridad predeterminada en la lista Política de seguridad de backend de Cloud Armor.
   3. En el campo Nombre de la política, acepta el nombre generado automáticamente o introduce un nombre para tu política de seguridad.
   4. En el campo Número de solicitudes, acepta el número de solicitudes predeterminado o introduce un número entero entre 1 y 10,000.
   5. En el campo Intervalo, selecciona un intervalo.
   6. En el campo Enforce on key (Aplicar en clave), elige uno de los siguientes valores: All (Todo), IP address (Dirección IP) o X-Forwarded-For IP address (Dirección IP X-Forwarded-For). Para obtener más información sobre estas opciones, consulta Identificar clientes para limitar la frecuencia.
8. Haz clic en Crear.

Configurar el mapa de URL

1. Haz clic en Reglas de host y ruta.

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

3. Asegúrate de que l7-ilb-backend-service sea el único servicio backend para cualquier host y cualquier ruta que no coincidan.

Para obtener información sobre la gestión del tráfico, consulta Configurar la gestión del tráfico en balanceadores de carga de aplicación internos.

Configurar el frontend

Para HTTP:

1. Haz clic en Configuración de frontend.
2. Asigna el nombre l7-ilb-forwarding-rule a la regla de reenvío.
3. Define Protocol (Protocolo) como HTTP.
4. Asigna el valor backend-subnet a Subred.
5. Asigna el valor 80 a Port.
6. En la lista Dirección IP, seleccione l7-ilb-ip-address.
7. Haz clic en Listo.

Para HTTPS:

1. Haz clic en Configuración de frontend.
2. Asigna el nombre l7-ilb-forwarding-rule a la regla de reenvío.
3. Define Protocol (Protocolo) como HTTPS (includes HTTP/2).
4. Asigna el valor backend-subnet a Subred.
5. Asegúrate de que el Puerto esté configurado como 443 para permitir el tráfico HTTPS.
6. En la lista Dirección IP, seleccione l7-ilb-ip-address.
7. Haz clic en la lista Certificado.
   1. Si ya tienes un recurso de certificado SSL autogestionado que quieras usar como certificado SSL principal, selecciónalo en la lista.
   2. De lo contrario, selecciona Crear un certificado.
      1. Asigna el nombre l7-ilb-cert al certificado.
      2. En los campos correspondientes, sube los archivos con formato PEM:
         • Certificado de clave pública
         • Cadena de certificados
         • Clave privada
      3. Haz clic en Crear.
8. Para añadir recursos de certificado además del recurso de certificado SSL principal, sigue estos pasos:
   1. Haz clic en Añadir certificado.
   2. Selecciona un certificado de la lista Certificados o haz clic en Crear un certificado y sigue las instrucciones.

9. Selecciona una política de SSL de la lista Política de SSL. Si quiere crear una política de SSL, siga estos pasos:

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

   Si no has creado ninguna política de SSL, se aplicará una política de SSL predeterminada Google Cloud .

10. Haz clic en Listo.

Revisar la configuración

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

gcloud

1. Define la comprobación del 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 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. Añade 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 URLs 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.

   En HTTP:

   En el caso de un balanceador de carga 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 de Certificate Manager. Utiliza cualquiera de los siguientes métodos para crear certificados con Certificate Manager:

   • Certificados autogestionados regionales. Para obtener información sobre cómo crear y usar certificados regionales autogestionados, consulta Implementar un certificado regional autogestionado. No se admiten mapas de certificados.

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

     Certificate Manager admite los siguientes tipos de certificados regionales gestionados por Google:

     • Certificados regionales gestionados por Google con autorización de DNS por proyecto. Para obtener más información, consulta el artículo sobre cómo desplegar un certificado regional gestionado por Google con autorización de DNS.
     • Certificados privados gestionados por Google regionales con el Servicio de Autoridades de Certificación. Para obtener más información, consulta el artículo sobre cómo implementar un certificado regional gestionado por Google con el Servicio de Autoridades de Certificación.

   Una vez que hayas creado los certificados, adjúntalos directamente al proxy de destino.

   Asigna las rutas de los 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.

   En el caso de las redes personalizadas, debes hacer referencia a la subred en la regla de reenvío. Ten en cuenta que se trata de la subred de la VM, no de la subred del proxy.

   En 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 comprobación del estado, haz una solicitud POST al método regionHealthChecks.insert, sustituyendo PROJECT_ID por el ID de tu 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"
}
}

Crea el servicio backend regional haciendo una solicitud POST al método regionBackendServices.insert y sustituyendo PROJECT_ID por el ID de tu 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"
}

Crea el mapa de URLs haciendo una solicitud POST al método regionUrlMaps.insert y sustituyendo PROJECT_ID por el ID de tu 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:

Crea el proxy HTTP de destino haciendo una solicitud POST al método regionTargetHttpProxies.insert y sustituyendo PROJECT_ID por el ID de tu 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, haz una solicitud POST al método forwardingRules.insert y sustituye PROJECT_ID por el ID de tu 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 de Certificate Manager. Utiliza cualquiera de los siguientes métodos para crear certificados con Certificate Manager:

• Certificados autogestionados regionales. Para obtener información sobre cómo crear y usar certificados regionales autogestionados, consulta Implementar un certificado regional autogestionado. No se admiten mapas de certificados.

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

  Certificate Manager admite los siguientes tipos de certificados regionales gestionados por Google:

  • Certificados regionales gestionados por Google con autorización de DNS por proyecto. Para obtener más información, consulta el artículo sobre cómo desplegar un certificado regional gestionado por Google con autorización de DNS.
  • Certificados privados gestionados por Google regionales con el Servicio de Autoridades de Certificación. Para obtener más información, consulta el artículo sobre cómo implementar un certificado regional gestionado por Google con el Servicio de Autoridades de Certificación.

Una vez que hayas creado los certificados, adjúntalos directamente al proxy de destino.

Lee los archivos de certificado y clave privada y, a continuación, crea el certificado SSL. En el siguiente ejemplo se muestra cómo hacerlo 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

Crea el proxy HTTPS de destino enviando una solicitud POST al método regionTargetHttpsProxies.insert y sustituyendo PROJECT_ID por el ID de tu 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, haz una solicitud POST al método forwardingRules.insert y sustituye PROJECT_ID por el ID de tu 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",
}

Probar el balanceador de carga

Para probar el balanceador de carga, crea una VM cliente. A continuación, establece una sesión SSH con la máquina virtual y envía tráfico desde la máquina virtual al balanceador de carga.

Crear una instancia de máquina virtual 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. Haz clic en Crear instancia.

3. Asigna el valor l7-ilb-client-us-west1-a a Nombre.

4. Define Zona como us-west1-a.

5. Haz clic en Advanced options (Opciones avanzadas).

6. Haga clic en Redes y configure los siguientes campos:

   1. En Etiquetas de red, introduzca 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

Enviar tráfico al balanceador de carga

Inicia sesión en la instancia que acabas de crear y comprueba que se puede acceder a los servicios HTTP(S) de los backends mediante la dirección IP de la regla de reenvío del balanceador de carga de aplicaciones interno regional y que el tráfico se está balanceando entre 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

Obtener la dirección IP del balanceador de carga

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

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

Verificar que la dirección IP está sirviendo su nombre de host

Sustituye IP_ADDRESS por la dirección IP del balanceador de carga.

Para las pruebas HTTP:

curl IP_ADDRESS

Para probar HTTPS:

curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:IP_ADDRESS:443

Sustituye DOMAIN_NAME por el nombre de dominio de tu aplicación. Por ejemplo, test.example.com.

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

Ejecuta 100 solicitudes y confirma que están balanceadas.

Sustituye IP_ADDRESS por la dirección IP del balanceador de carga.

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:

Sustituye DOMAIN_NAME por el nombre de dominio de tu aplicación. Por ejemplo, test.example.com.

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME: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 amplía el ejemplo de configuración para ofrecer opciones de configuración alternativas y adicionales. Todas las tareas son opcionales. Puedes realizarlas en el orden que prefieras.

Habilitar el acceso global

Puedes habilitar el acceso global en los balanceadores de carga de aplicaciones internos regionales y en los balanceadores de carga de red con proxy internos regionales para que los clientes de todas las regiones puedan acceder a ellos. Los backends del balanceador de carga de ejemplo deben seguir estando en una región (us-west1).

Balanceador de carga de aplicaciones interno regional con acceso global (haz clic para ampliar).

No puedes modificar una regla de reenvío regional para habilitar el acceso global. Para ello, debe crear una regla de reenvío y eliminar la anterior. Además, una vez que se ha creado una regla de reenvío con el acceso global habilitado, no se puede modificar. Para inhabilitar el acceso global, debes crear una regla de reenvío de acceso regional y eliminar la regla de reenvío de acceso global anterior.

Para configurar el acceso global, haz los siguientes cambios en la configuración.

Consola

Crea una regla de reenvío para el balanceador de carga:

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

   Ir a Balanceo de carga

2. En la columna Nombre, haz clic en el balanceador de carga.

3. Haz clic en Configuración de frontend.

4. Haz clic en Añadir IP y puerto de frontend.

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

6. En Subred, selecciona backend-subnet.

7. En Dirección IP, puedes seleccionar la misma dirección IP que una regla de reenvío ya creada, reservar una nueva dirección IP o usar una dirección IP efímera. Solo se puede compartir la misma dirección IP en varias reglas de reenvío si se define la marca --purpose de la dirección IP en SHARED_LOADBALANCER_VIP al crearla.

8. En Número de puerto, introduce 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 para el balanceador de carga con la marca --allow-global-access.

   En 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 describepara 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.

Crear una VM 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. Haz clic en Crear instancia.

3. Asigna el valor europe-client-vm a Nombre.

4. Define Zona como europe-west1-b.

5. Haz clic en Advanced options (Opciones avanzadas).

6. Haga clic en Redes y configure los siguientes campos:

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

7. Haz clic en Crear.

gcloud

Crea una máquina virtual 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 la VM y prueba la conectividad

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

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

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

   curl http://10.1.2.99
   

Habilitar la afinidad de sesión

En estos procedimientos se muestra cómo actualizar un servicio de backend del balanceador de carga de aplicaciones interno regional o del balanceador de carga de aplicaciones interno entre regiones de ejemplo para que el servicio de backend use la afinidad de cookies generada, la afinidad de campos de encabezado o la afinidad de cookies HTTP.

Cuando se habilita la afinidad de cookies generadas, el balanceador de carga emite una cookie en la primera solicitud. En cada solicitud posterior con la misma cookie, el balanceador de carga dirige la solicitud a la misma instancia o endpoint de máquina virtual (VM) de backend. En este ejemplo, la cookie se llama GCILB.

Cuando la afinidad de campo de encabezado está habilitada, el balanceador de carga dirige las solicitudes a las VMs o los endpoints de backend de un grupo de endpoints de red (NEG) en función del valor del encabezado HTTP denominado en la marca --custom-request-header. La afinidad de campo de encabezado solo es válida si la política de localidad del balanceo de carga es RING_HASH o MAGLEV y el hash coherente del servicio de backend especifica el nombre del encabezado HTTP.

Cuando la afinidad de cookies HTTP está habilitada, el balanceador de carga dirige las solicitudes a las VMs de backend o a los endpoints de un NEG en función de una cookie HTTP denominada en la marca HTTP_COOKIE con la marca opcional --affinity-cookie-ttl. Si el cliente no proporciona la cookie en su solicitud HTTP, el proxy genera la cookie y la devuelve al cliente en un encabezado Set-Cookie. La afinidad de cookies HTTP solo es válida si la política de localidad del balanceo de carga es RING_HASH o MAGLEV y el hash coherente del servicio de backend especifica la cookie HTTP.

Consola

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

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

   Ir a Balanceo de carga

2. Haz clic en Back-ends.
3. Haz clic en l7-ilb-backend-service (el nombre del servicio de backend que has creado para este ejemplo) y, a continuación, 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 quieras.
6. Haz clic en Actualizar.

gcloud

Usa los siguientes comandos de la CLI de Google Cloud 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 definir la afinidad de sesión, haz 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" ]
    }
    

Restringir los clientes que pueden enviar tráfico al balanceador de carga

Nota: En esta sección se explica cómo restringir el acceso de los clientes a tu balanceador de carga de aplicación interno regional mediante reglas de cortafuegos. También puedes usar Google Cloud Armor para restringir el acceso de los clientes a tu balanceador de carga. Para obtener más información, consulta la información general sobre las políticas de seguridad en la documentación de Cloud Armor.

Puedes impedir que los clientes se conecten a una IP virtual de una regla de reenvío de un balanceador de carga de aplicaciones interno configurando reglas de cortafuegos de salida en estos clientes. Define estas reglas de cortafuegos en VMs de cliente específicas en función de las cuentas de servicio o las etiquetas.

No puede usar reglas de cortafuegos para restringir el tráfico entrante a IPs virtuales de reglas de reenvío de balanceadores de carga de aplicaciones internos específicos. Por lo general, cualquier cliente de la misma red de VPC y de la misma región que la IP virtual de la regla de reenvío puede enviar tráfico a la IP virtual de la regla de reenvío.

Además, todas las solicitudes a los back-ends proceden de proxies que usan direcciones IP del intervalo de la subred de solo proxy. No se pueden crear reglas de cortafuegos que permitan o denieguen el tráfico de entrada en estos backends en función del VIP de la regla de reenvío que utilice un cliente.

A continuación, se muestran algunos ejemplos de cómo usar reglas de cortafuegos de salida para restringir el tráfico a la dirección IP virtual de la regla de reenvío del balanceador de carga.

Consola

Para identificar las VMs de cliente, etiqueta las VMs específicas que quieras restringir. Estas etiquetas se usan para asociar reglas de cortafuegos con las VMs de cliente etiquetadas. A continuación, añade la etiqueta al campo TARGET_TAG siguiendo estos pasos.

Para configurarlo, puedes usar una o varias reglas de cortafuegos.

Regla de cortafuegos de salida única

Puedes configurar una regla de salida de cortafuegos para denegar todo el tráfico de salida que vaya desde las VMs de cliente etiquetadas a la VIP de un balanceador de carga.

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

   Ir a reglas de cortafuegos

2. Haga clic en Crear regla de cortafuegos para crear la regla que deniegue el tráfico de salida de las VMs de cliente etiquetadas a la IP virtual de un balanceador de carga.

   • Nombre: fr-deny-access
   • Red: lb-network
   • Prioridad: 100
   • Dirección del tráfico: Salida
   • Acción tras coincidencia: Denegar
   • Objetivos: Etiquetas de destino especificadas
   • Etiquetas de destino: TARGET_TAG
   • Filtro de destino: Intervalos de IP
   • Intervalos de IPs de destino: 10.1.2.99
   • Protocolos y puertos:
     • Elige Protocolos y puertos especificados.
     • Selecciona la casilla tcp y, a continuación, introduce 80 como número de puerto.

3. Haz clic en Crear.

Varias reglas de cortafuegos de salida

Una estrategia más escalable consiste en definir dos reglas. Una regla predeterminada de baja prioridad que restringe el acceso de todos los clientes a la IP virtual del balanceador de carga. Una segunda regla de mayor prioridad que permite que un subconjunto de clientes etiquetados accedan a la dirección IP virtual del balanceador de carga. Solo las VMs etiquetadas pueden acceder a la IP virtual.

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

   Ir a reglas de cortafuegos

2. Haga clic en Crear regla de cortafuegos para crear la regla de menor prioridad que deniegue 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 tras coincidencia: Denegar
   • Objetivos: Etiquetas de destino especificadas
   • Etiquetas de destino: TARGET_TAG
   • Filtro de destino: Intervalos de IP
   • Intervalos de IPs de destino: 10.1.2.99
   • Protocolos y puertos:
     • Elige Protocolos y puertos especificados.
     • Selecciona la casilla TCP y, a continuación, introduce 80 como número de puerto.

3. Haz clic en Crear.

4. Haga clic en Crear regla de cortafuegos para crear la regla de mayor prioridad que permita el tráfico de determinadas instancias etiquetadas.

   • Nombre: fr-allow-some-access-high-priority
   • Red: lb-network
   • Prioridad: 100
   • Dirección del tráfico: Salida
   • Acción tras coincidencia: Permitir
   • Objetivos: Etiquetas de destino especificadas
   • Etiquetas de destino: TARGET_TAG
   • Filtro de destino: Intervalos de IP
   • Intervalos de IPs de destino: 10.1.2.99
   • Protocolos y puertos:
     • Elige Protocolos y puertos especificados.
     • Selecciona la casilla TCP y, a continuación, introduce 80 como número de puerto.

5. Haz clic en Crear.

gcloud

Para identificar las VMs de cliente, etiqueta las VMs específicas que quieras restringir. A continuación, añade la etiqueta al campo TARGET_TAG siguiendo estos pasos.

Para configurarlo, puedes usar una o varias reglas de cortafuegos.

Regla de cortafuegos de salida única

Puedes configurar una regla de salida de cortafuegos para denegar todo el tráfico de salida que vaya desde las VMs de cliente etiquetadas a la VIP de un balanceador de carga.

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 cortafuegos de salida

Un enfoque más escalable consiste en definir dos reglas: una regla predeterminada de baja prioridad que impida que todos los clientes accedan a la dirección IP virtual del balanceador de carga y una segunda regla de mayor prioridad que permita que un subconjunto de clientes etiquetados accedan a la dirección IP virtual del balanceador de carga. Solo las VMs etiquetadas pueden acceder a la VIP.

1. Crea la regla de menor prioridad:

   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 mayor prioridad:

   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 al crear reglas de cortafuegos.

Escalar el acceso restringido a los back-ends de los balanceadores de carga de aplicaciones internos en función de las subredes

Mantener reglas de cortafuegos independientes o añadir nuevas direcciones IP con balanceo de carga a las reglas existentes, tal como se describe en la sección anterior, resulta poco práctico a medida que aumenta el número de reglas de reenvío. Una forma de evitarlo es asignar direcciones IP de reglas de reenvío desde una subred reservada. Después, se puede permitir o bloquear el tráfico de las instancias o cuentas de servicio etiquetadas usando la subred reservada como intervalo de destino de las reglas de cortafuegos. De esta forma, puedes controlar de forma eficaz el acceso a un grupo de IPs virtuales de reglas de reenvío sin tener que mantener reglas de salida de cortafuegos por IP virtual.

A continuación, se indican los pasos generales para configurar esta opción, suponiendo que creará todos los demás recursos de balanceador de carga necesarios por separado.

gcloud

1. Crea una subred regional para asignar direcciones IP con balanceo de carga 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 cortafuegos para restringir el tráfico destinado al intervalo de direcciones IP de la subred de la regla 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
   

Configurar el subconjunto de backend

Vista previa

Este producto o función está sujeto a los "Términos de las Ofertas de Acceso Previo a la Disponibilidad General" de la sección Términos Generales de los Servicios de los Términos Específicos de los Servicios. Los productos y las funciones previos a la disponibilidad general están disponibles tal cual y pueden tener una compatibilidad y asistencia limitadas. Para obtener más información, consulta las descripciones de las fases de lanzamiento.

La creación de subconjuntos de backend mejora el rendimiento y la escalabilidad al asignar un subconjunto de backends a cada una de las instancias de proxy. Cuando se habilita para un servicio de backend, la creación de subconjuntos de backend ajusta el número de backends utilizados por cada instancia de proxy de la siguiente manera:

• A medida que aumenta el número de instancias de proxy que participan en el balanceador de carga, disminuye el tamaño del subconjunto.

• Cuando el número total de back-ends de una red supera la capacidad de una sola instancia de proxy, el tamaño del subconjunto se reduce automáticamente para cada servicio que tenga habilitado el subconjunto de back-ends.

Nota: En la API REST, el ajuste subsetting.subsetSize solo está disponible para Cloud Service Mesh. Este ajuste no está disponible para los balanceadores de carga de aplicaciones internos regionales.

En este ejemplo se muestra cómo crear recursos de balanceador de carga de aplicación interno regional y habilitar la creación de subconjuntos de backend:

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

2. Para habilitar el subconjunto de backend, especifica la marca --subsetting-policy como CONSISTENT_HASH_SUBSETTING. Define el esquema de balanceo de carga como INTERNAL_MANAGED.

   gcloud

   Usa el siguiente comando gcloud para actualizar l7-ilb-backend-service con el subconjunto de backend:

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

   API

   Haz 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 refinar el balanceo de carga de backend configurando la política localityLbPolicy. Para obtener más información, consulta las políticas de tráfico.

Usar la misma dirección IP en varias reglas de reenvío internas

Para que varias reglas de reenvío internas compartan la misma dirección IP interna, debe reservar la dirección IP y definir 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 redirigir el tráfico HTTP a HTTPS, puedes crear dos reglas de reenvío que usen una dirección IP común. Para obtener más información, consulta el artículo Configurar el redireccionamiento de HTTP a HTTPS para balanceadores de carga de aplicaciones internos.

Actualizar el tiempo de espera de keep-alive HTTP del cliente

El balanceador de carga creado en los pasos anteriores se ha configurado con un valor predeterminado para el tiempo de espera de keep-alive HTTP del cliente.

Para actualizar el tiempo de espera de keep-alive HTTP del cliente, sigue estas instrucciones.

Consola

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

   Ve a Balanceo de carga.

2. Haga clic en el nombre del balanceador de carga que quiera modificar.
3. Haz clic en Editar.
4. Haz clic en Configuración de frontend.
5. Despliega Funciones avanzadas. En Tiempo de espera de HTTP Keep-Alive, introduce un valor de tiempo de espera.
6. Haz clic en Actualizar.
7. Para revisar los cambios, haz clic en Revisar y finalizar y, a continuación, en Actualizar.

gcloud

En el caso de un balanceador de carga HTTP, actualiza el proxy HTTP de destino con el comando gcloud compute target-http-proxies update.

      gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --region=REGION
      

En el caso de un balanceador de carga HTTPS, actualice el proxy HTTPS de destino con el comando gcloud compute target-https-proxies update.

      gcloud compute target-https-proxies update TARGET_HTTP_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --region REGION
      

Haz los cambios siguientes:

• TARGET_HTTP_PROXY_NAME: nombre del proxy HTTP de destino.
• TARGET_HTTPS_PROXY_NAME: nombre del proxy HTTPS de destino.
• HTTP_KEEP_ALIVE_TIMEOUT_SEC: el valor del tiempo de espera de HTTP Keep-Alive de 5 a 600 segundos.

Siguientes pasos

• Convertir un balanceador de carga de aplicaciones a IPv6
• Descripción general del balanceador de carga de aplicaciones interno
• Subredes de solo proxy para balanceadores de carga basados en Envoy
• Sustituir o renovar un certificado SSL antes de que caduque
• Limpiar una configuración de balanceo de carga