Como se preparar para a configuração de balanceamento de carga HTTP(S) interno

A configuração do balanceamento de carga de HTTP(S) interno tem duas fases:

  • Executar tarefas de pré-requisito, como garantir que as contas necessárias tenham as permissões corretas e preparar a rede VPC.
  • Configurar os recursos do balanceador de carga.

Neste guia, descrevemos como configurar os pré-requisitos. Há outros guias com a descrição de como configurar os recursos de balanceamento 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
Adicionar e remover regras de firewall Administrador de segurança
Criar instâncias Administrador de instâncias

Visão geral da configuração

É possível configurar o balanceamento de carga HTTP(S) 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 balanceamento de carga HTTP(S) interno (clique para ampliar)
Componentes numerados do balanceamento de carga HTTP(S) interno (clique para ampliar)

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

O diagrama mostra:

  1. Uma rede VPC com duas sub-redes:

    1. Uma sub-rede é usada para os back-ends (grupos de instâncias e NEGs) e a 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. É necessário criar uma sub-rede somente proxy em cada região de uma rede VPC em que você usa balanceadores de carga HTTP(S) internos. A sub-rede somente proxy da região é compartilhada com todos os balanceadores de carga HTTP(S) internos na região. Os endereços de origem dos pacotes enviados do balanceador de carga HTTP(S) interno para os back-ends do seu serviço são alocados da sub-rede somente proxy. Neste exemplo, a sub-rede somente proxy para a região tem um intervalo de endereços IP principal de 10.129.0.0/26. Para mais informações, consulte Sub-redes somente proxy para balanceadores de carga HTTP(S) internos.

  2. Regras de firewall que permitem fluxos de tráfego pretendidos em sua rede. Isso inclui a adição de uma regra que permite que o tráfego das portas TCP 80, 443 e 8000 de 10.129.0.0/26 (o intervalo de sub-redes somente proxy neste exemplo) e outra regra para as sondagens de verificação de integridade.

  3. Instâncias de back-end. Neste exemplo, demonstramos as seguintes implantações de back-end:

    1. VMs do Google Compute Engine
    2. Back-ends do Google Kubernetes Engine (GKE) adicionados a grupos de endpoints da rede (NEGs, na sigla em inglês)
  4. Grupos de instâncias e NEGs:

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

    Em cada zona, é possível ter uma combinação de tipos de grupo de back-end com base nos requisitos da sua 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 descriptografa o tráfego SSL usando o certificado SSL quando você configura o balanceamento de carga HTTPS. Ele pode encaminhar o tráfego para as instâncias por 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.

Como 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 HTTP(S) 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: a rede é uma rede VPC de modo personalizado denominada lb-network.

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

  • Sub-rede para proxies: uma sub-rede denominada proxy-subnet na região us-west1 usa 10.129.0.0/26 como o intervalo de IP principal.

Como configurar a rede e a sub-rede para back-ends

Console

  1. Acesse a página "Redes VPC" no Console do Google Cloud Platform.
    Acessar a página "Redes VPC"
  2. Clique em Criar rede VPC.
  3. Informe um Nome de lb-network.
  4. Na seção Sub-redes:
    • Defina o Modo de criação de sub-rede como Personalizado.
    • Na seção Nova sub-rede, insira as informações a seguir:
      • Nome: backend-subnet
      • Região: us-west1
      • Intervalo de endereços IP: 10.1.2.0/24
      • Clique em Concluído.
  5. 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
    

api

Faça uma solicitação POST para o método networks.insert, substituindo [project-id] pelo ID do projeto.

POST https://www.googleapis.com/compute/v1/projects/[project-id]/global/networks
{
  "routingConfig": {
    "routingMode": "REGIONAL"
  },
  "name": "lb-network",
  "autoCreateSubnetworks": false
}

Faça uma solicitação POST para o método subnetworks.insert, substituindo [project-id] pelo ID do projeto.

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

Como configurar a sub-rede somente proxy

A sub-rede somente proxy é para todos os balanceadores de carga HTTP(S) internos na região us-west1.

Console

Se você estiver usando o Console do GCP, poderá esperar e criar a sub-rede somente proxy mais tarde na IU de balanceamento de carga. Consulte Como continuar o processo de configuração.

gcloud

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

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

api

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

POST https://www.googleapis.com/compute/projects/[project-id]/regions/us-west1/subnetworks
{
  "name": "proxy-subnet",
  "ipCidrRange": "10.129.0.0/26",
  "network": "projects/[project-id]/global/networks/lb-network",
  "region": "projects/[project-id]/regions/us-west1",
  "purpose": "INTERNAL_HTTPS_LOAD_BALANCER",
  "role": "ACTIVE"
}

Como configurar regras de firewall

Neste exemplo, usamos as seguintes regras de firewall:

  • fw-allow-backend-subnet: uma regra de entrada, aplicável a todos os destinos na rede VPC, permitindo todo o tráfego TCP, UDP e ICMP das origens no intervalo 10.1.2.0/24. Essa regra permite tráfego de entrada de qualquer origem em backend-subnet para as instâncias (VMs) submetidas a balanceamento de carga. No exemplo, mostramos a regra de firewall aplicada a todas as instâncias na rede. Como alternativa, aplique a regra somente aos back-ends reais do balanceador de carga.

  • fw-allow-ssh: uma regra de entrada, aplicável às instâncias submetidas a balanceamento de carga, 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 às quais a regra de firewall se aplica.

  • fw-allow-health-check: uma regra de entrada, aplicável às instâncias submetidas a balanceamento de carga, que permite todo o tráfego TCP dos sistemas de verificação de integridade do GCP (em 130.211.0.0/22 e 35.191.0.0/16). Neste exemplo, usamos a tag de destino load-balanced-backend para identificar as instâncias às quais ele deve se aplicar.

  • 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 8000 dos proxies gerenciados do balanceador de carga HTTP(S) interno. Neste exemplo, usamos a tag de destino load-balanced-backend para identificar as instâncias às quais ele deve se aplicar.

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.

Console

  1. Acesse a página "Regras de firewall" no Console do Google Cloud Platform.
    Acessar a página "Regras de firewall"
  2. Clique em Criar regra de firewall e insira as seguintes informações para criar a regra que permite o tráfego de sub-rede:
    • Nome: fw-allow-backend-subnet
    • Rede: lb-network
    • Direção do tráfego: entrada
    • Ação quando há correspondência: permitir
    • Destinos: todas as instâncias na rede
    • Filtro de origem: IP ranges
    • Intervalos de IP de origem: 10.1.2.0/24
    • Protocolos e portas: escolha Protocolos e portas especificados e marque tcp, udp e icmp.
  3. Clique em Criar.
  4. Clique em Criar regra de firewall novamente para criar a regra que permite conexões SSH de entrada:
    • Nome: fw-allow-ssh
    • Rede: lb-network
    • Direção do tráfego: entrada
    • Ação quando há correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de destino: allow-ssh
    • Filtro de origem: IP ranges
    • Intervalos de IP de origem: 0.0.0.0/0
    • Protocolos e portas: escolha Protocolos e portas especificados, marque tcp e digite 22 para o número da porta.
  5. Clique em Criar.
  6. Clique em Criar regra de firewall pela terceira vez para criar a regra que permite verificações de integridade do GCP:
    • Nome: fw-allow-health-check
    • Rede: lb-network
    • Direção do tráfego: entrada
    • Ação quando há correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de destino: load-balanced-backend
    • Filtro de origem: IP ranges
    • Intervalos de IP de origem: 130.211.0.0/22 e 35.191.0.0/16
    • Protocolos e portas : escolha Protocolos e portas especificados e marque tcp (escolha um conjunto de portas, se preferir)
  7. Clique em Criar.
  8. Clique em Criar regra de firewall uma quarta vez para criar a regra que permite que os servidores proxy do balanceador de carga se conectem aos back-ends:
    • Nome: fw-allow-proxies
    • Rede: lb-network
    • Direção do tráfego: entrada
    • Ação quando há correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de destino: load-balanced-backend
    • Filtro de origem: IP ranges
    • Intervalos de IP de origem: 10.129.0.0/26
    • Protocolos e portas: escolha Protocolos e portas especificados, marque tcp e digite 80, 443, 8000 para os números da porta.
  9. Clique em Criar.

gcloud

  1. Crie a regra de firewall fw-allow-backend-subnet para permitir a comunicação dentro da sub-rede com o comando gcloud compute firewall-rules create.

    gcloud compute firewall-rules create fw-allow-backend-subnet \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.1.2.0/24 \
        --rules=tcp,udp,icmp
    
  2. Crie a regra de firewall fw-allow-ssh que permita a conectividade SSH para VMs com a tag de rede allow-ssh. Quando você omite source-ranges, o GCP interpreta a regra como sendo qualquer origem.

    gcloud compute firewall-rules create fw-allow-ssh \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  3. Crie a regra fw-allow-health-check para permitir verificações de integridade do GCP. 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
    
  4. Crie a regra fw-allow-proxies para permitir que os proxies do balanceador de carga HTTP(S) interno se conectem aos back-ends.

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

api

Crie a regra de firewall fw-allow-backend-subnet fazendo uma solicitação POST para o método firewalls.insert, substituindo [project-id] pelo ID do projeto.

POST https://www.googleapis.com/compute/v1/projects/[project-id]/global/firewalls
{
  "name": "fw-allow-backend-subnet",
  "network": "projects/[project-id]/global/networks/lb-network",
  "sourceRanges": [
    "10.1.2.0/24"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    },
    {
      "IPProtocol": "udp"
    },
    {
      "IPProtocol": "icmp"
    }
  ],
  "direction": "INGRESS"
}

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

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

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

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

Crie a regra de firewall fw-allow-proxies para permitir o tráfego TCP dentro da sub-rede de proxy chamando o método firewalls.insert, substituindo [project-id] pelo ID do projeto.

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/26"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "80"
      ]
    },
    {
      "IPProtocol": "tcp",
      "ports": [
        "443"
      ]
    },
    {
      "IPProtocol": "tcp",
      "ports": [
        "8000"
      ]
    }
  ],
  "direction": "INGRESS"
}

Como continuar o processo de configuração

Para configurar o balanceamento de carga HTTP(S) interno, use um dos seguintes procedimentos, dependendo se os serviços de back-end são executados em VMs do Compute Engine ou em pods do GKE:

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…