Configura el balanceo de cargas de HTTP(S) interno

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

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

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

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

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

Permisos

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

Tarea Función requerida
Crear redes, subredes y componentes del balanceador de cargas Administrador de redes
Agregar y quitar reglas de firewall Administrador de seguridad
Crea instancias Administrador de instancias

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

Descripción general de la configuración

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

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

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

En el diagrama se muestra lo siguiente:

  1. Una red de VPC con dos subredes:

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

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

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

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

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

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

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

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

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

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

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

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

Configura la red y las subredes

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

En este ejemplo, se usan las siguientes redes de VPC, regiones y subredes:

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

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

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

Configura la red y la subred para los backends

Cloud Console

  1. Ve a la página Redes de VPC en Google Cloud Console.
    Ir a la página Redes de VPC
  2. Haz clic en Crear red de VPC.
  3. En Nombre, ingresa lb-network.
  4. En la sección Subredes, haz lo siguiente:
    • Establece Modo de creación de subred en Personalizado.
    • En la sección Nueva subred, ingresa la siguiente información:
      • Nombre: backend-subnet
      • Región:: us-west1
      • Rangos de direcciones IP: 10.1.2.0/24
    • Haz clic en Listo.
  5. Haz clic en Crear.

gcloud

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

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

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

API

Realiza una solicitud POST al método networks.insert y reemplaza project-id por el ID del proyecto.

POST https://www.googleapis.com/compute/v1/projects/project-id/global/networks

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

Realiza una solicitud POST al método subnetworks.insert y reemplaza project-id por el ID del proyecto.

POST https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks

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

Configura la subred de solo proxy

La subred de solo proxy es para todos los balanceadores de cargas de HTTP(S) internos en la región us-west1.

Cloud Console

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

gcloud

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

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

API

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

POST https://www.googleapis.com/compute/projects/project-id/regions/us-west1/subnetworks

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

Configura las reglas de firewall

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

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

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

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

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

Cloud Console

  1. Ve a la página Reglas de Firewall en Google Cloud Console.
    Ir a la página Reglas de firewall
  2. Haz clic en Crear regla de firewall para crear la regla que permite conexiones SSH entrantes:
    • Nombre: fw-allow-ssh
    • Red: lb-network
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de destino: allow-ssh
    • Filtro de fuente: IP ranges
    • Rangos de IP de origen: 0.0.0.0/0
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Marca tcp y escribe 22 para el número de puerto.
  3. Haz clic en Crear.
  4. Haz clic en Crear regla de firewall por segunda vez para crear la regla que permita las verificaciones de estado de Google Cloud:
    • Nombre: fw-allow-health-check
    • Red: lb-network
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de destino: load-balanced-backend
    • Filtro de fuente: IP ranges
    • Rangos de IP de origen: 130.211.0.0/22 y 35.191.0.0/16
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Marca tcp e ingresa 80.
        Como práctica recomendada, limita esta regla solo a los protocolos y puertos que coincidan con los que usa tu verificación de estado. Si usas tcp:80 en el protocolo y el puerto, Google Cloud puede usar HTTP en el puerto 80 a fin de contactar las VM, pero no puede usar HTTPS en el puerto 443 para comunicarse con ellas.
  5. Haz clic en Crear.
  6. Haz clic en Crear regla de firewall por tercera vez para crear la regla a fin de permitir que los servidores proxy del balanceador de cargas conecten los backends:
    • Nombre: fw-allow-proxies
    • Red: lb-network
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de destino: load-balanced-backend
    • Filtro de fuente: IP ranges
    • Rangos de IP de origen: 10.129.0.0/23
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Marca tcp y escribe 80, 443, 8080 para los números de puerto.
  7. Haz clic en Crear.

gcloud

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

    gcloud compute firewall-rules create fw-allow-ssh \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  2. Crea la regla fw-allow-health-check para permitir las verificaciones de estado de Google Cloud. Este ejemplo permite todo el tráfico de TCP proveniente de la verificación de estado. Sin embargo, puedes configurar un conjunto más limitado de puertos según tus necesidades.

    gcloud compute firewall-rules create fw-allow-health-check \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --target-tags=load-balanced-backend \
        --rules=tcp
    
  3. Crea la regla fw-allow-proxies para permitir que los proxies del balanceador de cargas de HTTP(S) interno se conecten con los backends.

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

API

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

POST https://www.googleapis.com/compute/v1/projects/project-id/global/firewalls

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

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

POST https://www.googleapis.com/compute/v1/projects/project-id/global/firewalls

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

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

POST https://www.googleapis.com/compute/v1/projects/{project}/global/firewalls

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

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

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

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

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

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 HTTP(S) interno de ejemplo. Las cargas del tráfico de los clientes se balancean a estos servidores de backend. A modo de demostración, los backends entregan sus propios nombres de host.

Cloud Console

  1. En Cloud Console, ve a la página Grupos de instancias.

    Ir a la página Grupos de instancias

  2. Haz clic en Crear grupo de instancias.
  3. Selecciona Nuevo grupo de instancias administrado a la izquierda.
  4. En Nombre, ingresa l7-ilb-backend-example.
  5. En Ubicación, selecciona Zona única.
  6. En Región, selecciona us-west1.
  7. En Zona, selecciona us-west1-a.
  8. En Plantilla de instancias, selecciona Crear una nueva plantilla de instancias.

    1. En Nombre, ingresa l7-ilb-backend-template.
    2. Asegúrate de que el disco de arranque esté configurado en una imagen de Debian, como Debian GNU/Linux 9 (stretch). En estas instrucciones, se usan comandos que solo están disponibles en Debian, como apt-get.
    3. En Administración, seguridad, discos, redes, usuario único, en la pestaña Administración, inserta 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'
      
    4. En Herramientas de redes, selecciona lb-network como la Red y, para la Subred, selecciona backend-subnet.

    5. Agrega las siguientes etiquetas de red: allow-ssh y load-balanced-backend.

    6. Haz clic en Guardar y continuar.

  9. Especifica la cantidad de instancias que deseas crear en el grupo.

    Para este ejemplo, en Modo de ajuste de escala automático, puedes seleccionar las siguientes opciones:

    • No configurar el ajuste de escala automático
    • En Cantidad 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.

  10. Haz clic en Crear para crear el grupo de instancias nuevo.

gcloud

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

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

    gcloud compute instance-templates create l7-ilb-backend-template \
    --region=us-west1 \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-9 \
    --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 l7-ilb-backend-example \
        --zone=us-west1-a \
        --size=2 \
        --template=l7-ilb-backend-template
    

API

Crea la plantilla de instancias con el método instanceTemplates.insert y reemplaza [project-id] por el ID de tu proyecto.

POST https://www.googleapis.com/compute/v1/projects/[project-id]/global/instanceTemplates
{
  "name":"l7-ilb-backend-template",
  "properties":{
     "machineType":"n1-standard-1",
     "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\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\necho \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
           "network":"projects/[project-id]/global/networks/lb-network",
           "subnetwork":"regions/us-west1/subnetworks/backend-subnet",
           "accessConfigs":[
             {
                 "type":"ONE_TO_ONE_NAT"
             }
           ]
       }
     ],
     "disks":[
       {
           "index":0,
           "boot":true,
           "initializeParams":{
              "sourceImage":"projects/debian-cloud/global/images/family/debian-9"
           },
           "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://www.googleapis.com/compute/v1/projects/[project-id]/zones/{zone}/instanceGroupManagers
{
  "name": "l7-ilb-backend-example",
  "zone": "projects/[project-id]/zones/us-west1-a",
  "instanceTemplate": "projects/[project-id]/global/instanceTemplates/l7-ilb-backend-template",
  "baseInstanceName": "l7-ilb-backend-example",
  "targetSize": 2
}

Configura el balanceador de cargas

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

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

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

Disponibilidad del proxy

En ocasiones, las regiones de Google Cloud no tienen suficiente capacidad de proxy para un nuevo balanceador de cargas de HTTP(S) interno. Si esto sucede, Cloud Console 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.

Cloud Console

Selecciona un tipo de balanceador de cargas

  1. Ve a la página Balanceo de cargas en Google Cloud Console.
    Ir a la página Balanceo de cargas
  2. En Balanceo de cargas de HTTP(S), haz clic en Iniciar configuración.
  3. Selecciona Solo entre mis VM. Esta configuración indica que el balanceador de cargas es interno.
  4. Haz clic en Continuar.

Prepara el balanceador de cargas

  1. Para el Nombre del balanceador de cargas, ingresa l7-ilb-map.
  2. En Región, selecciona us-west1.
  3. En Red, selecciona lb-network.
  4. Mantén la ventana abierta para continuar.

Reserva una subred de solo proxy

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

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

Configura el servicio de backend

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

Configura el mapa de URL

Haz clic en Reglas de host y ruta de acceso. Asegúrate de que l7-ilb-backend-service sea el único servicio de backend para cualquier host y ruta de acceso no coincidentes.

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

Configura el frontend

Para HTTP:

  1. Haz clic en Configuración de frontend.
  2. Haz clic en Agregar IP y puerto de frontend.
  3. Configura el Nombre como l7-ilb-forwarding-rule.
  4. Establece el Protocolo en HTTP.
  5. Establece la Subred en backend-subnet.
  6. En IP interna, selecciona Reserva una nueva dirección IP interna estática.
  7. En el panel que aparece, proporciona los siguientes detalles:
    1. Nombre: l7-ilb-ip
    2. En la sección Dirección IP estática, selecciona Permitirme elegir.
    3. En la sección Dirección IP personalizada, ingresa 10.1.2.99.
    4. Haz clic en Reservar.
  8. Establece el Puerto en 80.
  9. 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 obtener información sobre cómo crear recursos de certificados SSL, consulta Certificados SSL. Por el momento, los certificados administrados por Google no son compatibles con los balanceadores de cargas de HTTP(S) internos.

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

Completa la configuración

Haz clic en Crear.

gcloud

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

    gcloud compute health-checks create http l7-ilb-basic-check \
       --region=us-west1 \
       --use-serving-port
    
  2. Define el servicio de backend con el comando gcloud compute backend-services create.

    gcloud compute backend-services create l7-ilb-backend-service \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=HTTP \
      --health-checks=l7-ilb-basic-check \
      --health-checks-region=us-west1 \
      --region=us-west1
    
  3. Agrega backends al servicio de backend con el comando gcloud compute backend-services add-backend.

    gcloud compute backend-services add-backend l7-ilb-backend-service \
      --balancing-mode=UTILIZATION \
      --instance-group=l7-ilb-backend-example \
      --instance-group-zone=us-west1-a \
      --region=us-west1
    
  4. Crea el mapa de URL con el comando gcloud compute url-maps create.

    gcloud compute url-maps create l7-ilb-map \
      --default-service=l7-ilb-backend-service \
      --region=us-west1
    
  5. Crea el proxy de destino.

    Para HTTP:

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

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

    Para HTTPS:

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

    Asigna tus rutas de archivos a nombres de variables.

    export LB_CERT=path to PEM-formatted file
    
    export LB_PRIVATE_KEY=path to PEM-formatted file
    

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

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

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

    gcloud compute target-https-proxies create l7-ilb-proxy \
      --url-map=l7-ilb-map \
      --region=us-west1 \
      --ssl-certificates=l7-ilb-cert
    
  6. Crea la regla de reenvío.

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

    Para HTTP:

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

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

    Para HTTPS:

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

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

API

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

POST https://compute.googleapis.com/compute/v1/projects/[project-id]/regions/{region}/healthChecks
{
  "name": "l7-ilb-basic-check",
  "type": "HTTP",
  "httpHealthCheck": {
    "portSpecification": "USE_SERVING_PORT"
  }
}

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

POST https://www.googleapis.com/compute/v1/projects/[project-id]/regions/us-west1/backendServices
{
  "name": "l7-ilb-backend-service",
  "backends": [
    {
      "group": "projects/[project-id]/zones/us-west1-a/instanceGroups/l7-ilb-backend-example",
      "balancingMode": "UTILIZATION"
    }
  ],
  "healthChecks": [
    "projects/[project-id]/regions/us-west1/healthChecks/l7-ilb-basic-check"
  ],
  "loadBalancingScheme": "INTERNAL_MANAGED"
}

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

POST https://compute.googleapis.com/compute/v1/projects/[project-id]/regions/us-west1/urlMaps
{
  "name": "l7-ilb-map",
  "defaultService": "projects/[project-id]/regions/us-west1/backendServices/l7-ilb-backend-service"
}

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

POST https://www.googleapis.com/compute/v1/projects/[project-id]/regions/us-west1/targetHttpProxy
{
  "name": "l7-ilb-proxy",
  "urlMap": "projects/[project-id]/global/urlMaps/l7-ilb-map",
  "region": "us-west1"
}

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

POST https://www.googleapis.com/compute/v1/projects/[project-id]/regions/us-west1/forwardingRules
{
  "name": "l7-ilb-forwarding-rule",
  "IPAddress": "10.1.2.99",
  "IPProtocol": "TCP",
  "portRange": "80-80",
  "target": "projects/[project-id]/regions/us-west1/targetHttpProxies/l7-ilb-proxy",
  "loadBalancingScheme": "INTERNAL_MANAGED",
  "subnetwork": "projects/[project-id]/regions/us-west1/subnetworks/backend-subnet",
  "network": "projects/[project-id]/global/networks/lb-network",
  "networkTier": "PREMIUM",
}

Realiza pruebas

Crea una instancia de VM para probar la conectividad

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

Prueba el balanceador de cargas

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

Conecta mediante SSH a cada instancia de cliente

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

Verifica que la IP entregue su nombre de host

curl 10.1.2.99

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

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

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

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

Para HTTP:

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

Para HTTPS:

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

Opciones de configuración adicionales

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

Habilita la afinidad de sesión

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

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

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

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

Cloud Console

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

  1. Ve a la página Balanceo de cargas en Google Cloud Console.
    Ir a la página Balanceo de cargas
  2. Haz clic en Backends.
  3. Haz clic en l7-ilb-backend-service (el nombre del servicio de backend que creaste para este ejemplo) y haz clic en Editar.
  4. En la página Detalles del servicio de backend, haz clic en Configuración avanzada.
  5. En Afinidad de sesión, selecciona el tipo de afinidad de sesión que desees del menú.
  6. Haz clic en Actualizar.

gcloud

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

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

API

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

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

Próximos pasos