Esta página foi traduzida pela API Cloud Translation.

Codelab de balanceamento de carga HTTPs externo com gerenciamento de tráfego avançado (Envoy)

1. Introdução

Este é o codelab de balanceamento de carga de HTTPs externos com gerenciamento de tráfego avançado (Envoy).

A versão mais recente do balanceador de carga HTTP(S) externo com gerenciamento de tráfego avançado contém todos os recursos do balanceador de carga HTTP(S) externo global clássico, mas com uma lista cada vez maior de recursos de gerenciamento de tráfego avançado. Alguns desses recursos são novos para nossos balanceadores de carga e outros fornecem recursos aprimorados aos recursos atuais. Uma lista parcial desses recursos inclui:

O que você vai aprender

Como configurar um grupo gerenciado de instâncias, a VPC associada e as regras de firewall
Como usar os recursos avançados de gerenciamento de tráfego do novo balanceador de carga
Como validar se os recursos avançados de gerenciamento de tráfego estão funcionando conforme o esperado.

O que é necessário

Rede básica e conhecimento de HTTP
Conhecimento básico de linha de comando do Unix/Linux

Topologia e caso de uso

Figura 1: topologia de roteamento do balanceador de carga HTTP

Durante este codelab, você vai configurar três grupos gerenciados de instâncias, um nas regiões leste, oeste e central. Você vai criar um balanceador de carga HTTPS externo global. O balanceador de carga vai utilizar vários recursos da lista de recursos avançados com suporte do balanceador de carga baseado em Envoy. Após a implantação, você vai gerar uma carga simulada e verificar se as configurações definidas estão funcionando corretamente.

2. Configuração e requisitos

Configuração de ambiente autoguiada

Faça login no Console do Google Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.

O Nome do projeto é o nome de exibição para os participantes do projeto. Ele é uma string de caracteres que não é usada pelas APIs do Google e pode ser atualizada a qualquer momento.
O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser alterado após a definição. O Console do Cloud gera automaticamente uma string única, geralmente não importa o que seja. Na maioria dos codelabs, você precisará fazer referência ao ID do projeto, que geralmente é identificado como PROJECT_ID. Então, se você não gostar dele, gere outro ID aleatório ou crie um próprio e veja se ele está disponível. Em seguida, ele fica "congelado" depois que o projeto é criado.
Há um terceiro valor, um Número de projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.

Em seguida, você precisará ativar o faturamento no Console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não será muito cara, se tiver algum custo. Para encerrar os recursos e não gerar cobranças além deste tutorial, siga as instruções de "limpeza" encontradas no final do codelab. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.

Inicie o Cloud Shell

Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.

No Console do GCP, clique no ícone do Cloud Shell na barra de ferramentas localizada no canto superior direito:

O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:

Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Todo o trabalho neste laboratório pode ser feito apenas com um navegador.

Antes de começar

No Cloud Shell, verifique se o ID do projeto está configurado

gcloud config list project

gcloud config set project [SEU-NOME-DO-PROJETO]

PROJECT_ID=[YOUR-PROJECT-NAME]

echo $PROJECT_ID

Ativar APIs

Ative todos os serviços necessários

gcloud services enable compute.googleapis.com
gcloud services enable logging.googleapis.com
gcloud services enable monitoring.googleapis.com

3. criar a rede VPC

Crie uma rede VPC

No Cloud Shell

gcloud compute networks create httplbs --subnet-mode=auto

Saída

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/httplbs].
NAME: httplbs
SUBNET_MODE: AUTO
BGP_ROUTING_MODE: REGIONAL
IPV4_RANGE:
GATEWAY_IPV4:

Crie regras de firewall de VPC

Depois de criar a VPC, você vai criar regras de firewall. A regra de firewall será usada para permitir que todos os IPs acessem o IP externo do site do aplicativo de teste na porta 80 para tráfego HTTP.

No Cloud Shell

gcloud compute firewall-rules create httplb-allow-http-rule \
--allow tcp:80 \
--network httplbs \
--source-ranges 0.0.0.0/0 \
--priority 700

Saída

Creating firewall...working..Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls/httplb-allow-http-rule].
Creating firewall...done.
NAME: httplb-allow-http-rule
NETWORK: httplbs
DIRECTION: INGRESS
PRIORITY: 700
ALLOW: tcp:80
DENY:
DISABLED: False

4. Configurar os grupos gerenciados de instâncias

Você precisa configurar grupos gerenciados de instâncias que incluam os padrões dos recursos de back-end usados pelo balanceador de carga HTTP. Primeiro vamos criar modelos de instância que definem a configuração das VMs que serão criadas em cada região. Em seguida, para um back-end em cada região, vamos criar um grupo gerenciado de instâncias que faz referência a um modelo de instância.

Os grupos gerenciados de instâncias podem ter escopo zonal ou regional. Para este exercício de laboratório, vamos criar três grupos gerenciados de instâncias regionais, um em us-east1, um em us-west1 e outro em us-central1.

Nesta seção, você encontra um script de inicialização pré-criado que será referenciado na criação da instância. O script de inicialização instala e ativa os recursos do servidor da Web que serão usados para simular um aplicativo da Web. Sinta-se à vontade para explorar esse script.

Criar os modelos de instâncias Leste, Oeste e Central

A primeira etapa é criar o modelo de instância de us-east-1.

No Cloud Shell

gcloud compute instance-templates create us-east1-template \
   --region=us-east1 \
   --network=httplbs \
   --tags=http-server, \
   --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'

Saída

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-east1-template].
NAME: us-east1-template
MACHINE_TYPE: n1-standard-1
PREEMPTIBLE:
CREATION_TIMESTAMP: 2021-11-11T11:02:37.511-08:00

A próxima etapa é criar o modelo de instância de us-west-1.

No Cloud Shell

gcloud compute instance-templates create us-west1-template \
   --region=us-west1 \
   --network=httplbs \
   --tags=http-server, \
   --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'

Saída

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-west1-template].
NAME: us-west1-template
MACHINE_TYPE: n1-standard-1
PREEMPTIBLE:
CREATION_TIMESTAMP: 2021-11-11T11:03:08.577-08:00

A próxima etapa é criar o modelo de instância de us-central-1.

No Cloud Shell

gcloud compute instance-templates create us-central1-template \
   --region=us-central1 \
   --network=httplbs \
   --tags=http-server, \
   --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'

Saída

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-central1-template].
NAME: us-central1-template
MACHINE_TYPE: n1-standard-1
PREEMPTIBLE:
CREATION_TIMESTAMP: 2021-11-11T11:03:44.179-08:00

Agora é possível verificar se nossos modelos de instância foram criados com o seguinte comando gcloud:

No Cloud Shell

gcloud compute instance-templates list

Saída

NAME                  MACHINE_TYPE   PREEMPTIBLE  CREATION_TIMESTAMP
us-central1-template   n1-standard-1         2021-11-09T09:25:37.263-08:00
us-east1-template      n1-standard-1         2021-11-09T09:24:35.275-08:00
us-west1-template      n1-standard-1         2021-11-09T09:25:08.016-08:00

Criar os grupos de instâncias gerenciadas nas regiões leste, oeste e central

Agora precisamos criar um grupo gerenciado de instâncias usando os modelos de instância criados anteriormente.

No Cloud Shell

gcloud compute instance-groups managed create us-east1-mig \
--base-instance-name=us-east1-mig \
--size=1 \
--template=us-east1-template \
--zone=us-east1-b

Saída

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-east1-b/instanceGroupManagers/us-east1-mig].
NAME: us-east1-mig
LOCATION: us-east1-b
SCOPE: zone
BASE_INSTANCE_NAME: us-east1-mig
SIZE: 0
TARGET_SIZE: 1
INSTANCE_TEMPLATE: us-east1-template
AUTOSCALED: no

No Cloud Shell

gcloud compute instance-groups managed create us-west1-mig \
--base-instance-name=us-west1-mig \
--size=1 \
--template=us-west1-template \
--zone=us-west1-a

Saída

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroupManagers/us-west1-mig].
NAME: us-west1-mig
LOCATION: us-west1-a
SCOPE: zone
BASE_INSTANCE_NAME: us-west1-mig
SIZE: 0
TARGET_SIZE: 1
INSTANCE_TEMPLATE: us-west1-template
AUTOSCALED: no

No Cloud Shell

gcloud compute instance-groups managed create us-central1-mig \
--base-instance-name=us-central1-mig \
--size=1 \
--template=us-central1-template \
--zone=us-central1-a

Saída

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-central1-a/instanceGroupManagers/us-central1-mig].
NAME: us-central1-mig
LOCATION: us-central1-a
SCOPE: zone
BASE_INSTANCE_NAME: us-central1-mig
SIZE: 0
TARGET_SIZE: 1
INSTANCE_TEMPLATE: us-central1-template
AUTOSCALED: no

É possível verificar se os grupos de instâncias foram criados com o seguinte comando gcloud:

No Cloud Shell

gcloud compute instance-groups list

Saída

NAME                  LOCATION      SCOPE   NETWORK         MANAGED INSTANCES
us-central1-mig       us-central1   zone    httplbs          Yes      1
us-west1-mig          us-west1      zone    httplbs          Yes      1
us-east1-mig          us-east1      zone    httplbs          Yes      1

Verificar a funcionalidade do servidor da Web

Cada instância é configurada para executar um servidor da Web Apache com um script PHP simples que renderiza:

Para garantir que seus servidores da Web estejam funcionando corretamente, acesse Compute Engine -> do que para instâncias de VM padrão. Verifique se as novas instâncias (por exemplo, us-east1-mig-xxx) foram criadas de acordo com as definições do grupo de instâncias.

Agora, faça uma solicitação da Web em seu navegador para garantir que o servidor esteja em execução (pode levar um minuto para iniciar). Na página "Instâncias de VM" em "Compute Engine", selecione uma instância criada pelo grupo e clique no IP externo (público).

Ou, em seu navegador, navegue até http://<IP_Address>

5. Configurar o balanceador de carga

Criar verificação de integridade

Primeiro, precisamos criar uma verificação de integridade básica para garantir que nossos serviços estejam funcionando. Vamos criar uma verificação de integridade básica. Há muitas outras personalizações avançadas disponíveis.

No Cloud Shell

gcloud compute health-checks create http http-basic-check \
    --port 80

Reservar endereço IP externo

Nesta etapa, você precisará reservar um endereço IP estático disponível globalmente que será anexado posteriormente ao balanceador de carga.

No Cloud Shell

gcloud compute addresses create lb-ipv4-2 \
    --ip-version=IPV4 \
    --global

Anote o endereço IP que foi reservado.

gcloud compute addresses describe lb-ipv4-2 \
    --format="get(address)" \
    --global

Criar serviços de back-end

Agora é preciso criar um serviço de back-end para cada um dos grupos gerenciados de instâncias criados anteriormente. Uma para Leste, Oeste e Central.

Como criar um serviço de back-end para o grupo de instâncias gerenciadas Leste.

No Cloud Shell

gcloud beta compute backend-services create east-backend-service \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --port-name=http \
    --health-checks=http-basic-check \
    --global

Criar um serviço de back-end para o grupo gerenciado de instâncias do Oeste.

No Cloud Shell

gcloud beta compute backend-services create west-backend-service \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --port-name=http \
    --health-checks=http-basic-check \
    --global

Criar um serviço de back-end para o grupo gerenciado de instâncias da Central.

No Cloud Shell

gcloud beta compute backend-services create central-backend-service \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --port-name=http \
    --health-checks=http-basic-check \
    --global

Adicionar MIGs aos serviços de back-end

Agora que criamos os respectivos serviços de back-end para cada cluster de aplicativo, precisamos adicionar os grupos gerenciados de instâncias criados anteriormente a cada serviço de back-end.

Adicionar MIG Leste ao serviço de back-end.

No Cloud Shell

gcloud beta compute backend-services add-backend east-backend-service \
    --balancing-mode='UTILIZATION' \
    --instance-group=us-east1-mig \
    --instance-group-zone=us-east1-b \
    --global

Adicione o MIG Ocidental ao serviço de back-end.

No Cloud Shell

gcloud beta compute backend-services add-backend west-backend-service \
    --balancing-mode='UTILIZATION' \
    --instance-group=us-west1-mig \
    --instance-group-zone=us-west1-a \
    --global

Adicione o MIG Ocidental ao serviço de back-end.

No Cloud Shell

gcloud beta compute backend-services add-backend central-backend-service \
    --balancing-mode='UTILIZATION' \
    --instance-group=us-central1-mig \
    --instance-group-zone=us-central1-a \
    --global

Criar mapa de URL

Os recursos avançados de gerenciamento de tráfego deste laboratório estarão disponíveis no mapa de URLs. Precisamos criar um arquivo .yaml que conterá a configuração. Dentro do arquivo .yaml, criamos uma correspondência de prefixo em /roundrobbin, portanto, apenas o tráfego correspondente a /roundrobbin será afetado por essas configurações. Especificamos que 50% do tráfego deve ir para east-backend-service e 50% para west-backend-service. Além disso, adicionamos um valor de cabeçalho de resposta {test}, que vai estar presente em todas as respostas. Por fim, adicionamos que todo o tráfego deve ser espelhado ao central-backend-service. O tráfego é duplicado e enviado aqui apenas para fins de teste.

Salve o exemplo como um arquivo .yaml na sua máquina.

defaultService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
kind: compute #urlMap
name: web-map-http
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: /roundrobbin
    priority: 2
    headerAction:
        responseHeadersToAdd:
          - headerName: test
            headerValue: value
            replace: True
    routeAction:
        weightedBackendServices:
        - backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
          weight: 50
        - backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/west-backend-service
          weight: 50
        retryPolicy:
            retryConditions: ['502', '504']
            numRetries: 3
            perTryTimeout:
                seconds: 1
                nanos: 50
        requestMirrorPolicy:
          backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/central-backend-service

Crie o mapa de URL importando o documento da sua máquina. O caminho de origem será diferente dependendo de onde você salvar o arquivo .yaml.

No Cloud Shell

gcloud beta compute url-maps import web-map-http \
   --source /Users/[USERNAME]/Documents/Codelab/lbconfig.yaml \
   --global

Criar um front-end HTTP

A etapa final na criação do balanceador de carga é a criação do front-end. Isso vai mapear o endereço IP reservado anteriormente para o mapa de URL do balanceador de carga que você criou.

No Cloud Shell

gcloud beta compute target-http-proxies create http-lb-proxy-adv \
    --url-map=web-map-http

Em seguida, crie uma regra de encaminhamento global que mapeará o endereço IP reservado anteriormente para o proxy HTTP.

No Cloud Shell

gcloud beta compute forwarding-rules create http-content-rule \
    --load-balancing-scheme EXTERNAL_MANAGED \
    --address=lb-ipv4-2 \
    --global \
    --target-http-proxy=http-lb-proxy-adv \
    --ports=80

6. Verificar se os recursos avançados de tráfego estão funcionando

Para verificar se o recurso de divisão de tráfego implementado está funcionando, é necessário gerar carga. Para isso, vamos criar uma nova VM para simular a carga.

Criar regra de permissão de firewall SSH

Para usar o SSH na VM que vai gerar tráfego, primeiro crie uma regra de firewall para permitir o tráfego SSH.

No Cloud Shell

gcloud compute firewall-rules create fw-allow-ssh \
    --network=httplbs \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

Saída

NAME          NETWORK  DIRECTION  PRIORITY  ALLOW   DENY  DISABLED
fw-allow-ssh  httplbs  INGRESS    1000      tcp:22        False

Crie Siege-vm

Agora você vai criar a siege-vm que será usada para gerar cargas

No Cloud Shell

gcloud compute instances create siege-vm \
    --network=httplbs \
    --zone=us-east4-c \
    --machine-type=e2-medium \
    --tags=allow-ssh,http-server \
    --metadata=startup-script='sudo apt-get -y install siege'

Saída

NAME     ZONE        MACHINE_TYPE INTERNAL_IP  EXTERNAL_IP    STATUS
siege-vm us-east4-c  e2-medium    10.150.0.3   34.85.218.119  RUNNING

Em seguida, conecte-se via SSH à VM que você criou. Depois disso, clique em SSH para iniciar um terminal e se conectar.

Depois de se conectar, execute o comando a seguir para gerar carga. Use o endereço IP que você reservou anteriormente para o balanceador de carga HTTP externo.

No Cloud Shell

siege -c 250 http://$lb-ipv4-2/roundrobbin

Saída

New configuration template added to /home/cloudcurriculumdeveloper/.siege
Run siege -C to view the current settings in that file
[alert] Zip encoding disabled; siege requires zlib support to enable it: No such file or directory
** SIEGE 4.0.2
** Preparing 250 concurrent users for battle.
The server is now under siege...

Verificar a distribuição de carga

Agora que o siege está em execução, é hora de verificar se o tráfego está sendo distribuído igualmente para os grupos gerenciados de instâncias nas regiões leste e oeste. Além disso, confira se o espelhamento de tráfego está funcionando e se o tráfego está sendo enviado para o grupo de instâncias gerenciadas central.

No menu de navegação do console do Cloud, clique em Serviços de rede > Balanceamento de carga. Clique em "Back-ends". Clique no menu "Advanced", como mostra a captura de tela abaixo.

Navegue até a guia "Serviços de back-end" e selecione a opção

Será possível ver a divisão de tráfego nesse MIG em tempo real. Anote a taxa, você poderá compará-la com west-backend-service em alguns instantes.

Da mesma forma, navegue até west-backend-service. Você também deve ver o tráfego fluindo para esse serviço. A taxa será semelhante à que você viu em east-backend-service, já que configurou uma divisão de tráfego round-robbin de 50/50.

Para confirmar se a política de espelhamento de tráfego que você criou está funcionando, é necessário verificar a utilização do grupo gerenciado de instâncias central-backend-service. Para isso, acesse "Compute", "Compute Engine", "Grupos de instâncias" e selecione "us-central1-mig". Em seguida, acesse a guia de monitoramento.

4cf569efb3ba3c2b.png.

Os gráficos serão preenchidos, demonstrando que o tráfego foi espelhado no grupo gerenciado de instâncias.

Interrompa o Cerco

Agora que você demonstrou que a divisão avançada de tráfego está funcionando, é hora de interromper o cerco. Para isso, retorne ao terminal SSH de siege-vm e pressione CTRL+C para interromper a execução do siege.

Validar o cabeçalho de resposta sendo enviado

Antes da limpeza, é possível validar rapidamente se o cabeçalho de resposta apropriado está sendo enviado pelo balanceador de carga http. Ele foi configurado para enviar o teste de cabeçalho com valor de conteúdo. Executar o comando curl no Cloud Shell vai gerar a resposta esperada.

No Cloud Shell

curl -svo /dev/null http://lb-ipv4-2/roundrobbin

Saída

*   Trying lb-ipv4-2..
* TCP_NODELAY set
* Connected to  lb-ipv4-2 ( lb-ipv4-2) port 80 (#0)
> GET /roundrobbin HTTP/1.1
> Host:  lb-ipv4-2
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< date: Wed, 10 Nov 2021 17:05:27 GMT
< server: envoy
< Content-Length: 273
< content-type: text/html; charset=iso-8859-1
< via: 1.1 google
< test: value
<
{ [273 bytes data]
* Connection #0 to host 34.149.2.26 left intact
* Closing connection 0

7. Limpeza do laboratório

Agora que concluímos o ambiente do laboratório, é hora de desmontá-lo. Execute os comandos a seguir para excluir o ambiente de teste.

No Cloud Shell

gcloud compute instances delete siege-vm

gcloud alpha compute forwarding-rules delete http-content-rule --global
gcloud alpha compute target-http-proxies delete http-lb-proxy-adv
gcloud alpha compute url-maps delete web-map-http
gcloud alpha compute backend-services delete east-backend-service --global
gcloud alpha compute backend-services delete west-backend-service --global
gcloud alpha compute backend-services delete central-backend-service --global

gcloud compute addresses delete lb-ipv4-2 --global
gcloud compute health-checks delete http-basic-check 

gcloud compute instance-groups managed delete us-east1-mig --zone us-east1-b
gcloud compute instance-groups managed delete us-west1-mig --zone us-west1-a
gcloud compute instance-groups managed delete us-central1-mig --zone us-central1-a

gcloud compute instance-templates delete "us-east1-template" 
gcloud compute instance-templates delete "us-west1-template" 
gcloud compute instance-templates delete "us-central1-template" 

gcloud compute firewall-rules delete httplb-allow-http-rule
gcloud compute firewall-rules delete fw-allow-ssh

gcloud compute networks delete httplbs

8. Parabéns!

Você concluiu o codelab de HTTPs externos com gerenciamento de tráfego avançado (Envoy).

O que vimos

Como configurar um grupo gerenciado de instâncias, a VPC associada e as regras de firewall
Como usar os recursos avançados de gerenciamento de tráfego do novo balanceador de carga
Como validar se os recursos avançados de gerenciamento de tráfego estão funcionando conforme o esperado.

Próximas etapas

Experimente alguns dos outros recursos de roteamento avançados, como reescrever URLs, adicionar cabeçalhos CORS e muito mais ( link).