Configurar um balanceador de carga de aplicativo externo regional com back-ends de grupos de instâncias de VM

Neste documento, você aprenderá a configurar um balanceador de carga de aplicativo regional para seus serviços executados em VMs do Compute Engine.

Para configurar o balanceamento de carga para seus serviços em execução nos pods do Google Kubernetes Engine (GKE), consulteBalanceamento de carga nativo de contêiner com NEGs independentes e oComo anexar um balanceador de carga de aplicativo interno regional a NEGs independentes.

Para configurar o balanceamento de carga para acessar APIs e seviços do Google usando o Private Service Connect, consulte Como configurar o Private Service Connect com controles de serviço HTTP(S) do consumidor.

A configuração dos balanceadores de carga internos do aplicativo tem duas partes:

  • Realizar tarefas de pré-requisito, como garantir que as contas necessárias tenham as permissões corretas e preparar a rede de Nuvem Privada Virtual (VPC).
  • Configure os recursos do balanceador de carga.

Antes de seguir as instruções deste guia, familiarize-se com os itens abaixo:

Permissões

Para seguir as instruções deste guia, você precisa ser capaz de criar instâncias e modificar uma rede em um projeto. É necessário ser um proprietário ou editor de projeto, ou ter todos os seguintes papéis do IAM do Compute Engine:

Tarefa Papel necessário
Criar redes, sub-redes e componentes do balanceador de carga Administrador de rede do Compute
Adicionar e remover regras de firewall Administrador de segurança do Compute
Criar instâncias Administrador da instância da computação

Para mais informações, consulte estes guias:

Visão geral da configuração

É possível configurar um balanceador de carga de aplicativo interno, conforme descrito no fluxo de configuração de alto nível a seguir. As etapas numeradas se referem aos números no diagrama.

Componentes numerados do balanceador de carga de aplicativo interno.
Componentes numerados do balanceador de carga interno do aplicativo (clique para ampliar)

Conforme mostrado no diagrama, este exemplo cria um balanceador de carga de aplicativo interno em uma rede VPC na região us-west1, com um serviço de back-end e dois grupos de back-end.

O diagrama mostra estes elementos:

  1. Uma rede VPC com duas sub-redes:

    1. Uma sub-rede é usada para back-ends (grupos de instâncias) e regra de encaminhamento. O intervalo de endereços IP principal é 10.1.2.0/24.

    2. Uma sub-rede é uma sub-rede somente proxy na região us-west1. É preciso criar uma sub-rede somente proxy em cada região de uma rede VPC em que você usa balanceadores de carga de aplicativo. A sub-rede apenas de proxy da região é compartilhada com todos os balanceadores de carga de aplicativo internos na região. Os endereços de origem dos pacotes enviados do balanceador de carga de aplicativo interno para os back-ends do seu serviço são alocados da sub-rede somente proxy. Neste exemplo, a sub-rede somente proxy da região tem um intervalo de endereços IP primário de 10.129.0.0/23, que é o tamanho de sub-rede recomendado. Para mais informações, consulte Sub-redes somente proxy.

  2. Uma regra de firewall que permite o fluxo de sub-rede somente proxy na rede. Isso significa adicionar uma regra que permita o tráfego das portas TCP 80, 443 e 8080 de 10.129.0.0/23 (o intervalo da sub-rede somente proxy neste exemplo). Outra regra de firewall para as sondagens de verificação de integridade.

  3. Instâncias de VM do Compute Engine de backend.

  4. Grupos de instâncias gerenciadas ou não gerenciadas para implantações de VMs do Compute Engine.

    Em cada zona, é possível ter uma combinação de tipos de grupos de back-end com base nos requisitos da implantação.

  5. Uma verificação de integridade regional que informa a prontidão dos back-ends.

  6. Um serviço de back-end regional que monitora o uso e a integridade dos back-ends.

  7. Um mapa de URL regional que analisa o URL de uma solicitação e encaminha solicitações a serviços de back-end específicos com base no host e no caminho do URL de solicitação.

  8. Um proxy HTTP ou HTTPS de destino regional, que recebe uma solicitação do usuário e a encaminha ao mapa de URL. Em HTTPS, configure um recurso de certificado regional de SSL. O proxy de destino usa o certificado SSL para descriptografar o tráfego SSL se você configurar o balanceamento de carga HTTPS. O proxy de destino pode encaminhar o tráfego para suas instâncias usando HTTP ou HTTPS.

  9. Uma regra de encaminhamento, que tem o endereço IP interno do seu balanceador de carga, para encaminhar cada solicitação recebida ao proxy de destino.

    O endereço IP interno associado à regra de encaminhamento pode vir de qualquer sub-rede na mesma rede e região. Observe as seguintes condições:

    • O endereço IP pode (mas não precisa) vir da mesma sub-rede que os grupos de instâncias de back-end.
    • O endereço IP não pode vir de uma sub-rede exclusiva de proxy reservada que tenha a sinalização --purpose definida como REGIONAL_MANAGED_PROXY.
    • Se você quiser compartilhar o endereço IP interno com várias regras de encaminhamento, defina a sinalização --purpose do endereço IP como SHARED_LOADBALANCER_VIP.

    No exemplo desta página, é usado um endereço IP interno reservado para a regra de encaminhamento do balanceador de carga interno regional, em vez de um endereço IP interno temporário ser alocado. Como prática recomendada, reserve endereços IP para regras de encaminhamento.

Configurar a rede e as sub-redes

Você precisa de uma rede VPC com duas sub-redes: uma para os back-ends do balanceador de carga e a outra para os proxies do balanceador de carga. Um balanceador de carga de aplicativo interno é regional. O tráfego na rede VPC será direcionado ao balanceador de carga se a origem do tráfego estiver em uma sub-rede na mesma região que o balanceador de carga.

Neste exemplo, usamos a seguinte rede VPC, região e sub-redes:

  • Rede: uma rede VPC de modo personalizado chamada lb-network.

  • Sub-rede para back-ends: uma sub-rede chamada backend-subnet na região us-west1 usa 10.1.2.0/24 como o intervalo de IP primário.

  • Sub-rede para proxies: uma sub-rede chamada proxy-only-subnet na região us-west1 usa 10.129.0.0/23 como o intervalo de IP primário.

Para demonstrar o acesso global, este exemplo também cria uma segunda VM de cliente de teste em uma região e uma sub-rede diferentes:

  • Região: europe-west1
  • Sub-rede: europe-subnet, com intervalo de endereços IP principal 10.3.4.0/24

Configurar a rede e as sub-redes

Console

  1. No Console do Google Cloud, acesse a página Redes VPC.

    Acessar redes VPC

  2. Clique em Criar rede VPC.

  3. Em Nome, insira lb-network.

  4. Na seção Sub-redes, defina o Modo de criação da sub-rede como Personalizado.

  5. Crie uma sub-rede para os back-ends do balanceador de carga. Na seção Nova sub-rede, insira as informações a seguir:

    • Name: backend-subnet
    • Região: us-west1
    • Intervalo de endereços IP: 10.1.2.0/24
  6. Clique em Concluído.

  7. Clique em Add subnet.

  8. Crie uma sub-rede para demonstrar o acesso global. Na seção Nova sub-rede, insira as informações a seguir:

    • Name: europe-subnet
    • Região: europe-west1
    • Intervalo de endereços IP: 10.3.4.0/24
  9. Clique em Concluído.

  10. Clique em Criar.

gcloud

  1. Crie a rede VPC personalizada com o comando gcloud compute networks create:

    gcloud compute networks create lb-network --subnet-mode=custom
    
  2. Crie uma sub-rede na rede lb-network na região us-west1 com o comando gcloud compute networks subnets create:

    gcloud compute networks subnets create backend-subnet \
        --network=lb-network \
        --range=10.1.2.0/24 \
        --region=us-west1
    
  3. Crie uma sub-rede na rede lb-network na região europe-west1 com o comando gcloud compute networks subnets create:

    gcloud compute networks subnets create europe-subnet \
        --network=lb-network \
        --range=10.3.4.0/24 \
        --region=europe-west1
    

API

Faça uma solicitação POST ao método networks.insert. Substitua PROJECT_ID pelo ID do projeto.

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

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

Faça uma solicitação POST ao método subnetworks.insert. Substitua PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks

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

Faça uma solicitação POST ao método subnetworks.insert. Substitua PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/europe-west1/subnetworks

{
 "name": "europe-subnet",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "ipCidrRange": "10.3.4.0/24",
 "region": "projects/PROJECT_ID/regions/europe-west1",
}

Configurar a sub-rede somente proxy

Essa sub-rede somente proxy é destinada a todos os balanceadores de carga regionais baseados em Envoy na região us-west1 do lb-network.

Console

Se você estiver usando o Console do Google Cloud, poderá esperar e criar a sub-rede somente proxy depois na página Balanceamento de carga.

Se você quiser criar a sub-rede somente proxy agora, siga estas etapas:

  1. No Console do Google Cloud, acesse a página Redes VPC.

    Acessar redes VPC

  2. Clique no nome da rede VPC: lb-network.

  3. Clique em Add subnet.

  4. Em Nome, insira proxy-only-subnet.

  5. Em Região, selecione us-west1.

  6. Defina Finalidade como Proxy gerenciado regional.

  7. Em Intervalo de endereços IP, insira 10.129.0.0/23.

  8. Clique em Adicionar.

gcloud

Crie a sub-rede somente proxy com o comando gcloud compute networks subnets create.

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

API

Crie a sub-rede somente proxy com o método subnetworks.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/us-west1/subnetworks

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

Configurar regras de firewall

Este exemplo usa as seguintes regras de firewall:

  • fw-allow-ssh: uma regra de entrada, aplicável às instâncias cuja carga está sendo balanceada, que permite a conectividade SSH de entrada na porta TCP 22 proveniente de qualquer endereço. Escolha um intervalo de IP de origem mais restritivo para esta regra. Por exemplo, é possível especificar apenas os intervalos de IP do sistema do qual você inicia sessões SSH. Neste exemplo, usamos a tag de destino allow-ssh para identificar as VMs a que a regra de firewall se aplica.

  • fw-allow-health-check. Uma regra de entrada, aplicável às instâncias cuja carga está sendo balanceada, que permite todo o tráfego TCP dos sistemas de verificação de integridade do Google Cloud (em 130.211.0.0/22 e 35.191.0.0/16). Este exemplo usa a tag de destino load-balanced-backend para identificar as VMs a que a regra de firewall se aplica.

  • fw-allow-proxies. Uma regra de entrada, aplicável às instâncias submetidas a balanceamento de carga, que permite o tráfego TCP nas portas 80, 443 e 8080 dos proxies gerenciados do balanceador de carga de aplicativo interno. Neste exemplo, usamos a tag de destino load-balanced-backend para identificar as VMs a que a regra de firewall se aplica.

Sem essas regras de firewall, a regra padrão de negação de entrada bloqueará o tráfego que chega para as instâncias de back-end.

As tags de destino definem as instâncias de back-end. Sem as tags de destino, as regras de firewall se aplicam a todas as instâncias de back-end na rede VPC. Ao criar as VMs de back-end, inclua as tags de destino especificadas, conforme mostrado em Como criar um grupo gerenciado de instâncias.

Console

  1. No Console do Google Cloud, acesse a página políticas de Firewall.

    Acessar as políticas de firewall

  2. Clique em Criar regra de firewall para criar a regra que autorize conexões SSH de entrada:

    • Name: fw-allow-ssh
    • Rede: lb-network
    • Direção do tráfego: entrada
    • Ação na correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de meta: allow-ssh
    • Filtro de origem: intervalos IPv4
    • Intervalos IPv4 de origem: 0.0.0.0/0
    • Protocolos e portas:
      • Escolha Protocolos e portas especificados.
      • Marque a caixa de seleção tcp e insira 22 como o número da porta.
  3. Clique em Criar.

  4. Clique em Criar regra de firewall pela segunda vez para criar a regra que autorize as verificações de integridade do Google Cloud:

    • Name: fw-allow-health-check
    • Rede: lb-network
    • Direção do tráfego: entrada
    • Ação na correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de meta: load-balanced-backend
    • Filtro de origem: intervalos IPv4
    • Intervalos IPv4 de origem: 130.211.0.0/22 e 35.191.0.0/16
    • Protocolos e portas:
      • Escolha Protocolos e portas especificados.
      • Marque a caixa de seleção tcp e insira 80 como o número da porta.
        Como prática recomendada, limite esta regra somente aos protocolos e portas que correspondem aos usados por sua verificação de integridade. Se você usar tcp:80 para o protocolo e a porta, o Google Cloud poderá usar HTTP na porta 80 para entrar em contato com suas VMs, mas não poderá usar HTTPS na porta 443 para entrar em contato com elas.
  5. Clique em Criar.

  6. Clique em Criar regra de firewall uma terceira vez para criar a regra que permite que os servidores proxy do balanceador de carga se conectem aos back-ends:

    • Name: fw-allow-proxies
    • Rede: lb-network
    • Direção do tráfego: entrada
    • Ação na correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de meta: load-balanced-backend
    • Filtro de origem: intervalos IPv4
    • Intervalos IPv4 de origem: 10.129.0.0/23
    • Protocolos e portas:
      • Escolha Protocolos e portas especificados.
      • Marque a caixa de seleção tcp e insira 80, 443, 8080 como os números da porta.
  7. Clique em Criar.

gcloud

  1. Crie a regra de firewall fw-allow-ssh que permita a conectividade SSH para VMs com a tag de rede allow-ssh. Se você omitir source-ranges, o Google Cloud interpretará que a regra autoriza a conexão proveniente de qualquer origem.

    gcloud compute firewall-rules create fw-allow-ssh \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  2. Crie a regra fw-allow-health-check para permitir verificações de integridade do Google Cloud. Neste exemplo, é permitido todo o tráfego TCP de sondagens de verificação de integridade. No entanto, é possível configurar um conjunto mais restrito de portas para atender às suas necessidades.

    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. Crie a regra fw-allow-proxies para permitir que os proxies do balanceador de carga interno se conectem aos seus back-ends. Defina source-ranges para os intervalos alocados da sub-rede somente proxy, por exemplo, 10.129.0.0/23.

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

API

Crie a regra de firewall fw-allow-ssh fazendo uma solicitação POST ao método firewalls.insert, substituindo PROJECT_ID pelo ID do projeto.

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

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

Crie a regra de firewall fw-allow-health-check fazendo uma solicitação POST ao método firewalls.insert, substituindo PROJECT_ID pelo ID do projeto.

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

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

Crie a regra de firewall fw-allow-proxies para permitir o tráfego TCP na sub-rede proxy para o método firewalls.insert, substituindo PROJECT_ID pelo ID do projeto.

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

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

Reserve o endereço IP do balanceador de carga

Por padrão, um endereço IP é usado para cada regra de encaminhamento. É possível reservar um endereço IP compartilhado para usar o mesmo endereço IP com várias regras de encaminhamento. No entanto, se você quiser publicar o balanceador de carga usando o Private Service Connect, não use um endereço IP compartilhado para a regra de encaminhamento.

Como endereço IP da regra de encaminhamento, use o backend-subnet. Se você tentar usar a sub-rede somente proxy, a criação da regra de encaminhamento falhará.

Console

É possível reservar um endereço IP interno independente usando o Console do Google Cloud.

  1. Acesse a página Redes VPC.

    Acessar redes VPC

  2. Clique na rede usada para configurar a conectividade híbrida entre os ambientes.
  3. Clique em Endereços IP internos estáticos e em Reservar endereço estático.
  4. Em Nome, insira l7-ilb-ip-address.
  5. Em Sub-rede, selecione backend-subnet.
  6. Se quiser especificar o endereço IP a ser reservado, em Endereço IP estático , selecioneDeixe-me escolher e preencha com um Endereço IP personalizado. Caso contrário, o sistema atribui automaticamente um endereço IP na sub-rede para você.
  7. Se você quiser usar esse endereço IP com várias regras de encaminhamento, em Objetivo, escolha Compartilhado.
  8. Clique em Reservar para concluir o processo.

gcloud

  1. Usando a CLI gcloud, execute o comando compute addresses create:

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

    Se você quiser usar o mesmo endereço IP com várias regras de encaminhamento, especifique --purpose=SHARED_LOADBALANCER_VIP.

  2. Use o comando compute addresses describe para ver o endereço IP alocado:

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

Criar um back-end de grupo gerenciado de instâncias de VM

Nesta seção, mostramos como criar um modelo de grupo de instância e um grupo de instâncias gerenciadas. O grupo gerenciado de instâncias fornece instâncias de VM que executam os servidores de back-end de um exemplo de balanceador de carga de aplicativo interno regional. Para o grupo de instâncias, é possível definir um serviço HTTP e mapear um nome de porta para a porta relevante. O serviço de back-end do balanceador de carga encaminha o tráfego para as portas nomeadas. É feito o balanceamento de carga do tráfego dos clientes para os servidores de back-end. Para fins de demonstração, os back-ends veiculam nomes de host próprios.

Console

  1. Criar um modelo de instância. No console do Google Cloud, acesse a página Modelos de instância.

    Acessar "Modelos de instância"

    1. Clique em Criar modelo de instância.
    2. Em Nome, insira l7-ilb-backend-template.
    3. Verifique se Disco de inicialização está definido como uma imagem Debian, como Debian GNU/Linux 12 (bookworm): Estas instruções usam comandos que estão disponíveis apenas no Debian, como apt-get.
    4. Clique em Opções avançadas.
    5. Clique em Rede e configure os seguintes campos:
      1. Em Tags de rede, insira allow-ssh e load-balanced-backend.
      2. Em Interfaces de rede, selecione o seguinte:
        • Rede: lb-network
        • Sub-rede: backend-subnet
    6. Clique em Gerenciamento. Insira o script a seguir no campo Script de inicialização.

      #! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://metadata.google.internal/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2
      
    7. Clique em Criar.

  2. Crie um grupo de instâncias gerenciadas. No console do Google Cloud, acesse a página Grupos de instâncias.

    Acesse grupo de instâncias

    1. Clique em Criar grupo de instâncias.
    2. Selecione Novo grupo gerenciado de instâncias (sem estado). Para mais informações, consulte MIGs sem estado ou com estado.
    3. Em Nome, insira l7-ilb-backend-example.
    4. Em Local, selecione Zona única.
    5. Em Região, selecione us-west1.
    6. Em Zona, selecione us-west1-a.
    7. Em Modelo de instância, selecione l7-ilb-backend-template.
    8. Especifique o número de instâncias que você quer criar no grupo.

      Neste exemplo, especifique as seguintes opções em Escalonamento automático:

      • Em Modo de escalonamento automático, selecione Off:do not autoscale.
      • Em Número máximo de instâncias, insira 2.

      Se preferir, na seção Escalonamento automático da IU, configure o grupo de instâncias para adicionar ou remover instâncias automaticamente com base no uso de CPU da instância.

    9. Clique em Criar.

gcloud

As instruções gcloud deste guia pressupõem que você está usando o Cloud Shell ou outro ambiente com o bash instalado.

  1. Crie um modelo de instância de VM com o servidor HTTP usando o comando gcloud compute instance-templates create.

    gcloud compute instance-templates create l7-ilb-backend-template \
    --region=us-west1 \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --metadata=startup-script='#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://metadata.google.internal/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2'
    
  2. Crie um grupo de instâncias gerenciadas na zona com o 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

Crie o modelo de instância com o método instanceTemplates.insert, substituindo PROJECT_ID pelo ID do projeto.


POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates
{
  "name":"l7-ilb-backend-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
            \\\nhttp://metadata.google.internal/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/lb-network",
         "subnetwork":"regions/us-west1/subnetworks/backend-subnet",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}

Crie um grupo de instâncias gerenciadas em cada zona com o método instanceGroupManagers.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers
{
  "name": "l7-ilb-backend-example",
  "zone": "projects/PROJECT_ID/zones/us-west1-a",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/l7-ilb-backend-template",
  "baseInstanceName": "l7-ilb-backend-example",
  "targetSize": 2
}

Configurar o balanceador de carga

Neste exemplo, mostramos como criar os seguintes recursos internos do balanceador de carga de aplicativo interno regional:

  • Verificação de integridade de HTTP
  • Serviço de back-end com um grupo de instâncias gerenciadas como o back-end
  • Um mapa de URL
    • Certifique-se de consultar um mapa regional de URL se uma região for definida para o proxy HTTP(S) de destino. Um mapa regional de URL direciona as solicitações para um serviço de back-end regional com base em regras definidas para o host e caminho de um URL recebido. Esse tipo de mapa pode ser referenciado por uma regra de proxy de destino regional somente na mesma região.
  • Certificado SSL (para HTTPS)
  • Proxy de destino
  • Regra de encaminhamento

Disponibilidade de proxy

Às vezes, as regiões do Google Cloud não têm capacidade de proxy suficiente para um novo balanceador de carga. Se isso acontecer, o console do Google Cloud fornecerá uma mensagem de aviso sobre a disponibilidade de proxy quando você criar o balanceador de carga. Para resolver esse problema, siga um destes procedimentos:

  • Selecione uma região diferente para seu balanceador de carga. Essa opção pode ser prática se você tiver back-ends em outra região.
  • Selecione uma rede VPC que já tenha uma sub-rede somente proxy alocada.
  • Aguarde o problema de capacidade ser resolvido.

Console

Iniciar a configuração

  1. No console do Google Cloud, acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Clique em Criar balanceador de carga.
  3. Em Tipo de balanceador de carga, selecione Balanceador de carga de aplicativo (HTTP/HTTPS) e clique em Próxima.
  4. Em Voltado ao público ou interno, selecione Interno e clique em Próxima.
  5. Em Implantação entre regiões ou região única, selecione Melhor para cargas de trabalho regionais e clique em Próxima.
  6. Clique em Configurar.

Configuração básica

  1. Em Nome do balanceador de carga, digite l7-ilb-map.
  2. Em Região, selecione us-west1.
  3. Em Rede, selecione lb-network.

Reservar uma sub-rede somente proxy

.

Reserve uma sub-rede somente proxy:

  1. Clique em Reservar uma sub-rede.
  2. Em Nome, insira proxy-only-subnet.
  3. Em Intervalo de endereços IP, insira 10.129.0.0/23.
  4. Clique em Adicionar.

Configurar o serviço de back-end

  1. Clique em Configuração do back-end.
  2. No menu Criar ou selecionar serviços de back-end, selecione Criar um serviço de back-end.
  3. Defina o Nome do serviço de back-end como l7-ilb-backend-service.
  4. Defina o Tipo de back-end como Grupo de instâncias.
  5. Na seção Novo back-end:
    1. Defina Grupo de instâncias como l7-ilb-backend-example.
    2. Defina Números de portas como 80.
    3. Defina Modo de balanceamento como Utilização.
    4. Clique em Concluído.
  6. Na lista Verificação de integridade, clique em Criar verificação de integridade com os seguintes parâmetros:
    1. Name: l7-ilb-basic-check
    2. Protocolo: HTTP
    3. Porta: 80
    4. Clique em Salvar.
  7. Clique em Criar.

Configurar o mapa de URL

  1. Clique em Regras de host e caminho.

  2. Em Modo, selecione Regra de host e caminho simples.

  3. Certifique-se de que l7-ilb-backend-service seja o único serviço de back-end para qualquer host e qualquer caminho sem correspondência.

Saiba mais sobre gerenciamento de tráfego em Como configurar o gerenciamento de tráfego.

Configurar o front-end

Para HTTP:

  1. Clique em Configuração de front-end.
  2. Defina o nome da regra de encaminhamento como l7-ilb-forwarding-rule.
  3. Defina o Protocolo como HTTP.
  4. Defina Sub-rede como backend-subnet.
  5. Defina a Porta como 80.
  6. Na lista Endereço IP, selecione l7-ilb-ip-address.
  7. Clique em Concluído.

Para HTTPS:

  1. Clique em Configuração de front-end.
  2. Defina o nome da regra de encaminhamento como l7-ilb-forwarding-rule.
  3. Defina o Protocolo como HTTPS (includes HTTP/2).
  4. Defina Sub-rede como backend-subnet.
  5. Certifique-se de que Porta esteja definida como 443, para permitir tráfego HTTPS.
  6. Na lista Endereço IP, selecione l7-ilb-ip-address.
  7. Clique na lista suspensa Certificado.
    1. Se você já tiver um recurso de certificado SSL autogerenciado que você quer usar como o certificado SSL principal, selecione-o na lista.
    2. Caso contrário, selecione Criar um novo certificado.
      1. Defina o nome do certificado como l7-ilb-cert.
      2. Nos campos apropriados, faça o upload dos arquivos formatados em PEM:
        • Certificado de chave pública
        • Cadeia de certificados
        • Chave privada
      3. Clique em Criar.
  8. Para adicionar recursos de certificado além do certificado SSL principal, siga estas etapas:
    1. Clique em Adicionar certificado.
    2. Selecione um certificado na lista Certificados ou clique em Criar um novo certificado e siga as instruções.
  9. Selecione uma política de SSL na lista Política de SSL. Se você não criou nenhuma política de SSL, uma política padrão de SSL do GCP será aplicada.
  10. Clique em Concluído.

Analise a configuração

  1. Clique em Analisar e finalizar.
  2. Revise suas configurações do balanceador de carga.
  3. Opcional: clique em Código equivalente para conferir a solicitação de API REST que será usada para criar o balanceador de carga.
  4. Clique em Criar.

gcloud

  1. Defina a verificação de integridade HTTP com o comando gcloud compute health-checks create http.

    gcloud compute health-checks create http l7-ilb-basic-check \
       --region=us-west1 \
       --use-serving-port
    
  2. Defina o serviço de back-end com o 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. Adicione back-ends ao serviço de back-end com o 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. Crie o mapa de URL com o comando gcloud compute url-maps create.

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

    Para HTTP:

    Para um balanceador de carga HTTP interno, crie o proxy de destino com o 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:

    É possível criar certificados do Compute Engine ou do Gerenciador de certificados. Use um dos métodos a seguir para criar certificados usando o Gerenciador de certificados:

    • Certificados regionais autogerenciados. Para informações sobre como criar e usar certificados autogerenciados regionais, consulte Implantar um certificado autogerenciado regional. Mapas de certificados não são compatíveis.

    • Certificados regionais gerenciados pelo Google. Mapas de certificados não são compatíveis.

      Os seguintes tipos de certificados regionais gerenciados pelo Google são aceitos pelo Gerenciador de certificados:

    • Depois de criar certificados, anexe o certificado diretamente ao proxy de destino.

      Atribua os caminhos de arquivo aos nomes de variáveis.

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

      Crie um certificado SSL regional usando o 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
      

      Use o certificado SSL regional para criar um proxy de destino com o 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
      
    • Crie a regra de encaminhamento.

      Para redes personalizadas, referencie a sub-rede na regra de encaminhamento. Observe que esta é a sub-rede da VM, não a do proxy.

      Para HTTP:

      Use o comando gcloud compute forwarding-rules create com as sinalizações corretas.

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

      Para HTTPS:

      Crie a regra de encaminhamento usando o comando gcloud compute forwarding-rules create com as sinalizações corretas.

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

API

Crie a verificação de integridade fazendo uma solicitação POST ao método regionHealthChecks.insert, substituindo PROJECT_ID pelo ID do projeto.

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"
}
}

Crie o serviço de back-end regional fazendo uma solicitação POST para o método regionBackendServices.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices

{
"name": "l7-ilb-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/us-west1-a/instanceGroups/l7-ilb-backend-example",
    "balancingMode": "UTILIZATION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/us-west1/healthChecks/l7-ilb-basic-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

Crie o mapa de URL fazendo uma solicitação POST ao método regionUrlMaps.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/urlMaps

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/regions/us-west1/backendServices/l7-ilb-backend-service"
}

Para HTTP:

Crie o proxy HTTP de destino fazendo uma solicitação POST ao método regionTargetHttpProxies.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/targetHttpProxy

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

Crie a regra de encaminhamento fazendo uma solicitação POST para o método forwardingRules.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
"name": "l7-ilb-forwarding-rule",
"IPAddress": "IP_ADDRESS",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/regions/us-west1/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/us-west1/subnetworks/backend-subnet",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"networkTier": "PREMIUM"
}

Para HTTPS:

É possível criar certificados do Compute Engine ou do Gerenciador de certificados. Use um dos métodos a seguir para criar certificados usando o Gerenciador de certificados:

  • Certificados regionais autogerenciados. Para informações sobre como criar e usar certificados autogerenciados regionais, consulte Implantar um certificado autogerenciado regional. Mapas de certificados não são compatíveis.

  • Certificados regionais gerenciados pelo Google. Mapas de certificados não são compatíveis.

    Os seguintes tipos de certificados regionais gerenciados pelo Google são aceitos pelo Gerenciador de certificados:

  • Depois de criar certificados, anexe o certificado diretamente ao proxy de destino.

    Leia os arquivos do certificado e da chave privada e crie o certificado SSL. O exemplo a seguir mostra como fazer isso com 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
    

    Crie o proxy HTTPS de destino fazendo uma solicitação POST ao método regionTargetHttpsProxies.insert, substituindo PROJECT_ID pelo ID do projeto.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/regionTargetHttpsProxy
    
    {
    "name": "l7-ilb-proxy",
    "urlMap": "projects/PROJECT_ID/regions/us-west1/urlMaps/l7-ilb-map",
    "sslCertificates": /projects/PROJECT_ID/regions/us-west1/sslCertificates/SSL_CERT_NAME
    }
    

    Crie a regra de encaminhamento fazendo uma solicitação POST para o método forwardingRules.insert, substituindo PROJECT_ID pelo ID do projeto.

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

Testar o balanceador de carga

Para testar o balanceador de carga, crie uma VM de cliente. Em seguida, estabeleça uma sessão SSH com a VM e envie o tráfego da VM para o balanceador de carga.

Criar uma instância de VM para testar a conectividade

Console

  1. No console do Google Cloud, acesse a página Instâncias de VMs.

    Acessar instâncias de VM

  2. Clique em Criar instância.

  3. Defina o Nome como l7-ilb-client-us-west1-a.

  4. Defina Zona como us-west1-a.

  5. Clique em Opções avançadas.

  6. Clique em Rede e configure os seguintes campos:

    1. Em Tags de rede, insira allow-ssh.
    2. Em Interfaces de rede, selecione o seguinte:
      1. Rede: lb-network
      2. Sub-rede: backend-subnet
  7. Clique em Criar.

gcloud

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

Enviar tráfego ao balanceador de carga

Faça login na instância recém-criada e teste se os serviços HTTP(S) nos back-ends estão acessíveis usando o endereço IP de regra de encaminhamento do balanceador de carga de aplicativo interno. Verifique também se está ocorrendo o balanceamento de carga do tráfego nas instâncias de back-end.

Conectar-se via SSH a cada instância do cliente

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

Anotar o endereço IP do balanceador de carga

Use o comando gcloud compute addresses describe para ver o endereço IP alocado:

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

Verifique se o endereço IP está exibindo o nome do host

Substitua IP_ADDRESS pelo endereço IP do balanceador de carga.

curl IP_ADDRESS

Para fazer teste em HTTPS, substitua curl por:

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

A sinalização -k faz com que o curl ignore a validação do certificado.

Executar 100 solicitações e confirmar o balanceamento de carga delas

Substitua IP_ADDRESS pelo endereço IP do balanceador de carga.

Para HTTP:

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

Para HTTPS:

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

Outras opções de configuração

Nesta seção, o exemplo é detalhado para fornecer outras opções de configuração. Todas as tarefas são opcionais. É possível realizá-las em qualquer ordem.

Ativar o acesso global

É possível ativar o acesso global para o balanceador de carga regional e de proxy interno regional para torná-los acessíveis a clientes em todas as regiões. Os back-ends do balanceador de carga de exemplo ainda precisam estar localizados em uma única região (us-west1).

Balanceador de carga de aplicativo interno regional com acesso global.
Balanceador de carga de aplicativo interno regional com acesso global (clique para ampliar).

Não é possível modificar uma regra de encaminhamento regional para permitir o acesso global. Você precisa criar uma nova regra de encaminhamento para essa finalidade e excluir a regra de encaminhamento anterior. Além disso, depois que uma regra de encaminhamento é criada com o acesso global ativado, ela não pode ser modificada. Para desativar o acesso global, crie uma nova regra de encaminhamento de acesso regional e exclua a anterior.

Para configurar o acesso global, faça as seguintes alterações de configuração.

Console

Crie uma regra de encaminhamento para o balanceador de carga:

  1. No Console do Google Cloud, acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Na coluna Nome, clique no seu balanceador de carga.

  3. Clique em Configuração de front-end.

  4. Clique em Adicionar IP e porta de front-end.

  5. Digite os detalhes do nome e da sub-rede da nova regra de encaminhamento.

  6. Em Sub-rede, selecione backend-subnet.

  7. Em Endereço IP, é possível selecionar o mesmo endereço IP como uma regra de encaminhamento atual, reservar um novo endereço IP ou usar um endereço IP efêmero. O compartilhamento do mesmo endereço IP em várias regras de encaminhamento só será possível se você definir a sinalização --purpose do endereço IP como SHARED_LOADBALANCER_VIP ao criar o endereço IP.

  8. Em Número da porta, digite 110.

  9. Em Acesso global, selecione Ativar.

  10. Clique em Concluído.

  11. Clique em Atualizar.

gcloud

  1. Crie uma nova regra de encaminhamento para o balanceador de carga com a sinalização --allow-global-access.

    Para HTTP:

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

    Para HTTPS:

    gcloud compute forwarding-rules create l7-ilb-forwarding-rule-global-access \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=lb-network \
      --subnet=backend-subnet \
      --address=10.1.2.99 \
      --ports=443 \
      --region=us-west1 \
      --target-https-proxy=l7-ilb-proxy \
      --target-https-proxy-region=us-west1 \
      --allow-global-access
    
  2. Use o comando gcloud compute forwarding-rules describe para determinar se uma regra de encaminhamento tem acesso global ativado. Exemplo:

    gcloud compute forwarding-rules describe l7-ilb-forwarding-rule-global-access \
      --region=us-west1 \
      --format="get(name,region,allowGlobalAccess)"
    

    Quando o acesso global está ativado, a palavra True aparece na saída após o nome e a região da regra de encaminhamento.

Criar uma VM cliente para testar o acesso global

Console

  1. No console do Google Cloud, acesse a página Instâncias de VMs.

    Acessar instâncias de VM

  2. Clique em Criar instância.

  3. Defina o Nome como europe-client-vm.

  4. Defina Zona como europe-west1-b.

  5. Clique em Opções avançadas.

  6. Clique em Rede e configure os seguintes campos:

    1. Em Tags de rede, insira allow-ssh.
    2. Em Interfaces de rede, selecione o seguinte:
      • Rede: lb-network
      • Sub-rede: europe-subnet
  7. Clique em Criar.

gcloud

Crie uma VM cliente na zona europe-west1-b.

gcloud compute instances create europe-client-vm \
    --zone=europe-west1-b \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=europe-subnet

Conectar-se ao cliente da VM e testar a conectividade

  1. Use ssh para se conectar à instância do cliente.

    gcloud compute ssh europe-client-vm \
        --zone=europe-west1-b
    
  2. Teste as conexões com o balanceador de carga, como você fez no vm-client da região us-west1.

    curl http://10.1.2.99
    

Ativar a afinidade de sessão

Estes procedimentos mostram como atualizar um serviço de back-end do balanceador de carga de aplicativo interno regional de exemplo ou do balanceador de carga de aplicativo interno multirregional para que o serviço de back-end usa afinidade de cookie gerado, afinidade de campo de cabeçalho ou afinidade de cookie HTTP.

Quando a afinidade de cookie gerado é ativada, o balanceador de carga emite um cookie na primeira solicitação. Para cada solicitação subsequente com o mesmo cookie, o balanceador de carga direciona a solicitação para a mesma instância de máquina virtual (VM, na sigla em inglês) de back-end ou endpoint. Neste exemplo, o cookie é chamado de GCILB.

Quando a afinidade de campo de cabeçalho é ativada, o balanceador de carga encaminha solicitações para VMs ou endpoints de back-end em um NEG com base no valor do cabeçalho HTTP nomeado na sinalização --custom-request-header. A afinidade de campo de cabeçalho só será válida se a política de localidade de balanceamento de carga for RING_HASH ou MAGLEV e o hash consistente do serviço de back-end especificar o nome do cabeçalho HTTP.

Quando a afinidade de cookie HTTP é ativada, o balanceador de carga encaminha solicitações para VMs ou endpoints de back-end em um NEG, com base em um cookie HTTP nomeado na sinalização HTTP_COOKIE com a sinalização opcional --affinity-cookie-ttl. Se o cliente não fornecer o cookie na solicitação HTTP, o proxy gerará o cookie e o retornará ao cliente em um cabeçalho Set-Cookie. A afinidade de cookie HTTP só será válida se a política de localidade de balanceamento de carga for RING_HASH ou MAGLEV e o hash consistente do serviço de back-end especificar o cookie HTTP.

Console

Para ativar ou alterar a afinidade de sessão para um serviço de back-end:

  1. No Console do Google Cloud, acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Clique em Back-ends.
  3. Clique em l7-ilb-backend-service (o nome do serviço de back-end criado para este exemplo) e clique em l7-ilb-backend-service.
  4. Na página Detalhes do serviço de back-end, clique em Configuração avançada.
  5. Em Afinidade da sessão, selecione o tipo de afinidade da sessão.
  6. Clique em Atualizar.

gcloud

Use os seguintes comandos da Google Cloud CLI para atualizar o serviço de back-end para diferentes tipos de afinidade de sessão:

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

API

Para definir a afinidade da sessão, faça uma solicitação "PATCH" para o método backendServices/patch.

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

Restringir quais clientes podem enviar tráfego ao balanceador de carga

Para impedir que os clientes se conectem a um VIP interno de regra de encaminhamento do balanceador de carga de aplicativo, configure regras de firewall de saída nesses clientes. Defina essas regras de firewall em VMs específicas de cliente com base em contas de serviço ou tags.

Não é possível usar regras de firewall para restringir o tráfego de entrada para VIPs específicos de regra de encaminhamento do balanceador de carga de aplicativo interno. Qualquer cliente na mesma rede VPC e na mesma região que o VIP de regra de encaminhamento geralmente envia tráfego para o VIP da regra de encaminhamento.

Além disso, todas as solicitações para back-ends vêm de proxies que usam endereços IP no intervalo de sub-rede somente proxy. Não é possível criar regras de firewall que permitam ou neguem o tráfego de entrada nesses back-ends com base na regra de encaminhamento VIP usada por um cliente.

Veja alguns exemplos de como usar regras de firewall de saída para restringir o tráfego ao VIP da regra de encaminhamento do balanceador de carga.

Console

Para identificar as VMs do cliente, marque as VMs específicas que você quer restringir. Essas tags são usadas para associar regras de firewall às VMs clientes marcadas. Em seguida, adicione a tag ao campo TARGET_TAG nas etapas a seguir.

Para configurar isso, use uma única regra de firewall ou várias regras.

Regra única de firewall de saída

É possível configurar uma regra de saída de firewall para negar todo o tráfego de saída proveniente de VMs cliente marcadas com tag para o VIP de um balanceador de carga.

  1. No Google Cloud Console, acesse a página Regras de firewall.

    Acessar as regras de firewall

  2. Clique em Criar regra de firewall para criar a regra que nega o tráfego de saída das VMs clientes marcadas com tag ao VIP de um balanceador de carga.

    • Name: fr-deny-access
    • Rede: lb-network
    • Prioridade: 100
    • Direção do tráfego: saída
    • Ação na correspondência: negar
    • Destinos: tags de destino especificadas
    • Tags de meta: TARGET_TAG
    • Filtro de destino: intervalos de IP
    • Intervalos de IP de destino: 10.1.2.99
    • Protocolos e portas:
      • Escolha Protocolos e portas especificados.
      • Marque a caixa de seleção tcp e insira 80 como o número da porta.
  3. Clique em Criar.

Várias regras de firewall de saída

Uma abordagem mais escalonável envolve a configuração de duas regras. Uma regra padrão de baixa prioridade que impeça todos os clientes de acessar o VIP do balanceador de carga. Uma segunda regra de prioridade mais alta que permita que um subconjunto de clientes marcados com tag acessem o VIP do balanceador de carga. Somente VMs com tags podem acessar o VIP.

  1. No Google Cloud Console, acesse a página Regras de firewall.

    Acessar as regras de firewall

  2. Clique em Criar regra de firewall para criar a regra de prioridade mais baixa que nega acesso por padrão:

    • Name: fr-deny-all-access-low-priority
    • Rede: lb-network
    • Prioridade: 200
    • Direção do tráfego: saída
    • Ação na correspondência: negar
    • Destinos: tags de destino especificadas
    • Tags de meta: TARGET_TAG
    • Filtro de destino: intervalos de IP
    • Intervalos de IP de destino: 10.1.2.99
    • Protocolos e portas:
      • Escolha Protocolos e portas especificados.
      • Marque a caixa de seleção tcp e insira 80 como o número da porta.
  3. Clique em Criar.

  4. Clique em Criar regra de firewall para criar a regra de prioridade mais alta que permita o tráfego de determinadas instâncias marcadas com tag.

    • Name: fr-allow-some-access-high-priority
    • Rede: lb-network
    • Prioridade: 100
    • Direção do tráfego: saída
    • Ação na correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de meta: TARGET_TAG
    • Filtro de destino: intervalos de IP
    • Intervalos de IP de destino: 10.1.2.99
    • Protocolos e portas:
      • Escolha Protocolos e portas especificados.
      • Marque a caixa de seleção tcp e insira 80 como o número da porta.
  5. Clique em Criar.

gcloud

Para identificar as VMs do cliente, marque as VMs específicas que você quer restringir. Em seguida, adicione a tag ao campo TARGET_TAG nestas etapas.

Para configurar isso, use uma única regra de firewall ou várias regras.

Regra única de firewall de saída

É possível configurar uma regra de saída de firewall para negar todo o tráfego de saída proveniente de VMs cliente marcadas com tag para o VIP de um balanceador de carga.

gcloud compute firewall-rules create fr-deny-access \
  --network=lb-network \
  --action=deny \
  --direction=egress \
  --rules=tcp \
  --priority=100 \
  --destination-ranges=10.1.2.99 \
  --target-tags=TARGET_TAG

Várias regras de firewall de saída

Uma abordagem mais escalonável envolve a configuração de duas regras: uma regra padrão de baixa prioridade, que restringe o acesso do VIP do balanceador de carga, e uma segunda, que permite que um subconjunto de clientes marcados acesse o VIP do balanceador de carga. Somente VMs com tags podem acessar o VIP.

  1. Criar a regra de menor prioridade:

    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. Criar a regra de prioridade mais 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 contas de serviço em vez de tags para controlar o acesso, basta usar a opção --target-service-accounts em vez da sinalização --target-tags ao criar regras de firewall.

Escalonar o acesso restrito a back-ends internos do balanceador de carga do aplicativo com base em sub-redes

Manter regras de firewall separadas ou adicionar novos IPs de balanceamento de carga às regras existentes, conforme descrito na seção anterior, é inconveniente à medida que o número de regras de encaminhamento aumenta. Uma maneira de evitar isso é alocar os endereços IP da regra de encaminhamento de uma sub-rede reservada. Depois, o tráfego de instâncias marcadas com tags ou contas de serviço é permitido ou bloqueado usando a sub-rede reservada como o intervalo de destino das regras de firewall. Isso permite que você controle efetivamente o acesso a um grupo de VIPs de regras de encaminhamento sem precisar manter as regras de saída do firewall por VIP.

Veja a seguir as etapas de nível mais alto para configurar isso, pressupondo que você criará todos os outros recursos necessários do balanceador de carga separadamente.

gcloud

  1. Crie uma sub-rede regional que será usada para alocar endereços IP com balanceamento de carga para regras de encaminhamento:

    gcloud compute networks subnets create l7-ilb-restricted-subnet \
      --network=lb-network \
      --region=us-west1 \
      --range=10.127.0.0/24
    
  2. Crie uma regra de encaminhamento que use um endereço da sub-rede. O exemplo a seguir usa o endereço 10.127.0.1 da sub-rede criada na etapa anterior.

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

  3. Crie uma regra de firewall para restringir o tráfego destinado aos endereços IP do intervalo na sub-rede da regra de encaminhamento (l7-ilb-restricted-subnet):

    gcloud compute firewall-rules create restrict-traffic-to-subnet \
      --network=lb-network \
      --action=deny \
      --direction=egress \
      --rules=tcp:80 \
      --priority=100 \
      --destination-ranges=10.127.0.0/24 \
      --target-tags=TARGET_TAG
    

Configurar a subconfiguração do back-end

A subconfiguração de back-end melhora o desempenho e a escalonabilidade ao atribuir um subconjunto de back-ends a cada uma das instâncias de proxy. Quando ativada para um serviço de back-end, ela ajusta o número de back-ends usados por cada instância de proxy da seguinte maneira:

  • À medida que o número de instâncias de proxy que participam do balanceador de carga aumenta, o tamanho do subconjunto diminui.

  • Quando o número total de back-ends em uma rede excede a capacidade de uma única instância de proxy, o tamanho do subconjunto é reduzido automaticamente para cada serviço com a subconfiguração de back-end ativada.

Neste exemplo, mostramos como criar os recursos do balanceador de carga interno do aplicativo e ativar a subcriação de back-end:

  1. Use a configuração de exemplo para criar um serviço de back-end regional l7-ilb-backend-service.
  2. Ative a criação de subconjuntos de back-end especificando a sinalização --subsetting-policy como CONSISTENT_HASH_SUBSETTING. Defina o esquema de balanceamento de carga como INTERNAL_MANAGED.

    gcloud

    Use o comando gcloud a seguir para atualizar l7-ilb-backend-service com a subconfiguração de back-end:

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

    API

    Faça uma solicitação PATCH ao método regionBackendServices/patch.

    PATCH https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/regions/us-west1/backendServices/l7-ilb-backend-service
    
    {
     "subsetting":
    {
     "policy": CONSISTENT_HASH_SUBSETTING
    }
    }
    

Também é possível refinar o balanceamento de carga do back-end configurando a política localityLbPolicy. Para mais informações, consulte Políticas de tráfego.

Usar o mesmo endereço IP entre várias regras de encaminhamento internas

Para que várias regras de encaminhamento interno compartilhem o mesmo endereço IP interno, é necessário reservar o endereço IP e definir a sinalização --purpose como SHARED_LOADBALANCER_VIP.

gcloud

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP
Se você precisar redirecionar o tráfego HTTP para HTTPS, crie duas regras de encaminhamento com um endereço IP comum. Para mais informações, consulte Configurar o redirecionamento HTTP para HTTPS em balanceadores de carga internos de aplicativos.

A seguir