Configura un balanceador de cargas de aplicaciones interno entre regiones con backends de grupos de instancias de VM

En este documento, se proporcionan instrucciones para configurar un balanceador de cargas de aplicaciones entre regiones interno en los servicios que se ejecutan en las instancias de máquina virtual (VM) de Compute Engine.

Antes de comenzar

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

• Descripción general del balanceador de cargas de aplicaciones interno, incluida la sección Limitaciones
• Descripción general de las reglas de firewall de VPC

Configura un recurso de certificado SSL

Crea un recurso de certificado SSL del Administrador de certificados como se describe a continuación:

• Implementa un certificado autoadministrado global.
• Crea un certificado administrado por Google emitido por tu instancia de Certificate Authority Service.
• Crea un certificado administrado por Google con autorización de DNS.

Recomendamos que uses un certificado administrado por Google.

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	Rol requerido
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:

• Funciones y permisos
• Condiciones de IAM para las reglas de reenvío

Descripción general de la configuración

Puedes configurar el balanceador de cargas como se muestra en el siguiente diagrama:

Implementación de alta disponibilidad del balanceador de cargas de aplicaciones interno entre regiones (haz clic para ampliar)

Como se muestra en el diagrama, este ejemplo crea un balanceador de cargas de aplicaciones interno entre regiones en una red de VPC, con un servicio de backend y dos grupos de instancias administrados de backend en las regiones REGION_A y REGION_B.

En el diagrama se muestra lo siguiente:

1. Una red de VPC con las siguientes subredes:

   • Una subred de SUBNET_A y una subred de solo proxy en REGION_A.
   • Una subred de SUBNET_B y una subred de solo proxy en REGION_B.

   Debes crear subredes de solo proxy en cada región de una red de VPC en la que uses balanceadores de cargas de aplicaciones interno entre regiones. La subred de solo proxy de la región se comparte entre todos los balanceadores de cargas de aplicaciones internos entre regiones de la región. Las direcciones de origen de los paquetes enviados desde los balanceadores de cargas a los backends de tu servicio se asignan desde la subred de solo proxy. En este ejemplo, la subred solo de proxy para la región REGION_A tiene el rango principal de direcciones IP de 10.129.0.0/23 y para REGION_B tiene un rango de direcciones IP principal de 10.130.0.0/23 que es el tamaño de subred recomendado.

2. La configuración de alta disponibilidad tiene backends de grupos de instancias administrados para implementaciones de VM de Compute Engine en regiones REGION_A y REGION_B. Si los backends en una región están inactivos, el tráfico se dirige a la otra región.

3. Un servicio de backend global que supervisa el uso y el estado de los backends.

4. Un mapa de URL global 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.

5. Un proxy HTTP o HTTPS de destino global, que recibe una solicitud del usuario y la reenvía al mapa de URL. Para HTTPS, configura un recurso de certificado SSL global. 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.

6. Las reglas de reenvío globales tienen la dirección IP interna regional 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 una subred en la misma red y región que los backends. 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 GLOBAL_MANAGED_PROXY.
   • Si deseas usar la misma dirección IP interna con varias reglas de reenvío, configura la marca de dirección IP --purpose como SHARED_LOADBALANCER_VIP.

7. Opcional: Configura las políticas de enrutamiento de DNS del tipo GEO para enrutar el tráfico del cliente a la VIP del balanceador de cargas en la región más cercana al cliente.

Configura la red y las subredes

Dentro de la red de VPC, configura una subred en cada región en la que estén configurados los backends. Además, configura un proxy-only-subnet en cada región en la que desees configurar 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 NETWORK.

• Subredes para backends.

  • Una subred llamada SUBNET_A en la región REGION_A usa 10.1.2.0/24 para su rango de IP principal.
  • Una subred llamada SUBNET_B en la región REGION_B usa 10.1.3.0/24 para su rango de IP principal.

• Subredes para proxies.

  • Una subred llamada PROXY_SN_A en la región REGION_A usa 10.129.0.0/23 para su rango de IP principal.
  • Una subred llamada PROXY_SN_B en la región REGION_B usa 10.130.0.0/23 para su rango de IP principal.

Se puede acceder a los balanceadores de cargas de aplicaciones internos entre regiones desde cualquier región dentro de la VPC. Los clientes de cualquier región pueden acceder de manera global a los backends del balanceador de cargas.

Nota: En los pasos posteriores de esta guía, se usan los parámetros de red, región y subred como se describió aquí.

Configura las subredes de backend

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. Proporciona un Nombre para la red.

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:

   • Proporciona un Nombre para la subred.
   • Selecciona una Región: REGION_A
   • Ingresa un Rango de direcciones IP: 10.1.2.0/24

6. Haz clic en Listo.

7. Haz clic en Agregar subred.

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

   • Proporciona un Nombre para la subred.
   • Selecciona una Región: REGION_B
   • Ingresa un Rango de direcciones IP: 10.1.3.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 NETWORK \
       --subnet-mode=custom
   

2. Crea una subred en la red NETWORK en la región REGION_A con el comando gcloud compute networks subnets create:

   gcloud compute networks subnets create SUBNET_A \
       --network=NETWORK \
       --range=10.1.2.0/24 \
       --region=REGION_A
   

3. Crea una subred en la red NETWORK en la región REGION_B con el comando gcloud compute networks subnets create:

   gcloud compute networks subnets create SUBNET_B \
       --network=NETWORK \
       --range=10.1.3.0/24 \
       --region=REGION_B
   

Terraform

Para crear la red de VPC, usa el recurso google_compute_network.

resource "google_compute_network" "default" {
  auto_create_subnetworks = false
  name                    = "lb-network-crs-reg"
  provider                = google-beta
}

Para crear la subred de VPC en la red lb-network-crs-reg, usa el recurso google_compute_subnetwork.

resource "google_compute_subnetwork" "subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.1.2.0/24"
  name          = "lbsubnet-uswest1"
  network       = google_compute_network.default.id
  region        = "us-west1"
}

resource "google_compute_subnetwork" "subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.1.3.0/24"
  name          = "lbsubnet-useast1"
  network       = google_compute_network.default.id
  region        = "us-east1"
}

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": "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/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/lb-network-crs-reg",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

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/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

Configura la subred solo de proxy

La subred solo de proxy proporciona un conjunto de direcciones IP que Google Cloud usa para ejecutar proxies de Envoy en tu nombre. Los proxies finalizan las conexiones del cliente y crean conexiones nuevas a los backends.

Todos los balanceadores de cargas regionales basados en Envoy usan esta subred de solo proxy en la misma región de la red de VPC . Solo puede haber una subred de solo proxy activa para un propósito determinado, por región, por red.

Importante: No intentes asignar direcciones de la subred de solo proxy a la regla de reenvío del balanceador de cargas o los backends. Debes asignar la dirección IP de la regla de reenvío y las direcciones IP de la instancia de backend desde un rango (o rangos) de subred diferente, no desde este. Google Cloud reserva este rango de subredes para los proxies que administra Google Cloud.

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.
3. En la pestaña Subred, haz clic en Agregar subred.
4. Proporciona un Nombre para la subred de solo proxy.
5. Selecciona una Región: REGION_A
6. En la lista Propósito, selecciona Proxy administrado entre regiones.
7. En el campo Rango de direcciones IP, ingresa 10.129.0.0/23.
8. Haz clic en Agregar.

Crea la subred de solo proxy en REGION_B

1. En la pestaña Subred, haz clic en Agregar subred.
2. Proporciona un Nombre para la subred de solo proxy.
3. Selecciona una Región: REGION_B
4. En la lista Propósito, selecciona Proxy administrado entre regiones.
5. En el campo Rango de direcciones IP, ingresa 10.130.0.0/23.
6. Haz clic en Agregar.

gcloud

Crea las subredes solo de proxy con el comando gcloud compute networks subnets create.

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23
    

    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23
    

Terraform

Para crear la subred solo de proxy de VPC en la red lb-network-crs-reg, usa el recurso google_compute_subnetwork.

resource "google_compute_subnetwork" "proxy_subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.129.0.0/23"
  name          = "proxy-only-subnet1"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-west1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}

resource "google_compute_subnetwork" "proxy_subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.130.0.0/23"
  name          = "proxy-only-subnet2"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-east1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}

API

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

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": " PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   

Configura reglas de firewall

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

• fw-ilb-to-backends. 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 esde cualquier dirección. Puedes elegir un rango de direcciones IP de origen más restrictivo para esta regla; por ejemplo, puedes especificar solo los rangos de direcciones 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-healthcheck. 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-backends. 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-ilb-to-backends
   • Red: 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-healthcheck
   • Red: 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-backends
   • Red: 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 y 10.130.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-ilb-to-backends 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-ilb-to-backends \
       --network=NETWORK \
       --action=allow \
       --direction=ingress \
       --target-tags=allow-ssh \
       --rules=tcp:22
   

2. Crea la regla fw-healthcheck 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-healthcheck \
       --network=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-backends 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 solo de proxy, por ejemplo, 10.129.0.0/23 y 10.130.0.0/23.

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

Terraform

Para crear las reglas de firewall, usa el recurso google_compute_firewall.

resource "google_compute_firewall" "fw_healthcheck" {
  name          = "gl7-ilb-fw-allow-hc"
  provider      = google-beta
  direction     = "INGRESS"
  network       = google_compute_network.default.id
  source_ranges = ["130.211.0.0/22", "35.191.0.0/16", "35.235.240.0/20"]
  allow {
    protocol = "tcp"
  }
}

resource "google_compute_firewall" "fw_ilb_to_backends" {
  name          = "fw-ilb-to-fw"
  provider      = google-beta
  network       = google_compute_network.default.id
  source_ranges = ["0.0.0.0/0"]
  allow {
    protocol = "tcp"
    ports    = ["22", "80", "443", "8080"]
  }
}

resource "google_compute_firewall" "fw_backends" {
  name          = "gl7-ilb-fw-allow-ilb-to-backends"
  direction     = "INGRESS"
  network       = google_compute_network.default.id
  source_ranges = ["10.129.0.0/23", "10.130.0.0/23"]
  target_tags   = ["http-server"]
  allow {
    protocol = "tcp"
    ports    = ["80", "443", "8080"]
  }
}

API

Crea la regla de firewall fw-ilb-to-backends 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-ilb-to-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "0.0.0.0/0"
 ],
 "targetTags": [
   "allow-ssh"
 ],
 "allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [
      "22"
    ]
  }
 ],
"direction": "INGRESS"
}

Crea la regla de firewall fw-healthcheck 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-healthcheck",
 "network": "projects/PROJECT_ID/global/networks/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-backends 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-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "10.129.0.0/23",
   "10.130.0.0/23"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "80"
     ]
   },
 {
     "IPProtocol": "tcp",
     "ports": [
       "443"
     ]
   },
   {
     "IPProtocol": "tcp",
     "ports": [
       "8080"
     ]
   }
 ],
 "direction": "INGRESS"
}

Crea un grupo de instancias administrado

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

Consola

1. 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 gil7-backendeast1-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: NETWORK
         • Subred: SUBNET_B

   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://169.254.169.254/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2
      

   7. Haz clic en Crear.

   8. Haz clic en Crear plantilla de instancias.

   9. En Nombre, ingresa gil7-backendwest1-template.

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

   11. Haz clic en Opciones avanzadas.

   12. 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: NETWORK
          • Subred: SUBNET_A

   13. 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://169.254.169.254/computeMetadata/v1/instance/name)"
       echo "Page served from: $vm_hostname" | \
       tee /var/www/html/index.html
       systemctl restart apache2
       

   14. Haz clic en Crear.

2. 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 gl7-ilb-mig-a.
   4. En Ubicación, selecciona Zona única.
   5. En Región, selecciona REGION_A.
   6. En Zona, selecciona ZONE_A.
   7. En Plantilla de instancias, selecciona gil7-backendwest1-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.

   10. Haz clic en Crear grupo de instancias.

   11. Selecciona Nuevo grupo de instancias administrado (sin estado). Para obtener más información, consulta MIG sin estado o con estado.

   12. En Nombre, ingresa gl7-ilb-mig-b.

   13. En Ubicación, selecciona Zona única.

   14. En Región, selecciona REGION_B.

   15. En Zona, selecciona ZONE_B.

   16. En Plantilla de instancias, selecciona gil7-backendeast1-template.

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

   18. Haz clic en Crear.

gcloud

En las instrucciones de gcloud CLI 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 gil7-backendwest1-template \
     --region=REGION_A \
     --network=NETWORK \
     --subnet=SUBNET_A \
     --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://169.254.169.254/computeMetadata/v1/instance/name)"
       echo "Page served from: $vm_hostname" | \
       tee /var/www/html/index.html
       systemctl restart apache2'
   

   gcloud compute instance-templates create gil7-backendeast1-template \
       --region=REGION_B \
       --network=NETWORK \
       --subnet=SUBNET_B \
       --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://169.254.169.254/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 gl7-ilb-mig-a \
       --zone=ZONE_A \
       --size=2 \
       --template=gil7-backendwest1-template
   

   gcloud compute instance-groups managed create gl7-ilb-mig-b \
       --zone=ZONE_B \
       --size=2 \
       --template=gil7-backendeast1-template
   

Terraform

Para crear la plantilla de instancias, usa el recurso google_compute_instance_template.

resource "google_compute_instance_template" "instance_template_a" {
  name         = "gil7-backendwest1-template"
  provider     = google-beta
  machine_type = "e2-small"
  region       = "us-west1"
  tags         = ["http-server"]

  network_interface {
    network    = google_compute_network.default.id
    subnetwork = google_compute_subnetwork.subnet_a.id
    access_config {
      # add external ip to fetch packages
    }
  }
  disk {
    source_image = "debian-cloud/debian-11"
    auto_delete  = true
    boot         = true
  }

  # install nginx and serve a simple web page
  metadata = {
    startup-script = <<-EOF1
      #! /bin/bash
      set -euo pipefail

      export DEBIAN_FRONTEND=noninteractive
      apt-get update
      apt-get install -y nginx-light jq

      NAME=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/hostname")
      IP=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip")
      METADATA=$(curl -f -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=True" | jq 'del(.["startup-script"])')

      cat <<EOF > /var/www/html/index.html
      <pre>
      Name: $NAME
      IP: $IP
      Metadata: $METADATA
      </pre>
      EOF
    EOF1
  }
  lifecycle {
    create_before_destroy = true
  }
}

resource "google_compute_instance_template" "instance_template_b" {
  name         = "gil7-backendeast1-template"
  provider     = google-beta
  machine_type = "e2-small"
  region       = "us-east1"
  tags         = ["http-server"]

  network_interface {
    network    = google_compute_network.default.id
    subnetwork = google_compute_subnetwork.subnet_b.id
    access_config {
      # add external ip to fetch packages
    }
  }
  disk {
    source_image = "debian-cloud/debian-11"
    auto_delete  = true
    boot         = true
  }

  # install nginx and serve a simple web page
  metadata = {
    startup-script = <<-EOF1
      #! /bin/bash
      set -euo pipefail

      export DEBIAN_FRONTEND=noninteractive
      apt-get update
      apt-get install -y nginx-light jq

      NAME=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/hostname")
      IP=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip")
      METADATA=$(curl -f -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=True" | jq 'del(.["startup-script"])')

      cat <<EOF > /var/www/html/index.html
      <pre>
      Name: $NAME
      IP: $IP
      Metadata: $METADATA
      </pre>
      EOF
    EOF1
  }
  lifecycle {
    create_before_destroy = true
  }
}

Para crear el grupo de instancias administrado, usa el recurso google_compute_instance_group_manager.

resource "google_compute_region_instance_group_manager" "mig_a" {
  name     = "gl7-ilb-miga"
  provider = google-beta
  region   = "us-west1"
  version {
    instance_template = google_compute_instance_template.instance_template_a.id
    name              = "primary"
  }
  base_instance_name = "vm"
  target_size        = 2
}

resource "google_compute_region_instance_group_manager" "mig_b" {
  name     = "gl7-ilb-migb"
  provider = google-beta
  region   = "us-east1"
  version {
    instance_template = google_compute_instance_template.instance_template_b.id
    name              = "primary"
  }
  base_instance_name = "vm"
  target_size        = 2
}

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":"gil7-backendwest1-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://169.254.169.254/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/NETWORK",
         "subnetwork":"regions/REGION_A/subnetworks/SUBNET_A",
         "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": "gl7-ilb-mig-a",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil7-backendwest1-template",
  "baseInstanceName": "gl7-ilb-mig-b",
  "targetSize": 2
}

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

{
  "name":"gil7-backendeast1-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://169.254.169.254/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/NETWORK",
         "subnetwork":"regions/REGION_B/subnetworks/SUBNET_B",
         "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": "gl7-ilb-mig-b",
  "zone": "projects/PROJECT_ID/zones/ZONE_B",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil7-backendwest1-template",
  "baseInstanceName": "gl7-ilb-mig-b",
  "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 entre regiones:

• Una verificación de estado de HTTP global.
• Un servicio de backend global con los grupos de instancias administrados como backend.
• Un mapa de URL Asegúrate de hacer referencia a un mapa de URL global para el proxy HTTP(S) de destino. Un mapa de URL global enruta las solicitudes a un servicio de backend global en función de las reglas que definas para el host y la ruta de acceso de una URL entrante. Se puede hacer referencia a un mapa de URL global mediante una regla de proxy de destino global.
• Un certificado SSL global (para HTTPS)
• Un proxy de destino global.

• Dos reglas de reenvío global con direcciones IP regionales. Para la dirección IP de la regla de reenvío, usa el rango de direcciones IP SUBNET_A o SUBNET_B. Si intentas usar la subred de solo proxy, la creación de la regla de reenvío fallará.

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 entre regiones y haz clic en Siguiente.
6. Haz clic en Configurar.

Configuración básica

1. Ingresa un Nombre para el balanceador de cargas.
2. En Red, selecciona NETWORK.

Configura el frontend con dos reglas de reenvío

Para HTTP:

1. Haz clic en Configuración de frontend.
1. Proporciona un nombre para la regla de reenvío.
2. En la lista Región de la subred, selecciona REGION_A.
   

   Reserva una subred de solo proxy

Si ya configuraste la subred de solo proxy, el botón Reservar una subred no se muestra. Puedes continuar con los pasos siguientes.
3. En la lista Subred, selecciona SUBNET_A.
4. En la lista Dirección IP, haz clic en Crear dirección IP. Se abrirá la página Reservar una dirección IP interna estática.
• Proporciona un Nombre para la dirección IP estática.
• En la sección Dirección IP estática, selecciona Permitirme elegir.
• En el campo Dirección IP personalizada, ingresa 10.1.2.99.
• Selecciona Reservar.
2. Haz clic en Listo.
3. Para agregar la segunda regla de reenvío, haz clic en Agregar IP y puerto de frontend.
1. Proporciona un nombre para la regla de reenvío.
2. En la lista Región de la subred, selecciona REGION_B.
   

   Reserva una subred de solo proxy

Debido a que ya configuraste la subred de solo proxy, el botón Reservar una subred no se muestra. Puedes continuar con los pasos siguientes.
3. En la lista Subred, selecciona SUBNET_B.
4. En la lista Dirección IP, haz clic en Crear dirección IP. Se abrirá la página Reservar una dirección IP interna estática.
• Proporciona un Nombre para la dirección IP estática.
• En la sección Dirección IP estática, selecciona Permitirme elegir.
• En el campo Dirección IP personalizada, ingresa 10.1.3.99.
• Selecciona Reservar.
4. Haz clic en Listo.

Para HTTPS:

Si usas HTTPS entre el cliente y el balanceador de cargas, necesitas uno o más recursos de certificado SSL para configurar el proxy. Para crear un certificado administrado por Google de all-regions, consulta la siguiente documentación:

• Crea un certificado administrado por Google emitido por tu instancia de Certificate Authority Service.
• Crea un certificado administrado por Google con autorización de DNS.

Después de crear el certificado administrado por Google, adjunta el certificado directamente al proxy de destino. Los mapas de certificados no son compatibles con los balanceadores de cargas de aplicaciones internos entre regiones.

Para crear un certificado autoadministrado de all-regions, consulta la siguiente documentación: Implementa un certificado autoadministrado regional.

1. Haz clic en Configuración de frontend.
1. Proporciona un nombre para la regla de reenvío.
2. En el campo Protocolo, selecciona HTTPS (includes HTTP/2).
3. Asegúrate de que el Puerto esté establecido en 443.
4. En la lista Región de la subred, selecciona REGION_A.
   

   Reserva una subred de solo proxy

Debido a que ya configuraste la subred de solo proxy, el botón Reservar una subred no se muestra. Puedes continuar con los pasos siguientes.
5. En la lista Subred, selecciona SUBNET_A.
6. En la lista Dirección IP, haz clic en Crear dirección IP. Se abrirá la página Reservar una dirección IP interna estática.
• Proporciona un Nombre para la dirección IP estática.
• En la sección Dirección IP estática, selecciona Permitirme elegir.
• En el campo Dirección IP personalizada, ingresa 10.1.3.99.
• Selecciona Reservar.
7. En la sección Agregar certificado, selecciona el certificado.
8. Opcional: Para agregar certificados además del certificado SSL principal, sigue estos pasos:
1. Haz clic en Agregar certificado.
2. Selecciona el certificado de la lista.
9. Selecciona una política de SSL de la lista Política de SSL. Si no creaste ninguna política de SSL, se aplica una política predeterminada de Google Cloud SSL.
10. Haz clic en Listo.

Agrega la segunda configuración de frontend:

1. Proporciona un Nombre para la configuración del frontend.
2. En el campo Protocolo, selecciona HTTPS (includes HTTP/2).
3. Asegúrate de que el Puerto esté establecido en 443.
4. En la lista Región de la subred, selecciona REGION_B.
   

   Reserva una subred de solo proxy

Debido a que ya configuraste la subred de solo proxy, el botón Reservar una subred no se muestra. Puedes continuar con los pasos siguientes.
5. En la lista Subred, selecciona SUBNET_B.
6. En la lista Dirección IP, haz clic en Crear dirección IP. Se abrirá la página Reservar una dirección IP interna estática.
• Proporciona un Nombre para la dirección IP estática.
• En la sección Dirección IP estática, selecciona Permitirme elegir.
• En el campo Dirección IP personalizada, ingresa 10.1.3.99.
• Selecciona Reservar.
7. En la sección Agregar certificado, selecciona el certificado.
8. Opcional: Para agregar certificados además del certificado SSL principal, sigue estos pasos:
1. Haz clic en Agregar certificado.
2. Selecciona el certificado de la lista.
9. Selecciona una política de SSL de la lista Política de SSL. Si no creaste ninguna política de SSL, se aplica una política predeterminada de Google Cloud SSL.
10. Haz clic en Listo.
Configura el servicio de backend
1. Haz clic en Configuración de backend.
2. En la lista Crear o seleccionar servicios de backend, haz clic en Crear un servicio de backend.
3. Proporciona un Nombre para el servicio de backend.
4. En Protocolo, selecciona HTTP.
5. En Puerto con nombre, ingresa http.
6. En la lista Tipo de backend, selecciona Grupo de instancias.
7. En la sección Nuevo backend, sigue estos pasos:
• En la lista Grupo de instancias, selecciona gl4-ilb-miga en REGION_A.
• Establece Números de puerto en 80.
• Haz clic en Listo.
• Para agregar otro backend, haz clic en Agregar backend.
• En la lista Grupo de instancias, selecciona gl4-ilb-migb en REGION_B.
• Establece Números de puerto en 80.
• Haz clic en Listo.
8. En la sección Verificación de estado, haz clic en Crea una verificación de estado.
• En el campo Nombre, ingresa global-http-health-check.
• Establece el Protocolo en HTTP.
• Configura el Puerto como 80.
• Haz clic en Guardar.

Configura las reglas de enrutamiento

1. Haga clic en Reglas de enrutamiento.
2. En Modo, selecciona Regla sencilla de host y ruta de acceso.
3. Asegúrate de que haya un solo servicio de backend para los hosts y las rutas de acceso no coincidentes.

Revisa la configuración

1. Haz clic en Revisar y finalizar.
2. Revisa la configuración del balanceador de cargas.
3. 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 global-http-health-check \
      --use-serving-port \
      --global
   

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

   gcloud compute backend-services create BACKEND_SERVICE_NAME \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --protocol=HTTP \
     --enable-logging \
     --logging-sample-rate=1.0 \
     --health-checks=global-http-health-check \
     --global-health-checks \
     --global
   

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

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --balancing-mode=UTILIZATION \
     --instance-group=gl7-ilb-mig-a \
     --instance-group-zone=ZONE_A \
     --global
   

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --balancing-mode=UTILIZATION \
     --instance-group=gl7-ilb-mig-b \
     --instance-group-zone=ZONE_B \
     --global
   

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

   gcloud compute url-maps create gl7-gilb-url-map \
     --default-service=BACKEND_SERVICE_NAME \
     --global
   

5. Crea el proxy de destino.

   Para HTTP:

   Crea el proxy de destino con el comando gcloud compute target-http-proxies create.

   gcloud compute target-http-proxies create gil7-http-proxy \
     --url-map=gl7-gilb-url-map \
     --global
   

   Para HTTPS:

   Para crear un certificado administrado por Google, consulta la siguiente documentación:

   • Crea un certificado administrado por Google emitido por tu instancia de Certificate Authority Service.
   • Crea un certificado administrado por Google con autorización de DNS.

   Después de crear el certificado administrado por Google, adjúntalo directamente al proxy de destino. Los mapas de certificados no son compatibles con los balanceadores de cargas de aplicaciones internos entre regiones.

   Para crear un certificado autoadministrado, consulta la siguiente documentación:

   • Crea una clave privada y un certificado.

   Asigna tus rutas de archivos a nombres de variables.

   export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
   

   export LB_PRIVATE_KEY=PATH_TO_LB_PRIVATE_KEY_FILE
   

   Crea un certificado SSL para todas las regiones con el comando gcloud beta certificate-manager certificates create.

   gcloud certificate-manager certificates create gilb-certificate \
     --private-key-file=$LB_PRIVATE_KEY \
     --certificate-file=$LB_CERT \
     --scope=all-regions
   

   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 gil7-https-proxy \
     --url-map=gl7-gilb-url-map \
     --certificate-manager-certificates=gilb-certificate \
     --global
   

6. Crea dos reglas de reenvío, una con una VIP (10.1.2.99) en la región REGION_B y otra con una VIP (10.1.3.99) en la región REGION_A. Para obtener más información, consulta Reserva una dirección IPv4 interna estática.

   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 FWRULE_A \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=NETWORK \
     --subnet=SUBNET_A \
     --subnet-region=REGION_A \
     --address=10.1.2.99 \
     --ports=80 \
     --target-http-proxy=gil7-http-proxy \
     --global
   

   gcloud compute forwarding-rules create FWRULE_B \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=NETWORK \
     --subnet=SUBNET_B \
     --subnet-region=REGION_B \
     --address=10.1.3.99 \
     --ports=80 \
     --target-http-proxy=gil7-http-proxy \
     --global
   

   Para HTTPS:

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

   gcloud compute forwarding-rules create FWRULE_A \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=NETWORK \
     --subnet=SUBNET_A \
     --subnet-region=REGION_A \
     --address=10.1.2.99 \
     --ports=443 \
     --target-https-proxy=gil7-https-proxy \
     --global
   

   gcloud compute forwarding-rules create FWRULE_B \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=NETWORK \
     --subnet=SUBNET_B \
     --subnet-region=REGION_B \
     --address=10.1.3.99 \
     --ports=443 \
     --target-https-proxy=gil7-https-proxy \
     --global
   

Terraform

Para crear la verificación de estado, usa el recurso google_compute_health_check.

resource "google_compute_health_check" "default" {
  provider = google-beta
  name     = "global-http-health-check"
  http_health_check {
    port_specification = "USE_SERVING_PORT"
  }
}

Para crear el servicio de backend, usa el recurso google_compute_backend_service.

resource "google_compute_backend_service" "default" {
  name                  = "gl7-gilb-backend-service"
  provider              = google-beta
  protocol              = "HTTP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  timeout_sec           = 10
  health_checks         = [google_compute_health_check.default.id]
  backend {
    group           = google_compute_region_instance_group_manager.mig_a.instance_group
    balancing_mode  = "UTILIZATION"
    capacity_scaler = 1.0
  }
  backend {
    group           = google_compute_region_instance_group_manager.mig_b.instance_group
    balancing_mode  = "UTILIZATION"
    capacity_scaler = 1.0
  }
}

Para crear el mapa de URL, usa el recurso google_compute_url_map.

resource "google_compute_url_map" "default" {
  name            = "gl7-gilb-url-map"
  provider        = google-beta
  default_service = google_compute_backend_service.default.id
}

Para crear el proxy HTTP de destino, usa el google_compute_target_http_proxy recurso.

resource "google_compute_target_http_proxy" "default" {
  name     = "gil7target-http-proxy"
  provider = google-beta
  url_map  = google_compute_url_map.default.id
}

Para crear la regla de reenvío, usa e google_compute_forwarding_rule recurso.

resource "google_compute_global_forwarding_rule" "fwd_rule_a" {
  provider              = google-beta
  depends_on            = [google_compute_subnetwork.proxy_subnet_a]
  ip_address            = "10.1.2.99"
  ip_protocol           = "TCP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  name                  = "gil7forwarding-rule-a"
  network               = google_compute_network.default.id
  port_range            = "80"
  target                = google_compute_target_http_proxy.default.id
  subnetwork            = google_compute_subnetwork.subnet_a.id
}

resource "google_compute_global_forwarding_rule" "fwd_rule_b" {
  provider              = google-beta
  depends_on            = [google_compute_subnetwork.proxy_subnet_b]
  ip_address            = "10.1.3.99"
  ip_protocol           = "TCP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  name                  = "gil7forwarding-rule-b"
  network               = google_compute_network.default.id
  port_range            = "80"
  target                = google_compute_target_http_proxy.default.id
  subnetwork            = google_compute_subnetwork.subnet_b.id
}

Si deseas obtener más información para aplicar o quitar una configuración de Terraform, consulta los comandos básicos de Terraform.

API

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

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

{
"name": "global-http-health-check",
"type": "HTTP",
"httpHealthCheck": {
  "portSpecification": "USE_SERVING_PORT"
}
}

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

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

{
"name": "BACKEND_SERVICE_NAME",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl7-ilb-mig-a",
    "balancingMode": "UTILIZATION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl7-ilb-mig-b",
    "balancingMode": "UTILIZATION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/global/healthChecks/global-http-health-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

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

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

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME"
}

Para HTTP:

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

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

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

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/global/forwardingRules

{
"name": "FWRULE_A",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

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

{
"name": "gil7forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Para HTTPS:

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

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 targetHttpsProxies.insert y reemplaza PROJECT_ID por el ID del proyecto.

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

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

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

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

{
"name": "FWRULE_A",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

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

{
"name": "FWRULE_B",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Prueba el balanceador de cargas

Crea una instancia de VM para probar la conectividad

1. Crea una VM de cliente:

   gcloud compute instances create l7-ilb-client-a \
       --image-family=debian-12 \
       --image-project=debian-cloud \
       --network=NETWORK \
       --subnet=SUBNET_A \
       --zone=ZONE_A \
       --tags=allow-ssh
   

   gcloud compute instances create l7-ilb-client-b \
       --image-family=debian-12 \
       --image-project=debian-cloud \
       --network=NETWORK \
       --subnet=SUBNET_B \
       --zone=ZONE_B \
       --tags=allow-ssh
   

2. Usa SSH para conectarte a cada instancia de cliente.

   gcloud compute ssh l7-ilb-client-a --zone=ZONE_A
   

   gcloud compute ssh l7-ilb-client-b --zone=ZONE_B
   

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

   • Verifica que la VM del cliente pueda acceder a ambas direcciones IP. El comando muestra el nombre de la VM de backend que entregó la solicitud:

     curl 10.1.2.99
     

     curl 10.1.3.99
     

     Para la prueba de HTTPS, reemplaza curl por la siguiente línea de comandos:

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

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

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

   • Opcional: Usa el registro DNS configurado para resolver la dirección IP más cercana a la VM del cliente. Por ejemplo, DNS_NAME puede ser service.example.com.

     curl DNS_NAME
     

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

Para HTTP:

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

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

Para HTTPS:

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

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

Prueba la conmutación por error

1. Verifica la conmutación por error a los backends en la región REGION_A cuando los backends en REGION_B estén en mal estado o sean inaccesibles. Para simular la conmutación por error, quita todos los backends de REGION_B:

   gcloud compute backend-services remove-backend BACKEND_SERVICE_NAME \
      --balancing-mode=UTILIZATION \
      --instance-group=gl7-ilb-mig-b \
      --instance-group-zone=ZONE_B
   

2. Conéctate mediante SSH a una VM de cliente en REGION_B.

   gcloud compute ssh l7-ilb-client-b \
      --zone=ZONE_B
   

3. Envía solicitudes a la dirección IP del balanceo de cargas en la región REGION_B. El resultado del comando muestra respuestas de las VMs de backend en REGION_A:

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

Opciones de configuración adicionales

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

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 gil7-backend-service (el nombre del servicio de backend que creaste para este ejemplo) y, luego, 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 gil7-backend-service \
        --session-affinity=[GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | CLIENT_IP] \
        --global
    

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]/global/backendServices/gil7-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.

Consola

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 \
     --global \
     --target-http-proxy=gil7-http-proxy
   

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
   

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.

Configura políticas de enrutamiento de DNS

Si tus clientes están en varias regiones, es posible que desees hacer que el balanceador de cargas de aplicaciones interno entre regiones sea accesible mediante VIPs en estas regiones. Esta configuración de varias regiones minimiza la latencia y los costos de tránsito de red. Además, te permite configurar una solución de balanceo de cargas global basada en DNS que proporcione resiliencia contra interrupciones regionales. Para obtener más información, consulta Administra las políticas de enrutamiento de DNS y las verificaciones de estado.

gcloud

Para crear una entrada de DNS con un TTL de 30 segundos, usa el comando gcloud dns record-sets create.

gcloud dns record-sets create DNS_ENTRY --ttl="30" \
  --type="A" --zone="service-zone" \
  --routing-policy-type="GEO" \
  --routing-policy-data="REGION_A=gil7-forwarding-rule-a@global;REGION_B=gil7-forwarding-rule-b@global" \
  --enable-health-checking

Reemplaza lo siguiente:

• DNS_ENTRY: el nombre de dominio o DNS del conjunto de registros.

  Por ejemplo, service.example.com

• REGION_A y REGION_B: las regiones en las que configuraste el balanceador de cargas.

API

Para crear el registro DNS, realiza una solicitud POST al método ResourceRecordSets.create. Reemplaza PROJECT_ID con el ID del proyecto.

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/SERVICE_ZONE/rrsets
{
  "name": "DNS_ENTRY",
  "type": "A",
  "ttl": 30,
  "routingPolicy": {
    "geo": {
      "items": [
        {
          "location": "REGION_A",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        },
        {
          "location": "REGION_B",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS_B",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        }
      ]
    }
  }
}

Actualiza el tiempo de espera de keepalive del HTTP del cliente

El balanceador de cargas creado en los pasos anteriores se configuró con un valor predeterminado para el tiempo de espera de keepalive de HTTP del cliente.

Para actualizar el tiempo de espera de keepalive del cliente HTTP, sigue las siguientes instrucciones.

Console

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

   Ir a Balanceo de cargas

2. Haz clic en el nombre del balanceador de cargas que deseas modificar.
3. Haz clic en Editar.
4. Haz clic en Configuración de frontend.
5. Expande Funciones avanzadas. Para el tiempo de espera de keepalive de HTTP, ingresa un valor de tiempo de espera.
6. Haz clic en Actualizar.
7. Para revisar los cambios, haz clic en Revisar y finalizar y, luego, haz clic en Actualizar.

gcloud

Para un balanceador de cargas de HTTP, actualiza el proxy HTTP de destino con el comandogcloud 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 \
        --global
    

Para un balanceador de cargas de HTTPS, actualiza el proxy HTTPS de destino con el comandogcloud compute target-https-proxies update:

    gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \
        --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
        --global
    

Reemplaza lo siguiente:

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

Habilitar la detección de valores atípicos

Puedes habilitar la detección de valores atípicos en los servicios de backend globales para identificar los NEGs sin servidores y reducir la cantidad de solicitudes enviadas a los NEGs sin servidores en mal estado.

La detección de valores atípicos se habilita en el servicio de backend con uno de los siguientes métodos:

• El método consecutiveErrors (outlierDetection.consecutiveErrors), en el que un código de estado HTTP de la serie 5xx califica como un error.
• El método consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), en el que solo los códigos de estado HTTP 502, 503 y 504 califican como un error.

Sigue los pasos a continuación para habilitar la detección de valores atípicos para un servicio de backend existente. Ten en cuenta que, incluso después de habilitar la detección de valores atípicos, algunas solicitudes se pueden enviar al servicio deteriorado y mostrar un código de estado 5xx a los clientes. Para reducir aún más la tasa de error, puedes configurar valores más agresivos para los parámetros de detección de valores atípicos. Para obtener más información, consulta el campo outlierDetection.

Console

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

   Ir a Balanceo de cargas

2. Haz clic en el nombre del balanceador de cargas cuyo servicio de backend quieres editar.

3. En la página Detalles del balanceador de cargas, haz clic en Editar.

4. En la página Editar balanceador de cargas de aplicaciones interno entre regiones, haz clic en Configuración de backend.

5. En la página de Configuración de backend, haz clic en Editar en el servicio de backend que deseas modificar.

6. Desplázate hacia abajo y expande la sección Configuración avanzada.

7. En la sección Detección de valores atípicos, selecciona la casilla de verificación Habilitar.

8. Haz clic en Editar para configurar la detección de valores atípicos.

   Verifica que las siguientes opciones estén configuradas con estos valores:

   Propiedad	Valor
   Errores consecutivos	5
   Interval	1000
   Tiempo de expulsión base	30,000
   Porcentaje de expulsión máximo	50
   Aplicación de errores consecutivos	100

   En este ejemplo, el análisis de detección de valores atípicos se ejecuta cada segundo. Si la cantidad de códigos de estado HTTP 5xx consecutivos que recibe un proxy de Envoy es de cinco o más, el extremo de backend se expulsa del grupo de balanceo de cargas de ese proxy de Envoy durante 30 segundos. Cuando el porcentaje de aplicación forzosa se establece en 100%, el servicio de backend aplica la expulsión de los extremos en mal estado de los grupos de balanceo de cargas de esos proxies de Envoy específicos cada vez que se ejecuta el análisis de detección de valores atípicos. Si se cumplen las condiciones de expulsión, se puede expulsar hasta el 50% de los extremos de backend del grupo de balanceo de cargas.

9. Haz clic en Guardar.

10. Para actualizar el servicio de backend, haz clic en Actualizar.

11. Para actualizar el balanceador de cargas, en la página Edita el balanceador de cargas de aplicaciones interno entre regiones, haz clic en Actualizar.

gcloud

1. Exporta el servicio de backend a un archivo YAML.

   gcloud compute backend-services export BACKEND_SERVICE_NAME \
     --destination=BACKEND_SERVICE_NAME.yaml --global
   

   Reemplaza BACKEND_SERVICE_NAME por el nombre del servicio de backend.

2. Edita la configuración YAML del servicio de backend para agregar los campos para la detección de valores atípicos, como se destaca en la siguiente configuración de YAML, en la sección outlierDetection:

   En este ejemplo, el análisis de detección de valores atípicos se ejecuta cada segundo. Si la cantidad de códigos de estado HTTP 5xx consecutivos que recibe un proxy de Envoy es de cinco o más, el extremo de backend se expulsa del grupo de balanceo de cargas de ese proxy de Envoy durante 30 segundos. Cuando el porcentaje de aplicación forzosa se establece en 100%, el servicio de backend aplica la expulsión de los extremos en mal estado de los grupos de balanceo de cargas de esos proxies de Envoy específicos cada vez que se ejecuta el análisis de detección de valores atípicos. Si se cumplen las condiciones de expulsión, se puede expulsar hasta el 50% de los extremos de backend del grupo de balanceo de cargas.

   name: BACKEND_SERVICE_NAME
   backends:
   - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME
   - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2
   outlierDetection:
     baseEjectionTime:
       nanos: 0
       seconds: 30
     consecutiveErrors: 5
     enforcingConsecutiveErrors: 100
     interval:
       nanos: 0
       seconds: 1
     maxEjectionPercent: 50
   port: 80
   selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME
   sessionAffinity: NONE
   timeoutSec: 30
   ...
   

   Reemplaza lo siguiente:

   • BACKEND_SERVICE_NAME: es el nombre del servicio de backend.
   • PROJECT_ID: Es el ID de tu proyecto.
   • REGION_A y REGION_B: las regiones en las que se configuró el balanceador de cargas.
   • SERVERLESS_NEG_NAME: Es el nombre del primer NEG sin servidores.
   • SERVERLESS_NEG_NAME_2: es el nombre del segundo NEG sin servidores.

3. Para actualizar el servicio de backend, importa la configuración más reciente.

   gcloud compute backend-services import BACKEND_SERVICE_NAME \
     --source=BACKEND_SERVICE_NAME.yaml --global
   

   La detección de valores atípicos ahora está habilitada en el servicio de backend.

¿Qué sigue?

• Convierte el balanceador de cargas de aplicaciones a IPv6
• Descripción general del balanceador de cargas de aplicaciones interno
• Subredes de solo proxy para balanceadores de cargas basados en Envoy
• Administrar certificados
• Limpia una configuración de balanceo de cargas