Configure um Application Load Balancer interno entre regiões com o Cloud Run

Este documento mostra como implementar um Application Load Balancer interno entre regiões com o Cloud Run. Para configurar esta opção, usa um back-end de NEG sem servidor para o balanceador de carga.

Embora este documento descreva uma configuração do Cloud Run, um NEG sem servidor para o Cloud Run pode apontar para um recurso do Cloud Run ou um recurso das funções do Cloud Run (2.ª geração).

Os NEGs sem servidor permitem-lhe usar os serviços do Cloud Run com o seu equilibrador de carga. Depois de configurar um balanceador de carga com o back-end do NEG sem servidor, os pedidos ao balanceador de carga são encaminhados para o back-end do Cloud Run.

O balanceamento de carga entre regiões oferece redundância, para que, se uma região estiver inacessível, o tráfego seja automaticamente desviado para outra região. Com base na localização do Envoy, o tráfego de proxy é distribuído aos serviços do Cloud Run da seguinte forma:

  • Se os serviços do Cloud Run de várias regiões estiverem configurados na mesma região que o Envoy, é preferível o NEG localizado na mesma região que o Envoy. O tráfego é enviado para a região de alternativa apenas se a deteção de valores atípicos estiver ativada e o NEG local não estiver em bom estado.
  • Se os serviços do Cloud Run multirregionais não estiverem configurados na mesma região que o Envoy, o tráfego é distribuído uniformemente por todos os NEGs. Os NEGs localizados mais perto não são preferenciais.
  • Se o Identity-Aware Proxy estiver ativado, só é suportado um NEG sem servidor. No entanto, pode configurar serviços do Cloud Run adicionais, mas o equilibrador de carga não envia tráfego para os mesmos.

Antes de começar

Antes de seguir este guia, familiarize-se com o seguinte:

Implemente um serviço do Cloud Run

As instruções nesta página pressupõem que já tem um serviço do Cloud Run em execução.

Para o exemplo nesta página, pode usar qualquer um dos inícios rápidos do Cloud Run para implementar um serviço do Cloud Run.

Para impedir o acesso ao serviço Cloud Run a partir da Internet, restrinja a entrada a internal. O tráfego do balanceador de carga da aplicação interno é considerado tráfego interno.

Colocar o serviço do Cloud Run em várias regiões ajuda a evitar falhas numa única região. Para implementar o serviço do Cloud Run nas regiões REGION_A e REGION_B, execute os seguintes comandos:

gcloud

gcloud run deploy CLOUD_RUN_SERVICE_NAMEA \
   --platform=managed \
   --allow-unauthenticated \
   --ingress=internal \
   --region=REGION_A \
   --image=IMAGE_URLA

gcloud run deploy CLOUD_RUN_SERVICE_NAMEB \
   --platform=managed \
   --allow-unauthenticated \
   --ingress=internal \
   --region=REGION_B \
   --image=IMAGE_URLB

Tome nota do nome do serviço que criar. O resto desta página mostra-lhe como configurar um equilibrador de carga que encaminha pedidos para este serviço.

Configure um recurso de certificado SSL

Crie um recurso de certificado SSL do Certificate Manager da seguinte forma:

Recomendamos a utilização de um certificado gerido pela Google.

Autorizações

Para seguir este guia, tem de conseguir criar instâncias e modificar uma rede num projeto. Tem de ser proprietário ou editor do projeto, ou ter todas as funções do IAM do Compute Engine seguintes.

Tarefa Função necessária
Crie redes, sub-redes e componentes do balanceador de carga Administrador de rede de Calcular
Adicione e remova regras de firewall Administrador de segurança de computação
Crie instâncias Administrador de instâncias do Compute

Para mais informações, consulte os seguintes guias:

Vista geral da configuração

Pode configurar o Application Load Balancer interno entre regiões, conforme descrito no diagrama seguinte:

Balanceador de carga de aplicações interno entre regiões com implementação do Cloud Run.
Balanceador de carga de aplicações interno entre regiões com implementação do Cloud Run (clique para aumentar).

Conforme mostrado no diagrama, este exemplo cria um Application Load Balancer interno entre regiões numa rede VPC, com um serviço de back-end e duas implementações do Cloud Run nas regiões REGION_A e REGION_B.

A configuração do balanceador de carga de aplicações interno entre regiões é descrita da seguinte forma:

  1. Uma rede da VPC com as seguintes sub-redes:

    • Sub-rede SUBNET_A e uma sub-rede só de proxy em REGION_A.
    • Sub-rede SUBNET_B e uma sub-rede só de proxy em REGION_B.

    Tem de criar sub-redes apenas de proxy em cada região de uma rede VPC onde usa balanceadores de carga de aplicações internos entre regiões. A sub-rede apenas de proxy da região é partilhada entre todos os balanceadores de carga de aplicações internos entre regiões na região. Os endereços de origem dos pacotes enviados do balanceador de carga para os back-ends do seu serviço são atribuídos a partir da sub-rede apenas de proxy. Neste exemplo, a sub-rede apenas de proxy para a região REGION_A tem um intervalo de endereços IP principal de 10.129.0.0/23 e, para REGION_B, tem um intervalo de endereços IP principal de 10.130.0.0/23, que é o tamanho de sub-rede recomendado.

  2. Uma regra de firewall que permite fluxos de tráfego de sub-rede só de proxy na sua rede. Isto significa adicionar uma regra que permita o tráfego das portas TCP 80, 443 e 8080 de 10.129.0.0/23 e 10.130.0.0/23 (o intervalo das sub-redes só de proxy neste exemplo).

  3. Outra regra de firewall para as sondas de verificação de funcionamento.

  4. Uma configuração de alta disponibilidade com back-ends sem servidor para implementações do Cloud Run nas regiões REGION_A e REGION_B. Se os backends numa região estiverem inativos, o tráfego é transferido para a outra região.

  5. Um serviço de back-end global que monitoriza a utilização e o estado de funcionamento dos back-ends. Certifique-se de que ativa a deteção de valores atípicos no serviço de back-end.

  6. Um mapa de URLs global que analisa o URL de um pedido e encaminha pedidos para serviços de back-end específicos com base no anfitrião e no caminho do URL do pedido.

  7. Um proxy HTTP ou HTTPS de destino global, que recebe um pedido do utilizador e encaminha-o para o mapa de URLs. Para HTTPS, configure um recurso de certificado SSL regional. O proxy de destino usa o certificado SSL para desencriptar o tráfego SSL se configurar o equilíbrio de carga HTTPS. O proxy de destino pode encaminhar o tráfego para as suas instâncias através de HTTP ou HTTPS.

  8. Regras de encaminhamento globais, que têm o endereço IP interno do seu balanceador de carga, para encaminhar cada pedido recebido para o proxy de destino.

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

    • O endereço IP pode (mas não tem de) ser proveniente da mesma sub-rede que os grupos de instâncias de back-end.
    • O endereço IP não pode ser proveniente de uma sub-rede reservada só de proxy com a respetiva flag --purpose definida como GLOBAL_MANAGED_PROXY.
    • Se quiser usar o mesmo endereço IP interno com várias regras de encaminhamento, defina a flag --purpose do endereço IP como SHARED_LOADBALANCER_VIP.

  9. Opcional: configure políticas de encaminhamento de DNS do tipo GEO para encaminhar o tráfego de clientes para o VIP do balanceador de carga na região mais próxima do cliente.

Configure a rede e as sub-redes

Na rede VPC, configure uma sub-rede em cada região onde os seus back-ends estão configurados. Além disso, configure um proxy-only-subnet em cada região na qual quer configurar o equilibrador de carga.

Este exemplo usa a seguinte rede de VPC, região e sub-redes:

  • Rede. A rede é uma rede VPC no modo personalizado denominada NETWORK.

  • Sub-redes para back-ends. Uma sub-rede denominada SUBNET_A na região REGION_A usa 10.1.2.0/24 para o respetivo intervalo de IP principal. A sub-rede denominada SUBNET_B na região REGION_B usa 10.1.3.0/24 para o respetivo intervalo de IP principal.

  • Sub-rede para proxies. Uma sub-rede denominada PROXY_SN_A na região REGION_A usa 10.129.0.0/23 para o respetivo intervalo de IP principal. Uma sub-rede denominada PROXY_SN_B na região REGION_B usa 10.130.0.0/23 para o respetivo intervalo de IP principal.

É possível aceder aos balanceadores de carga de aplicações internos entre regiões a partir de qualquer região na VPC. Assim, os clientes de qualquer região podem aceder globalmente aos back-ends do equilibrador de carga.

Configure as sub-redes de back-end

Consola

  1. Na Google Cloud consola, aceda à página Redes VPC.

    Aceda a redes de VPC

  2. Clique em Criar rede de VPC.

  3. Indique um Nome para a rede.

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

  5. Crie uma sub-rede para os back-ends do balanceador de carga. Na secção Nova sub-rede, introduza as seguintes informações:

    • Indique um Nome para a sub-rede.
    • Selecione uma região: REGION_A
    • Introduza um intervalo de endereços IP: 10.1.2.0/24

  6. Clique em Concluído.

  7. Clique em Adicionar sub-rede.

  8. Crie uma sub-rede para os back-ends do balanceador de carga. Na secção Nova sub-rede, introduza as seguintes informações:

    • Indique um Nome para a sub-rede.
    • Selecione uma região: REGION_B
    • Introduza um intervalo de endereços IP: 10.1.3.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 NETWORK --subnet-mode=custom

  2. Crie uma sub-rede na NETWORK rede na região REGION_A com o comando gcloud compute networks subnets create:

    gcloud compute networks subnets create SUBNET_A \
    --network=NETWORK \
    --range=10.1.2.0/24 \
    --region=REGION_A

  3. Crie uma sub-rede na NETWORK rede na região REGION_B com o comando gcloud compute networks subnets create:

    gcloud compute networks subnets create SUBNET_B \
    --network=NETWORK \
    --range=10.1.3.0/24 \
    --region=REGION_B

API

Faça um pedido POST ao método networks.insert. Substitua PROJECT_ID pelo ID do seu projeto.

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

{
 "routingConfig": {
   "routingMode": "regional"
 },
 "name": "NETWORK",
 "autoCreateSubnetworks": false
}

Faça um pedido POST ao método subnetworks.insert. Substitua PROJECT_ID pelo ID do seu projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

Faça um pedido POST ao método subnetworks.insert. Substitua PROJECT_ID pelo ID do seu projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

Configure a sub-rede só de proxy

Uma sub-rede apenas de proxy fornece um conjunto de endereços IP que Google Cloud usa para executar proxies Envoy em seu nome. Os proxies terminam as ligações do cliente e criam ligações aos backends.

Esta sub-rede apenas de proxy é usada por todos os equilibradores de carga regionais baseados no Envoy na mesma região que a rede VPC. Só pode existir uma sub-rede só de proxy ativa para uma determinada finalidade, por região e por rede.

Consola

Se estiver a usar a Google Cloud consola, pode esperar e criar a sub-rede apenas de proxy mais tarde na página Equilíbrio de carga.

Se quiser criar a sub-rede apenas de proxy agora, siga estes passos:

  1. Na Google Cloud consola, aceda à página Redes VPC.

    Aceda a redes de VPC

  2. Clique no nome da rede de VPC.
  3. No separador Sub-redes, clique em Adicionar sub-rede.
  4. Indique um nome para a sub-rede só de proxy.
  5. Na lista Região, selecione REGION_A.
  6. Na lista Finalidade, selecione Proxy gerido entre regiões.
  7. No campo Intervalo de endereços IP, introduza 10.129.0.0/23.
  8. Clique em Adicionar.

Crie a sub-rede só de proxy em REGION_B

  1. Clique em Adicionar sub-rede.
  2. Indique um nome para a sub-rede só de proxy.
  3. Na lista Região, selecione REGION_B.
  4. Na lista Finalidade, selecione Proxy gerido entre regiões.
  5. No campo Intervalo de endereços IP, introduza 10.130.0.0/23.
  6. Clique em Adicionar.

gcloud

Crie as sub-redes só de proxy com o comando gcloud compute networks subnets create.

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23
    
    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23

API

Crie as sub-redes só de proxy com o método subnetworks.insert, substituindo PROJECT_ID pelo ID do seu projeto.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": "PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   
    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }

Crie os NEGs sem servidor

  1. Crie um NEG sem servidor para o seu serviço do Cloud Run:

    gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-a \
   --region=REGION_A \
   --network-endpoint-type=serverless  \
   --cloud-run-service=CLOUD_RUN_SERVICE_NAMEA

    gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-b \
   --region=REGION_B \
   --network-endpoint-type=serverless  \
   --cloud-run-service=CLOUD_RUN_SERVICE_NAMEB

Configure o balanceador de carga

O tráfego que vai do balanceador de carga para os back-ends do NEG sem servidor usa rotas especiais definidas fora da sua VPC que não estão sujeitas a regras de firewall. Como tal, se o seu balanceador de carga tiver apenas back-ends de NEG sem servidor, não precisa de criar regras de firewall para permitir o tráfego da sub-rede só de proxy para o back-end sem servidor.

Consola

Selecione o tipo de balanceador de carga

  1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

    Aceda a Balanceamento de carga

  2. Clique em Criar equilibrador de carga.
  3. Em Tipo de balanceador de carga, selecione Balanceador de carga de aplicações (HTTP/HTTPS) e clique em Seguinte.
  4. Para Público ou interno, selecione Interno e clique em Seguinte.
  5. Para a Implementação em várias regiões ou numa única região, selecione Melhor para cargas de trabalho em várias regiões e clique em Seguinte.
  6. Clique em Configurar.

Configuração básica

  1. Indique um nome para o balanceador de carga.
  2. Para Rede, selecione NETWORK.

Configure o front-end com duas regras de encaminhamento

Para HTTP:

  1. Clique em Configuração do front-end.
    1. Indique um nome para a regra de encaminhamento.
    2. Na lista Região da sub-rede, selecione REGION_A.

      Reserve uma sub-rede só de proxy

    3. Na lista Sub-rede, selecione SUBNET_A.
    4. Na lista Endereço IP, clique em Criar endereço IP. É apresentada a página Reserve um endereço IP interno estático.
      • Indique um nome para o endereço IP estático.
      • Na lista Endereço IP estático, selecione Permitir-me escolher.
      • No campo Endereço IP personalizado, introduza 10.1.2.99.
      • Selecione Reservar.
  2. Clique em Concluído.
  3. Para adicionar a segunda regra de encaminhamento, clique em Adicionar IP e porta de front-end.
    1. Indique um nome para a regra de encaminhamento.
    2. Na lista Região da sub-rede, selecione REGION_B.

      Reserve uma sub-rede só de proxy

    3. Na lista Sub-rede, selecione SUBNET_B.
    4. Na lista Endereço IP, clique em Criar endereço IP. É apresentada a página Reserve um endereço IP interno estático.
      • Indique um nome para o endereço IP estático.
      • Na lista Endereço IP estático, selecione Permitir-me escolher.
      • No campo Endereço IP personalizado, introduza 10.1.3.99.
      • Selecione Reservar.
  4. Clique em Concluído.

Para HTTPS:

Para atribuir um certificado SSL ao proxy HTTPS de destino do equilibrador de carga, tem de usar um certificado do gestor de certificados.

  1. Clique em Configuração do front-end.
    1. Indique um nome para a regra de encaminhamento.
    2. No campo Protocolo, selecione HTTPS (includes HTTP/2).
    3. Certifique-se de que a Porta está definida como 443.
    4. Na lista Região da sub-rede, selecione REGION_A.

      Reserve uma sub-rede só de proxy

    5. Na lista Sub-rede, selecione SUBNET_A.
    6. Na lista Endereço IP, clique em Criar endereço IP. É apresentada a página Reserve um endereço IP interno estático.
      • Indique um nome para o endereço IP estático.
      • Na lista Endereço IP estático, selecione Permitir-me escolher.
      • No campo Endereço IP personalizado, introduza 10.1.3.99.
      • Selecione Reservar.
    7. Clique em Adicionar certificado para selecionar um certificado existente ou criar um novo.

      Se já tiver um certificado do Gestor de certificados para selecionar, faça o seguinte:

      1. Clique em Adicionar certificado.
      2. Clique em Selecionar um certificado existente e selecione o certificado na lista de certificados.
      3. Clique em Selecionar.

      Depois de selecionar o novo certificado do Gestor de certificados, este é apresentado na lista de certificados.

      Para criar um novo certificado do Gestor de certificados, faça o seguinte:

      1. Clique em Adicionar certificado.
      2. Clique em Criar um novo certificado.
      3. Para criar um novo certificado, siga os passos a partir do passo 3, conforme descrito num dos seguintes métodos de configuração na documentação do Gestor de certificados:
    8. Selecione uma política SSL na lista Política SSL. Se não tiver criado nenhuma política de SSL, é aplicada uma política de SSL predefinida Google Cloud .
    9. Clique em Concluído.

    Adicione a segunda configuração da interface:

    1. Indique um nome para a configuração do front-end.
    2. No campo Protocolo, selecione HTTPS (includes HTTP/2).
    3. Certifique-se de que a Porta está definida como 443.
    4. Na lista Região da sub-rede, selecione REGION_B.

      Reserve uma sub-rede só de proxy

    5. Na lista Sub-rede, selecione SUBNET_B.
    6. Na lista Endereço IP, clique em Criar endereço IP. É apresentada a página Reserve um endereço IP interno estático.
      • Indique um nome para o endereço IP estático.
      • Na lista Endereço IP estático, selecione Permitir-me escolher.
      • No campo Endereço IP personalizado, introduza 10.1.3.99.
      • Selecione Reservar.
    7. Clique em Adicionar certificado e, de seguida, selecione um certificado existente ou crie um novo certificado.
    8. Selecione uma política SSL na lista Política SSL. Se não tiver criado nenhuma política de SSL, é aplicada uma política de SSL predefinida Google Cloud .
    9. Clique em Concluído.
    Configure o serviço de back-end
    1. Clique em Configuração de back-end.
    2. Na lista Criar ou selecionar serviços de back-end, clique em Criar um serviço de back-end.
    3. Indique um nome para o serviço de back-end.
    4. Para Protocolo, selecione HTTP.
    5. Em Porta com nome, introduza http.
    6. Na lista Tipo de back-end, selecione Grupo de pontos finais da rede sem servidor.
    7. Na secção Novo back-end:
      1. Na lista Grupo de pontos finais da rede sem servidor, selecione gl7ilb-serverless-neg-a.
      2. Clique em Concluído.
      3. Para adicionar outro back-end, clique em Adicionar back-end.
      4. Na lista Grupo de pontos finais da rede sem servidor, selecione gl7ilb-serverless-neg-b.
      5. Clique em Concluído.

    Configure as regras de encaminhamento

    1. Clique em Regras de encaminhamento.
    2. Para Modo, selecione Regra de anfitrião e caminho simples.
    3. Certifique-se de que existe apenas um serviço de back-end para qualquer anfitrião não correspondente e qualquer caminho não correspondente.

    Reveja a configuração

    1. Clique em Rever e finalizar.
    2. Reveja as definições de configuração do equilibrador de carga.
    3. Clique em Criar.

gcloud

  1. Defina o serviço de back-end com o comando gcloud compute backend-services create.

    gcloud compute backend-services create gil7-backend-service \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --global

  2. Adicione back-ends ao serviço de back-end com o comando gcloud compute backend-services add-backend.

    gcloud compute backend-services add-backend gil7-backend-service \
  --network-endpoint-group=gl7ilb-serverless-neg-a \
  --network-endpoint-group-region=REGION_A \
  --global

    gcloud compute backend-services add-backend gil7-backend-service \
  --network-endpoint-group=gl7ilb-serverless-neg-b \
  --network-endpoint-group-region=REGION_B \
  --global

  3. Crie o mapa de URLs com o comando gcloud compute url-maps create.

    gcloud compute url-maps create gil7-map \
  --default-service=gil7-backend-service \
  --global

  4. Crie o proxy de destino.

    Para HTTP:

    Crie o proxy de destino com o comando gcloud compute target-http-proxies create.

    gcloud compute target-http-proxies create gil7-http-proxy \
  --url-map=gil7-map \
  --global

    Para HTTPS:

    Para criar um certificado gerido pela Google, consulte a seguinte documentação:

    Depois de criar o certificado gerido pela Google, anexe o certificado diretamente ao proxy de destino. Os mapas de certificados não são suportados por equilibradores de carga de aplicações internos entre regiões.

    Para criar um certificado autogerido, consulte a seguinte documentação:

    Atribua os caminhos dos ficheiros a nomes de variáveis.

    export LB_CERT=PATH_TO_PEM_FORMATTED_FILE

    export LB_PRIVATE_KEY=PATH_TO_LB_PRIVATE_KEY_FILE

    Crie um certificado SSL de todas as regiões com o comando gcloud certificate-manager certificates create.

    gcloud certificate-manager certificates create gilb-certificate \
  --private-key-file=$LB_PRIVATE_KEY \
  --certificate-file=$LB_CERT \
  –-scope=all-regions

    Use o certificado SSL para criar um proxy de destino com o comando gcloud compute target-https-proxies create

    gcloud compute target-https-proxies create gil7-https-proxy \
  --url-map=gil7-map \
  --certificate-manager-certificates=gilb-certificate

  5. Crie duas regras de encaminhamento: uma com um VIP (10.1.2.99) na região REGION_B e outra com um VIP (10.1.3.99) na região REGION_A.

    Para redes personalizadas, tem de fazer referência à sub-rede na regra de encaminhamento. Tenha em atenção que esta é a sub-rede da instância da máquina virtual (VM) e não a sub-rede do proxy.

    Para HTTP:

    Use o comando gcloud compute forwarding-rules create com as flags corretas.

    gcloud compute forwarding-rules create gil7-forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --subnet-region=REGION_B \
  --address=10.1.3.99 \
  --ports=80 \
  --target-http-proxy=gil7-http-proxy \
  --global

    gcloud compute forwarding-rules create gil7-forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --subnet-region=REGION_A \
  --address=10.1.2.99 \
  --ports=80 \
  --target-http-proxy=gil7-http-proxy \
  --global

    Para HTTPS:

    Crie a regra de encaminhamento com o comando gcloud compute forwarding-rules create com os sinalizadores corretos.

    gcloud compute forwarding-rules create gil7-forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --address=10.1.3.99 \
  --ports=443 \
  --target-https-proxy=gil7-https-proxy \
  --global

    gcloud compute forwarding-rules create gil7-forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --address=10.1.2.99 \
  --ports=443 \
  --target-https-proxy=gil7-https-proxy \
  --global

API

Crie o serviço de back-end global fazendo um pedido POST ao método backendServices.insert, substituindo PROJECT_ID pelo ID do seu projeto.

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

{
"name": "gil7-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl7ilb_serverless_negwest",
    "balancingMode": "UTILIZATION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl7ilb_serverless_negeast",
  }
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

Crie o mapa de URLs fazendo um pedido POST ao método urlMaps.insert, substituindo PROJECT_ID pelo ID do seu projeto.

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

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/global/backendServices/gil7-backend-service"
}

Para HTTP:

Crie o proxy HTTP de destino fazendo um pedido POST ao método targetHttpProxies.insert, substituindo PROJECT_ID pelo ID do seu projeto.

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

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

Crie a regra de encaminhamento fazendo um pedido POST ao método globalforwardingRules.insert, substituindo PROJECT_ID pelo ID do seu projeto.

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

{
"name": "gil7-forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

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

{
"name": "gil7-forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Para HTTPS:

Ler os ficheiros de certificado e chave privada e, em seguida, criar o certificado SSL. O exemplo seguinte mostra como o fazer com Python.

Crie o proxy HTTPS de destino fazendo um pedido POST ao método targetHttpsProxies.insert, substituindo PROJECT_ID pelo ID do seu projeto.

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

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map",
"sslCertificates": /projects/PROJECT_ID/global/sslCertificates/SSL_CERT_NAME
}

Crie a regra de encaminhamento fazendo um pedido POST ao método globalForwardingRules.insert, substituindo PROJECT_ID pelo ID do seu projeto.

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

{
"name": "gil7-forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

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

{
"name": "gil7-forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Teste o balanceador de carga

Agora que o serviço de equilíbrio de carga está em execução, pode enviar tráfego para a regra de encaminhamento e observar o tráfego a ser disperso para diferentes instâncias.

Configure a regra de firewall

Este exemplo requer a regra de firewall fw-allow-ssh para a VM do cliente de teste. fw-allow-ssh é uma regra de entrada aplicável à VM do cliente de teste e que permite a conetividade SSH de entrada na porta TCP 22 a partir de qualquer endereço. Pode escolher um intervalo de endereços IP de origem mais restritivo para esta regra. Por exemplo, pode especificar apenas os intervalos de endereços IP do sistema a partir do qual inicia sessões SSH. Este exemplo usa a etiqueta de destino allow-ssh.

gcloud

  1. Crie a regra de firewall fw-allow-ssh para permitir a conetividade SSH a VMs com a etiqueta de rede allow-ssh. Quando omite source-ranges, Google Cloud interpreta a regra como qualquer origem.

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

Crie uma instância de VM para testar a conetividade

  1. Crie uma VM de cliente:

    gcloud compute instances create l7-ilb-client-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_A \
    --zone=ZONE_A \
    --tags=allow-ssh

    gcloud compute instances create l7-ilb-client-b \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_B \
    --zone=ZONE_B \
    --tags=allow-ssh

  2. Ligue-se, através de SSH, a cada instância do cliente.

    gcloud compute ssh l7-ilb-client-a \
   --zone=ZONE_A

    gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B

  3. Verifique se o endereço IP está a publicar o respetivo nome do anfitrião.

    • Confirme se a VM do cliente consegue alcançar ambos os endereços IP. O comando é bem-sucedido e devolve o nome da VM de back-end que publicou o pedido:

      Para testes HTTP:

      curl 10.1.2.99

      curl 10.1.3.99

      Para testes HTTPS:

      curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:10.1.2.99:443

      curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:10.1.3.99:443

      Substitua DOMAIN_NAME pelo nome do domínio da sua aplicação, por exemplo, test.example.com.

      A flag -k faz com que o curl ignore a validação de certificados.

    • Opcional: use o registo DNS configurado para resolver o endereço IP.

      curl service.example.com

Execute 100 pedidos e confirme que têm o balanceamento de carga

Para HTTP:

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

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

Para HTTPS:

Substitua DOMAIN_NAME pelo nome do domínio da sua aplicação, por exemplo, test.example.com.

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

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

Teste de comutação por falha

  1. Validar a comutação por falha para back-ends na região REGION_A quando os back-ends nas regiões REGION_B não estão em bom estado ou estão inacessíveis. Simulamos isto removendo todos os back-ends de REGION_B:

    gcloud compute backend-services remove-backend gil7-backend-service \
   --network-endpoint-group=gl7ilb-serverless-neg-b \
   --network-endpoint-group-zone=ZONE_B

  2. Estabeleça ligação, através de SSH, a uma VM cliente em REGION_B.

    gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B

  3. Envie pedidos para o endereço IP com balanceamento de carga na região REGION_B. O resultado do comando apresenta respostas das VMs de back-end em REGION_A.

    Substitua DOMAIN_NAME pelo nome do domínio da sua aplicação, por exemplo, test.example.com.

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

Opções de configuração adicionais

Esta secção expande o exemplo de configuração para oferecer opções de configuração alternativas e adicionais. Todas as tarefas são opcionais. Pode realizá-las por qualquer ordem.

Usar uma máscara de URL

Quando cria um NEG sem servidor, em vez de selecionar um serviço do Cloud Run específico, pode usar uma máscara de URL para apontar para vários serviços publicados no mesmo domínio. Uma máscara de URL é um modelo do seu esquema de URL. O NEG sem servidor usa este modelo para extrair o nome do serviço do URL do pedido recebido e mapear o pedido para o serviço adequado.

As máscaras de URL são particularmente úteis se o seu serviço estiver mapeado para um domínio personalizado em vez do endereço predefinido que Google Cloud fornece para o serviço implementado. Uma máscara de URL permite-lhe segmentar vários serviços e versões com uma única regra, mesmo quando a sua aplicação está a usar um padrão de URL personalizado.

Se ainda não o fez, certifique-se de que lê a vista geral dos NEGS sem servidor: máscaras de URL.

Construa uma máscara de URL

Para criar uma máscara de URL para o seu equilibrador de carga, comece com o URL do seu serviço. Este exemplo usa uma app sem servidor de exemplo em execução em https://example.com/login. Este é o URL onde o serviço login da app é publicado.

  1. Remova o http ou o https do URL. Tem example.com/login.
  2. Substitua o nome do serviço por um marcador de posição para a máscara de URL.
    • Cloud Run: substitua o nome do serviço do Cloud Run pelo marcador de posição <service>. Se o serviço do Cloud Run tiver uma etiqueta associada, substitua o nome da etiqueta pelo marcador de posição <tag>. Neste exemplo, a máscara de URL que lhe resta é example.com/<service>.

  3. Opcional: se for possível extrair o nome do serviço da parte do caminho do URL, o domínio pode ser omitido. A parte do caminho da máscara de URL distingue-se pelo primeiro caráter de barra (/). Se não estiver presente uma barra (/) na máscara de URL, entende-se que a máscara representa apenas o anfitrião. Por conseguinte, para este exemplo, a máscara de URL pode ser reduzida a /<service>.

    Da mesma forma, se for possível extrair <service> da parte do anfitrião do URL, pode omitir completamente o caminho da máscara de URL.

    Também pode omitir quaisquer componentes de anfitrião ou subdomínio que venham antes do primeiro marcador de posição, bem como quaisquer componentes de caminho que venham depois do último marcador de posição. Nestes casos, o marcador de posição captura as informações necessárias para o componente.

Seguem-se mais alguns exemplos que demonstram estas regras:

Esta tabela pressupõe que tem um domínio personalizado denominado example.com e que todos os seus serviços do Cloud Run estão a ser mapeados para este domínio.

Serviço, nome da etiqueta URL de domínio personalizado do Cloud Run Máscara de URL
service: login https://login-home.example.com/web <service>-home.example.com
service: login https://example.com/login/web example.com/<service> ou /<service>
service: login, tag: test https://test.login.example.com/web <tag>.<service>.example.com
service: login, tag: test https://example.com/home/login/test example.com/home/<service>/<tag> ou /home/<service>/<tag>
service: login, tag: test https://test.example.com/home/login/web <tag>.example.com/home/<service>

Criar um NEG sem servidor com uma máscara de URL

Consola

Para um novo equilibrador de carga, pode usar o mesmo processo completo, conforme descrito anteriormente neste documento. Quando configurar o serviço de back-end, em vez de selecionar um serviço específico, introduza uma máscara de URL.

Se tiver um balanceador de carga existente, pode editar a configuração do back-end e fazer com que o NEG sem servidor aponte para uma máscara de URL em vez de um serviço específico.

Para adicionar um NEG sem servidor baseado em máscara de URL a um serviço de back-end existente, faça o seguinte:

  1. Na Google Cloud consola, aceda à página Equilíbrio de carga.
    Aceder a Balanceamento de carga
  2. Clique no nome do equilibrador de carga que tem o serviço de back-end que quer editar.
  3. Na página Detalhes do equilibrador de carga, clique em Editar.
  4. Na página Editar balanceador de carga de aplicações externo global, clique em Configuração do back-end.
  5. Na página Configuração de back-end, clique em Editar para o serviço de back-end que quer modificar.
  6. Clique em Adicionar back-end.
  7. Selecione Criar grupo de pontos finais de rede sem servidor.
    1. No campo Nome, introduza helloworld-serverless-neg.
    2. Em Região, é apresentada a região do balanceador de carga.
    3. Em Tipo de grupo de pontos finais de rede sem servidor, o Cloud Run é o único tipo de grupo de pontos finais de rede suportado.
      1. Selecione Usar máscara de URL.
      2. Introduza uma máscara de URL. Para obter informações sobre como criar uma máscara de URL, consulte o artigo Construir uma máscara de URL.
      3. Clique em Criar.

  8. No novo back-end, clique em Concluído.
  9. Clique em Atualizar.

gcloud

Para criar um NEG sem servidor com uma máscara de URL de exemplo de example.com/<service>:

gcloud compute network-endpoint-groups create SERVERLESS_NEG_MASK_NAME \
    --region=REGION \
    --network-endpoint-type=serverless \
    --cloud-run-url-mask="example.com/<service>"

Use o mesmo endereço IP entre várias regras de encaminhamento interno

Para que várias regras de encaminhamento interno partilhem o mesmo endereço IP interno, tem de reservar o endereço IP e definir a respetiva flag --purpose como SHARED_LOADBALANCER_VIP.

gcloud 

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP
Se precisar de redirecionar o tráfego HTTP para HTTPS, pode criar duas regras de encaminhamento que usem um endereço IP comum. Para mais informações, consulte o artigo Configure o redirecionamento de HTTP para HTTPS para balanceadores de carga de aplicações internos.

Configure políticas de encaminhamento de DNS

Se os seus clientes estiverem em várias regiões, pode tornar o balanceador de carga de aplicações interno entre regiões acessível através de VIPs nestas regiões. Pode usar políticas de encaminhamento de DNS do tipo GEO para encaminhar o tráfego de clientes para o VIP do balanceador de carga na região mais próxima do cliente. Esta configuração de várias regiões minimiza a latência e os custos de trânsito de rede. Além disso, permite-lhe configurar uma solução de balanceamento de carga global baseada em DNS que oferece resiliência contra interrupções regionais.

O Cloud DNS suporta a verificação de estado e permite a comutação automática em caso de falha quando os pontos finais falham as respetivas verificações de estado. Durante uma ativação pós-falha, o Cloud DNS ajusta automaticamente a divisão do tráfego entre os pontos finais saudáveis restantes. Para mais informações, consulte o artigo Faça a gestão das políticas de encaminhamento de DNS e das verificações de estado.

gcloud

Para criar uma entrada DNS com um TTL de 30 segundos, use o comando gcloud dns record-sets create.

gcloud dns record-sets create DNS_ENTRY --ttl="30" \
  --type="A" --zone="service-zone" \
  --routing-policy-type="GEO" \
  --routing-policy-data="REGION_A=gil7-forwarding-rule-a@global;REGION_B=gil7-forwarding-rule-b@global" \
  --enable-health-checking

Substitua o seguinte:

  • DNS_ENTRY: DNS ou nome de domínio do conjunto de registos

    Por exemplo, service.example.com

  • REGION_A e REGION_B: as regiões onde configurou o balanceador de carga

API

Crie o registo DNS fazendo um pedido POST ao método.ResourceRecordSets.create Substitua PROJECT_ID pelo ID do seu projeto.

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/SERVICE_ZONE/rrsets
{
  "name": "DNS_ENTRY",
  "type": "A",
  "ttl": 30,
  "routingPolicy": {
    "geo": {
      "items": [
        {
          "location": "REGION_A",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        },
        {
          "location": "REGION_B",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS_B",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        }
      ]
    }
  }
}

Ative a deteção de valores atípicos

Pode ativar a deteção de valores outliers em serviços de back-end globais para identificar NEGs sem servidor não íntegros e reduzir o número de pedidos enviados para os NEGs sem servidor não íntegros.

A deteção de valores atípicos é ativada no serviço de back-end através de um dos seguintes métodos:

  • O método consecutiveErrors (outlierDetection.consecutiveErrors), no qual um código de estado HTTP da série 5xx é considerado um erro.
  • O método consecutiveGatewayFailure(outlierDetection.consecutiveGatewayFailure), no qual apenas os códigos de estado HTTP 502, 503 e 504 se qualificam como um erro.

Siga estes passos para ativar a deteção de valores atípicos para um serviço de back-end existente. Tenha em atenção que, mesmo depois de ativar a deteção de valores atípicos, alguns pedidos podem ser enviados para o serviço não saudável e devolver um código de estado 5xx aos clientes. Para reduzir ainda mais a taxa de erro, pode configurar valores mais agressivos para os parâmetros de deteção de valores atípicos. Para mais informações, consulte o campo outlierDetection.

Consola

  1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

    Aceda a Balanceamento de carga

  2. Clique no nome do balanceador de carga cujo serviço de back-end quer editar.

  3. Na página Detalhes do equilibrador de carga, clique em Editar.

  4. Na página Editar Application Load Balancer interno entre regiões, clique em Configuração do back-end.

  5. Na página Configuração de back-end, clique em Editar para o serviço de back-end que quer modificar.

  6. Desloque a página para baixo e expanda a secção Configurações avançadas.

  7. Na secção Deteção de valores atípicos, selecione a caixa de verificação Ativar.

  8. Clique em Editar para configurar a deteção de valores atípicos.

    Verifique se as seguintes opções estão configuradas com estes valores:

    Propriedade Valor
    Erros consecutivos 5
    Intervalo 1000
    Tempo de ejeção base 30000
    Percentagem máxima de rejeição 50
    Aplicação de erros consecutivos 100

    Neste exemplo, a análise de deteção de valores atípicos é executada a cada segundo. Se o número de códigos de estado HTTP consecutivos recebidos por um proxy do Envoy for igual ou superior a cinco, o ponto final de back-end é rejeitado do conjunto de equilíbrio de carga desse proxy do Envoy durante 30 segundos.5xx Quando a percentagem de aplicação é definida como 100%, o serviço de back-end aplica a rejeição de pontos finais não íntegros dos conjuntos de equilíbrio de carga desses proxies Envoy específicos sempre que a análise de deteção de valores atípicos é executada. Se as condições de rejeição forem cumpridas, é possível rejeitar até 50% dos pontos finais de back-end do conjunto de equilíbrio de carga.

  9. Clique em Guardar.

  10. Para atualizar o serviço de back-end, clique em Atualizar.

  11. Para atualizar o balanceador de carga, na página Editar balanceador de carga de aplicações interno entre regiões, clique em Atualizar.

gcloud

  1. Exporte o serviço de back-end para um ficheiro YAML.

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
  --destination=BACKEND_SERVICE_NAME.yaml --global

    Substitua BACKEND_SERVICE_NAME pelo nome do serviço de back-end.

  2. Edite a configuração YAML do serviço de back-end para adicionar os campos de deteção de valores atípicos, conforme realçado na seguinte configuração YAML, na secção outlierDetection:

    Neste exemplo, a análise de deteção de valores atípicos é executada a cada segundo. Se o número de códigos de estado HTTP consecutivos recebidos por um proxy do Envoy for igual ou superior a cinco, o ponto final de back-end é rejeitado do conjunto de equilíbrio de carga desse proxy do Envoy durante 30 segundos.5xx Quando a percentagem de aplicação é definida como 100%, o serviço de back-end aplica a rejeição de pontos finais não íntegros dos conjuntos de equilíbrio de carga desses proxies Envoy específicos sempre que a análise de deteção de valores atípicos é executada. Se as condições de rejeição forem cumpridas, é possível rejeitar até 50% dos pontos finais de back-end do conjunto de equilíbrio de carga. 

    name: BACKEND_SERVICE_NAME
backends:
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2
outlierDetection:
  baseEjectionTime:
    nanos: 0
    seconds: 30
  consecutiveErrors: 5
  enforcingConsecutiveErrors: 100
  interval:
    nanos: 0
    seconds: 1
  maxEjectionPercent: 50
port: 80
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME
sessionAffinity: NONE
timeoutSec: 30
...

    Substitua o seguinte:

    • BACKEND_SERVICE_NAME: o nome do serviço de back-end
    • PROJECT_ID: o ID do seu projeto
    • REGION_A e REGION_B: as regiões onde o balanceador de carga foi configurado.
    • SERVERLESS_NEG_NAME: o nome do primeiro NEG sem servidor
    • SERVERLESS_NEG_NAME_2: o nome do segundo NEG sem servidor

  3. Atualize o serviço de back-end importando a configuração mais recente.

    gcloud compute backend-services import BACKEND_SERVICE_NAME \
  --source=BACKEND_SERVICE_NAME.yaml --global

    A deteção de valores atípicos está agora ativada no serviço de back-end.

Eliminar um NEG sem servidor

Não é possível eliminar um grupo de pontos finais de rede se estiver anexado a um serviço de back-end. Antes de eliminar um NEG, certifique-se de que está desvinculado do serviço de back-end.

Consola

  1. Para se certificar de que o NEG sem servidor que quer eliminar não está a ser usado por nenhum serviço de back-end, aceda ao separador Serviços de back-end na página Componentes de equilíbrio de carga.
    Aceda aos serviços de back-end
  2. Se o NEG sem servidor estiver em utilização, faça o seguinte:
    1. Clique no nome do serviço de back-end que está a usar o NEG sem servidor.
    2. Clique em Editar.
    3. Na lista de Back-ends, clique em para remover o back-end do NEG sem servidor do serviço de back-end.
    4. Clique em Guardar.

  3. Aceda à página Grupo de pontos finais de rede na Google Cloud consola.
    Aceda a Grupo de pontos finais da rede
  4. Selecione a caixa de verificação do NEG sem servidor que quer eliminar.
  5. Clique em Eliminar.
  6. Clique novamente em Eliminar para confirmar.

gcloud

Para remover um NEG sem servidor de um serviço de back-end, tem de especificar a região onde o NEG foi criado.

gcloud compute backend-services remove-backend BACKEND_SERVICE_NAME \
    --network-endpoint-group=SERVERLESS_NEG_NAME \
    --network-endpoint-group-region=REGION \
    --region=REGION

Para eliminar o NEG sem servidor:

gcloud compute network-endpoint-groups delete SERVERLESS_NEG_NAME \
    --region=REGION

O que se segue?