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

En este documento, se proporcionan instrucciones para configurar un balanceador de cargas de red del proxy interno entre regiones en los servicios que se ejecutan en las VMs de Compute Engine.

Antes de comenzar

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

Permisos

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

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

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

Descripción general de la configuración

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

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

Como se muestra en el diagrama, este ejemplo crea un balanceador de cargas de red del proxy interno entre regiones en una red de VPC, con un servicio de backend y dos grupos de instancias administrados de backend en la región REGION_A y las regiones 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 red del proxy interno entre regiones. La subred de solo proxy de la región se comparte entre todos los balanceadores de cargas de red del proxy 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_B tiene el rango principal de direcciones IP de 10.129.0.0/23 y para REGION_A 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 proxy TCP de destino global, que recibe una solicitud del usuario y la reenvía al servicio de backend.

  5. Reglas de reenvío globales, que tienen la dirección IP interna regional de tu balanceador de cargas y pueden 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.

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.

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.

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 desde 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 desde los proxies administrados del balanceador de cargas de red del proxy 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 red del proxy interno se conecten con los backends. Configura source-ranges en los rangos asignados de tu subred de solo proxy, por ejemplo, 10.129.0.0/23 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

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 red del proxy 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.

Console

  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 gil4-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 gil4-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 gl4-ilb-miga.
    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 gil4-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 gl4-ilb-migb.

    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 gil4-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 gil4-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 gil4-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 gl4-ilb-miga \
    --zone=ZONE_A \
    --size=2 \
    --template=gil4-backendwest1-template

    gcloud compute instance-groups managed create gl4-ilb-migb \
    --zone=ZONE_B \
    --size=2 \
    --template=gil4-backendeast1-template

API

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

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

{
  "name":"gil4-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
       }
     ]
  }
}

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

{
  "name":"gil4-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": "gl4-ilb-miga",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
  "baseInstanceName": "gl4-ilb-miga",
  "targetSize": 2
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl4-ilb-migb",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
  "baseInstanceName": "gl4-ilb-migb",
  "targetSize": 2
}

Configura el balanceador de cargas

En este ejemplo, se muestra cómo crear los siguientes recursos del balanceador de cargas de red del proxy interno entre regiones:

  • Una verificación de estado de TCP global.
  • Un servicio de backend global con los mismos MIG que el backend.
  • 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á.

Disponibilidad del proxy

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

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

  • Espera a que se resuelva el problema de capacidad.

Console

Inicia la configuración

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

    Ir a Balanceo de cargas

  2. Haz clic en Crear balanceador de cargas.
  3. En Tipo de balanceador de cargas, selecciona Balanceador de cargas de red (TCP/UDP/SSL) y haz clic en Siguiente.
  4. En Proxy o transferencia, selecciona Balanceador de cargas de proxy y haz clic en Siguiente.
  5. En Orientado al público o interno, selecciona Interno y haz clic en Siguiente.
  6. En Implementación entre regiones o de una sola región, selecciona Ideal para cargas de trabajo entre regiones y haz clic en Siguiente.
  7. 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

  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 subred, selecciona REGION_A.

      Reserva una subred de solo proxy

    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 subred, selecciona REGION_B.

      Reserva una subred de solo proxy

    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.
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 Protocol, selecciona TCP.
  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.

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 TCP con el comando gcloud compute health-checks create tcp.

    gcloud compute health-checks create tcp global-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 gl4-gilb-backend-service \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=TCP \
  --enable-logging \
  --logging-sample-rate=1.0 \
  --health-checks=global-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 gl4-gilb-backend-service \
  --balancing-mode=CONNECTION \
  --max-connections=50 \
  --instance-group=gl4-ilb-miga \
  --instance-group-zone=ZONE_A \
  --global

    gcloud compute backend-services add-backend gl4-gilb-backend-service \
  --balancing-mode=CONNECTION \
  --max-connections=50 \
  --instance-group=gl4-ilb-migb \
  --instance-group-zone=ZONE_B \
  --global

  4. Crea el proxy de destino.

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

    gcloud compute target-tcp-proxies create gilb-tcp-proxy \
  --backend-service=gl4-gilb-backend-service \
  --global

  5. Crea dos reglas de reenvío, una con una VIP (10.1.2.99) en REGION_B y otra con una VIP (10.1.3.99) en 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.

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

    gcloud compute forwarding-rules create gil4forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --subnet-region=REGION_A \
  --address=10.1.2.99 \
  --ports=80 \
  --target-tcp-proxy=gilb-tcp-proxy \
  --global

    gcloud compute forwarding-rules create gil4forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --subnet-region=REGION_B \
  --address=10.1.3.99 \
  --ports=80 \
  --target-tcp-proxy=gilb-tcp-proxy \
  --global

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-health-check",
"type": "TCP",
"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": "gl4-gilb-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl4-ilb-miga",
    "balancingMode": "CONNECTION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl4-ilb-migb",
    "balancingMode": "CONNECTION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/global/healthChecks/global-health-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

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

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

{
"name": "l4-ilb-proxy",
}

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": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-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": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-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 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": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-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": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-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 en las regiones REGION_B y REGION_A:

    gcloud compute instances create l4-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 l4-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 l4-ilb-client-a --zone=ZONE_A

    gcloud compute ssh l4-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 debería ejecutarse correctamente y mostrar el nombre de la VM de backend que entregó la solicitud:

      curl 10.1.2.99

      curl 10.1.3.99

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 gl4-gilb-backend-service \
  --instance-group=gl4-ilb-migb \
  --instance-group-zone=ZONE_B \
  --global

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

    gcloud compute ssh l4-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.

Protocolo PROXY para retener información de conexión del cliente

El balanceador de cargas de red de proxy interno finaliza las conexiones TCP del cliente y crea conexiones nuevas con las instancias. De forma predeterminada, no se conservan la IP de cliente original y la información del puerto.

Para conservar y enviar la información de conexión original a tus instancias, habilita el protocolo PROXY (versión 1). Este protocolo envía a la instancia un encabezado adicional que contiene la dirección IP de origen, la dirección IP de destino y los números de puerto como parte de la solicitud.

Asegúrate de que las instancias de backend del balanceador de cargas de red del proxy interno ejecuten servidores HTTP o HTTPS que admitan encabezados del protocolo PROXY. Si los servidores HTTP o HTTPS no están configurados para admitir encabezados del protocolo PROXY, las instancias de backend muestran respuestas vacías. Por ejemplo, el protocolo PROXY no funciona con el software del servidor HTTP de Apache. Puedes usar diferentes softwares de servidor web, como Nginx.

Si configuras el protocolo PROXY para el tráfico de los usuarios, también debes configurarlo para las verificaciones de estado. Si verificas el estado y entregas contenido en el mismo puerto, configura el --proxy-header de la verificación de estado para que coincida con la configuración del balanceador de cargas.

Por lo general, el encabezado del protocolo PROXY será una sola línea de texto legible para el usuario con el siguiente formato:

PROXY TCP4 <client IP> <load balancing IP> <source port> <dest port>\r\n

A continuación, se muestra un ejemplo del protocolo PROXY:

PROXY TCP4 192.0.2.1 198.51.100.1 15221 110\r\n

En el ejemplo anterior, la IP de cliente es 192.0.2.1, la IP de balanceo de cargas es 198.51.100.1, el puerto del cliente es 15221 y el puerto de destino es 110.

Cuando no se conoce la IP de cliente, el balanceador de cargas genera un encabezado de protocolo PROXY que tiene el siguiente formato:

PROXY UNKNOWN\r\n

Actualiza el encabezado del protocolo PROXY para el proxy TCP de destino

En el ejemplo de configuración del balanceador de cargas de esta página, se muestra cómo habilitar el encabezado del protocolo PROXY mientras se crea el balanceador de cargas de red del proxy interno. Sigue estos pasos a fin de cambiar el encabezado del protocolo PROXY para un proxy TCP de destino existente.

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 Editar para tu balanceador de cargas.

  3. Haz clic en Configuración de frontend.

  4. Cambia el valor del campo del Protocolo Proxy a Activado.

  5. Haz clic en Actualizar para guardar los cambios.

gcloud

En el siguiente comando, edita el campo --proxy-header y configúralo como NONE o PROXY_V1 según tu requisito.

gcloud compute target-ssl-proxies update int-tcp-target-proxy \
    --proxy-header=[NONE | PROXY_V1]

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

Habilita la afinidad de sesión

En la configuración de ejemplo, se crea un servicio de backend sin afinidad de sesión.

En estos procedimientos, se muestran cómo actualizar un servicio de backend para un balanceador de cargas de ejemplo a fin de que el servicio de backend use la afinidad de IP de cliente o la afinidad de cookie generada.

Cuando la afinidad de IP de cliente está habilitada, el balanceador de cargas dirige las solicitudes de un cliente en particular a la misma VM de backend según el hash que se generó en la dirección IP del cliente y la dirección IP del balanceador de cargas (la dirección IP interna de una regla de reenvío interna).

Console

Para habilitar la afinidad de sesión de IP de cliente, sigue estos pasos:

  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 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 IP de cliente en el menú.
  6. Haz clic en Actualizar.

gcloud

Usa el siguiente comando de gcloud a fin de actualizar el servicio de backend BACKEND_SERVICE; para ello, especifica la afinidad de sesión de IP de cliente:

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --session-affinity=CLIENT_IP

Habilita el vaciado de conexiones

Puedes habilitar el desvío de conexiones en servicios de backend a fin de garantizar una interrupción mínima para tus usuarios cuando se finaliza una instancia que entrega tráfico, se quita de forma manual o la quita un escalador automático. Para obtener más información sobre el vaciado de conexiones, consulta la documentación Habilita el vaciado de conexiones.

¿Qué sigue?