Configure um balanceador de carga de aplicativo interno entre regiões com o Cloud Run

Neste documento, mostramos como implantar um balanceador de carga de aplicativo interno entre regiões com o Cloud Run. Para configurar isso, use um back-end NEG sem servidor para o balanceador de carga.

Os NEGs sem servidor permitem usar os serviços do Cloud Run com o balanceador de carga. Depois de configurar um balanceador de carga com o back-end NEG sem servidor, as solicitações para o balanceador de carga são roteadas para o back-end do aplicativo sem servidor.

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

  • Se os serviços multirregionais do Cloud Run estiverem configurados na mesma região que o Envoy, será preferível usar o NEG localizado na mesma região do Envoy. O tráfego será enviado para a região de failover somente se a detecção de outliers estiver ativada e o NEG local não estiver íntegro.
  • Se os serviços multirregionais do Cloud Run não estiverem configurados na mesma região que o Envoy, o tráfego será distribuído uniformemente por todos os NEGs. Os NEGs localizados mais perto não são preferidos.
  • Se o Identity-Aware Proxy estiver ativado, apenas um NEG sem servidor será compatível. No entanto, é possível configurar outros serviços do Cloud Run, mas o balanceador de carga não envia tráfego para eles.

Antes de começar

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

Implantar um serviço do Cloud Run

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

Para o exemplo nesta página, é possível usar qualquer um dos guias de início rápido do Cloud Run para implantar um serviço do Cloud Run.

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

Colocar o serviço do Cloud Run em várias regiões ajuda a evitar falhas em uma única região. Para implantar 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

Anote o nome do serviço que você criar. No restante desta página, mostramos como configurar um balanceador de carga que encaminha solicitações para esse serviço.

Configurar um recurso de certificado SSL

Crie um recurso de certificado SSL do Gerenciador de certificados da seguinte maneira:

Recomendamos o uso de um certificado gerenciado pelo Google.

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 o balanceador de carga de aplicativo interno entre regiões conforme descrito no diagrama a seguir:

Balanceador de carga de aplicativo interno entre regiões com implantação do Cloud Run.
Balanceador de carga de aplicativo interno entre regiões com implantação do Cloud Run (clique para ampliar).

Como mostrado no diagrama, este exemplo cria um balanceador de carga de aplicativo interno entre regiões em uma rede VPC, com um serviço de back-end e duas implantações do Cloud Run em REGION_A e nas regiões REGION_B.

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

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

    • Sub-rede SUBNET_A e uma sub-rede somente proxy em REGION_A.
    • Sub-rede SUBNET_B e uma sub-rede somente proxy em REGION_B.

    É preciso criar sub-redes somente proxy em todas as regiões de uma rede VPC em que você usa balanceadores de carga de aplicativo internos entre regiões. A sub-rede somente proxy da região é compartilhada com todos os balanceadores de carga de aplicativo internos entre regiões que estão na região. Os endereços de origem dos pacotes enviados dos balanceadores de carga para os back-ends do serviço são alocados por meio da sub-rede somente proxy. Neste exemplo, a sub-rede somente proxy da região REGION_A tem um intervalo de endereços IP primário 10.129.0.0/23. A região REGION_B tem um intervalo de endereços IP primário 10.130.0.0/23, que é o tamanho de sub-rede recomendado.

  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 e 10.130.0.0/23 (o intervalo da sub-rede somente proxy neste exemplo).

  3. Outra regra de firewall para as sondagens de verificação de integridade.

  4. Uma configuração de alta disponibilidade com back-ends sem servidor para implantações do Cloud Run em regiões REGION_A e REGION_B. Se os back-ends de uma região ficarem inativos, o tráfego fará o failover para a outra região.

  5. Um serviço de back-end global que monitora o uso e a integridade dos back-ends. Ative a detecção de outliers no serviço de back-end.

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

  7. Um proxy HTTP ou HTTPS de destino global, que recebe uma solicitação do usuário e a encaminha para o 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.

  8. Regras de encaminhamento global, que têm 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 GLOBAL_MANAGED_PROXY.
    • Se você quiser usar o mesmo endereço IP interno com várias regras de encaminhamento, defina a sinalização --purpose do endereço IP como SHARED_LOADBALANCER_VIP.

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

Configurar a rede e as sub-redes

Na rede VPC, configure uma sub-rede em cada região em que os back-ends estão configurados. Além disso, configure um proxy-only-subnet em cada região em que você quer configurar o balanceador de carga.

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

  • Rede. Uma rede VPC de modo personalizado denominada NETWORK.

  • Sub-redes para back-ends. uma sub-rede chamada SUBNET_A na região REGION_A usa 10.1.2.0/24 para o intervalo de IP primário. uma sub-rede chamada SUBNET_A na região REGION_B usa 10.1.3.0/24 para o intervalo de IP primário.

  • Sub-rede para proxies. uma sub-rede chamada PROXY_SN_A na região REGION_A usa 10.129.0.0/23 para o intervalo de IP primário. uma sub-rede chamada PROXY_SN_B na região REGION_B usa 10.130.0.0/23 para o intervalo de IP primário.

Os balanceadores de carga de aplicativo internos entre regiões podem ser acessados de qualquer região dentro da VPC. Assim, clientes de qualquer região podem acessar globalmente os back-ends do balanceador de carga.

Configurar as sub-redes de back-end

Console

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

    Acessar redes VPC

  2. Clique em Criar rede VPC.

  3. Atribua um Nome à rede.

  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:

    • Forneça um Nome para a sub-rede.
    • Selecione uma Região: REGION_A
    • Digite um Intervalo de endereço IP: 10.1.2.0/24

  6. Clique em Concluído.

  7. Clique em Add subnet.

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

    • Forneça um Nome para a sub-rede.
    • Selecione uma Região: REGION_B
    • Digite um Intervalo de endereço 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 rede NETWORK 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 rede NETWORK 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 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": "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/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 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/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",
}

Configurar a sub-rede somente proxy

Uma sub-rede somente proxy fornece um conjunto de endereços IP que o Google Cloud usa para executar proxies Envoy em seu nome. Os proxies encerram as conexões do cliente e criam novas conexões com os back-ends.

Essa sub-rede somente proxy é usada por todos os balanceadores de carga regionais baseados no Envoy que estão na mesma região que a rede VPC. Só pode haver uma sub-rede somente proxy ativa para uma determinada finalidade, por região e por rede.

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.
  3. Na guia Sub-redes, clique em Adicionar sub-rede.
  4. Forneça um Nome para a sub-rede somente proxy.
  5. Na lista Região, selecione REGION_A.
  6. Na lista Finalidade, selecione Proxy gerenciado entre regiões.
  7. No campo Intervalo de endereços IP, insira 10.129.0.0/23.
  8. Clique em Adicionar.

Crie a sub-rede somente proxy em REGION_B

  1. Clique em Add subnet.
  2. Forneça um Nome para a sub-rede somente proxy.
  3. Na lista Região, selecione REGION_B.
  4. Na lista Finalidade, selecione Proxy gerenciado entre regiões.
  5. No campo Intervalo de endereços IP, insira 10.130.0.0/23.
  6. Clique em Adicionar.

gcloud

Crie a sub-rede somente 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 somente proxy com o método subnetworks.insert, substituindo PROJECT_ID pelo ID do 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"
    }

Criar os NEGs sem servidor

  1. Crie um NEG sem servidor para 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

Configurar o balanceador de carga

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

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 entre regiões e clique em Próxima.
  6. Clique em Configurar.

Configuração básica

  1. Dê um Nome para o balanceador de carga.
  2. Em Rede, selecione NETWORK.

Configure o front-end com duas regras de encaminhamento

Para HTTP:

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

      Reservar uma sub-rede somente proxy

    3. Na lista Sub-rede, selecione SUBNET_A.
    4. Na lista de Endereços IP, clique em Criar endereço IP. A página Reservar um endereço IP interno estático é aberta.
      • Forneça um Nome para o endereço IP estático.
      • Na lista Endereço IP estático, selecione Quero escolher.
      • No campo Endereço IP, digite 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 do front-end.
    1. Dê um Nome para a regra de encaminhamento.
    2. Na lista Região da sub-rede, selecione REGION_B.

      Reservar uma sub-rede somente proxy

    3. Na lista Sub-rede, selecione SUBNET_B.
    4. Na lista de Endereços IP, clique em Criar endereço IP. A página Reservar um endereço IP interno estático é aberta.
      • Forneça um Nome para o endereço IP estático.
      • Na lista Endereço IP estático, selecione Quero escolher.
      • No campo Endereço IP, digite 10.1.3.99.
      • Selecione Reservar.
  4. Clique em Concluído.

Para HTTPS:

Se você usa o HTTPS entre o cliente e o balanceador de carga, um ou mais recursos de certificado SSL serão necessários para configurar o proxy. Para criar um all-regions certificado gerenciado pelo Google, consulte a seguinte documentação:

Depois de criar o certificado gerenciado pelo Google, anexe-o diretamente ao proxy de destino. Os mapas de certificado não são suportados por balanceadores de carga de aplicativo internos entre regiões.

Para criar um certificado autogerenciado all-regions, consulte a seguinte documentação: Implantar um certificado autogerenciado regional.

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

      Reservar uma sub-rede somente proxy

    5. Na lista Sub-rede, selecione SUBNET_A.
    6. Na lista de Endereços IP, clique em Criar endereço IP. A página Reservar um endereço IP interno estático é aberta.
      • Forneça um Nome para o endereço IP estático.
      • Na lista Endereço IP estático, selecione Quero escolher.
      • No campo Endereço IP, digite 10.1.3.99.
      • Selecione Reservar.
    7. Na seção Adicionar certificado, selecione o certificado.
    8. Opcional: para adicionar certificados além do certificado SSL principal:
      1. Clique em Adicionar certificado.
      2. Selecione o certificado na lista.
    9. Selecione uma política de SSL na lista Política de SSL. Se você não tiver criado políticas SSL, uma política padrão do Google Cloud SSL será aplicada.
    10. Clique em Concluído.

    Adicione a segunda configuração de front-end:

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

      Reservar uma sub-rede somente proxy

    5. Na lista Sub-rede, selecione SUBNET_B.
    6. Na lista de Endereços IP, clique em Criar endereço IP. A página Reservar um endereço IP interno estático é aberta.
      • Forneça um Nome para o endereço IP estático.
      • Na lista Endereço IP estático, selecione Quero escolher.
      • No campo Endereço IP, digite 10.1.3.99.
      • Selecione Reservar.
    7. Na seção Adicionar certificado, selecione o certificado.
    8. Opcional: para adicionar certificados além do certificado SSL principal:
      1. Clique em Adicionar certificado.
      2. Selecione o certificado na lista.
    9. Selecione uma política de SSL na lista Política de SSL. Se você não tiver criado políticas SSL, uma política padrão do Google Cloud SSL será aplicada.
    10. Clique em Concluído.
    Configurar 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. Forneça um Nome para o serviço de back-end.
    4. Em Protocolo, selecione HTTP.
    5. Em Porta nomeada, insira http.
    6. Na lista Tipo de back-end, selecione Grupo de endpoints de rede sem servidor.
    7. Na seção Novo back-end:
      • Na lista Grupo de endpoints de rede sem servidor, selecione gl7ilb-serverless-neg-a.
      • Clique em Concluído.
      • Para adicionar outro back-end, clique em Adicionar back-end.
      • Na lista Grupo de endpoints de rede sem servidor, selecione gl7ilb-serverless-neg-b.
      • Clique em Concluído.

    Configurar as regras de roteamento

    1. Clique em Regras de roteamento.
    2. Em Modo, selecione Regra de host e caminho simples.
    3. Verifique se há apenas um serviço de back-end para qualquer host e caminho sem correspondência.

    Analise a configuração

    1. Clique em Analisar e finalizar.
    2. Revise suas configurações do balanceador 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 URL 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 gerenciado pelo Google, consulte a seguinte documentação:

    Depois de criar o certificado gerenciado pelo Google, anexe-o diretamente ao proxy de destino. Os mapas de certificado não são suportados por balanceadores de carga de aplicativo internos entre regiões.

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

    Atribua os caminhos de arquivo aos 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 para todas as regiões usando 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 regional 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, referencie a sub-rede na regra de encaminhamento. Observe que essa é a sub-rede da instância da máquina virtual (VM), não a sub-rede proxy.

    Para HTTP:

    Use o comando gcloud compute forwarding-rules create com as sinalizações 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 usando o comando gcloud compute forwarding-rules create com as sinalizações corretas.

    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 regional fazendo uma solicitação POST ao método backendServices.insert, substituindo PROJECT_ID pelo ID do 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 URL fazendo uma solicitação POST ao método urlMaps.insert, substituindo PROJECT_ID pelo ID do 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 uma solicitação POST ao método targetHttpProxies.insert, substituindo PROJECT_ID pelo ID do 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 uma solicitação POST ao método globalforwardingRules.insert, substituindo PROJECT_ID pelo ID do 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:

Leia os arquivos do certificado e da chave privada e crie o certificado SSL. O exemplo a seguir mostra como fazer isso com Python.

Crie o proxy HTTPS de destino fazendo uma solicitação POST ao método targetHttpsProxies.insert, substituindo PROJECT_ID pelo ID do 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 uma solicitação POST ao método globalForwardingRules.insert, substituindo PROJECT_ID pelo ID do 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"
}

Testar o balanceador de carga

Agora que o serviço de balanceamento de carga está em execução, é possível enviar o tráfego para a regra de encaminhamento e observar como ele será distribuído em várias 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 de cliente de teste e que permite a conectividade SSH de entrada na porta TCP 22 vindo de qualquer endereço. Escolha um intervalo de endereço IP de origem mais restritivo para esta regra. Por exemplo, é possível especificar apenas os intervalos de IP do sistema a partir do qual você inicia sessões SSH. Neste exemplo, usamos a tag de destino allow-ssh.

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=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

Criar uma instância de VM para testar a conectividade

  1. Crie uma VM 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. Conectar-se via 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á exibindo o nome do host.

    • Verifique se a VM cliente pode acessar os dois endereços IP. O comando é bem-sucedido e retorna o nome da VM de back-end que veiculou a solicitação:

      curl 10.1.2.99

      curl 10.1.3.99

      Para fazer teste em HTTPS, substitua curl por:

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

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

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

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

      curl service.example.com

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

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:

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

  {
    RESULTS=
    for i in {1..100}
    do
        RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.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
  }

Testar o failover

  1. Verifique o failover para back-ends na região REGION_A quando os back-ends nas regiões REGION_B não estiverem íntegros ou acessíveis. Simule isso 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. Conecte-se usando SSH a uma VM cliente em REGION_B.

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

  3. Envie solicitações ao endereço IP com carga balanceada na região REGION_B. A resposta ao comando mostra as respostas das VMs de back-end em REGION_A:

    {
RESULTS=
for i in {1..100}
do
  RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.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
}

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.

Como usar uma máscara de URL

Ao criar um NEG sem servidor, em vez de selecionar um serviço específico do Cloud Run (totalmente gerenciado), é possível usar uma máscara de URL para apontar para vários serviços exibidos no mesmo domínio. Uma máscara de URL é um modelo do esquema de URL. O NEG sem servidor usa esse modelo para extrair o nome do serviço do URL da solicitação recebida e mapear a solicitação para o serviço apropriado.

As máscaras de URL são particularmente úteis se o serviço estiver mapeado para um domínio personalizado em vez do endereço padrão fornecido pelo Google Cloud para o serviço implantado. Uma máscara de URL permite segmentar vários serviços e versões com uma única regra, mesmo quando seu aplicativo usa um padrão do URL personalizado.

Se você ainda não tiver feito isso, leia Visão geral do NEGS sem servidor: máscaras de URL.

Criar uma máscara de URL

Para criar uma máscara de URL para o balanceador de carga, comece com o URL do serviço. Este exemplo usa um aplicativo de amostra sem servidor em execução em https://example.com/login. Esse é o URL em que o serviço login do app é exibido.

  1. Remova o http ou o https do URL. Você ainda tem example.com/login.
  2. Substitua o nome do serviço por um marcador para a máscara de URL.
    • Cloud Run: substitua o nome do serviço do Cloud Run pelo marcador <service>. Se o serviço do Cloud Run (totalmente gerenciado) tiver uma tag associada a ele, substitua o nome da tag pelo marcador <tag>. Neste exemplo, a máscara de URL restante é example.com/<service>.

  3. Opcional: se o nome do serviço puder ser extraído da parte do caminho do URL, o domínio poderá ser omitido. A parte do caminho da máscara de URL é diferenciada pelo primeiro caractere de barra (/). Se uma barra (/) não estiver presente na máscara de URL, a máscara será entendida para representar apenas o host. Portanto, para este exemplo, a máscara de URL pode ser reduzida para /<service>.

    Da mesma forma, se <service> puder ser extraído da parte do host do URL, será possível omitir o caminho completamente da máscara de URL.

    Também é possível omitir todos os componentes de host ou subdomínio que vêm antes do primeiro marcador, bem como qualquer componente de caminho que vem depois do último marcador. Nesses casos, o marcador captura as informações necessárias para o componente.

Veja mais alguns exemplos que demonstram essas regras:

Nesta tabela, pressupomos que você tenha um domínio personalizado chamado example.com e que todos os serviços do Cloud Run estejam sendo mapeados para esse domínio.

Serviço, nome da tag URL de domínio personalizado do Cloud Run Máscara de URL
serviço: login https://login-home.example.com/web <service>-home.example.com
serviço: 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>

Como criar um NEG sem servidor com uma máscara de URL

Console

Para um novo balanceador de carga, é possível usar o mesmo processo completo conforme descrito anteriormente neste documento. Ao configurar o serviço de back-end, em vez de selecionar um serviço específico, insira uma máscara de URL.

Se você tiver um balanceador de carga, poderá editar a configuração do back-end e fazer com que o ponto de NEG sem servidor acesse 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, faça o seguinte:

  1. No Console do Google Cloud, acesse a página Balanceamento de carga.
    Acesse "Balanceamento de carga"
  2. Clique no nome do balanceador de carga que tem o serviço de back-end que você quer editar.
  3. Na página Detalhes do balanceador de carga, clique em Editar.
  4. Na página Editar balanceador de carga externo do aplicativo global, clique em Configuração de back-end.
  5. Na página Configuração de back-end, clique em Editar no serviço de back-end que você quer modificar.
  6. Clique em Adicionar back-end.
  7. Selecione Criar grupo de endpoints da rede sem servidor.
    1. Em Nome, insira helloworld-serverless-neg.
    2. Em Região, a região do balanceador de carga é exibida.
    3. Em Tipo de grupo de endpoints de rede sem servidor, o Cloud Run é o único tipo de grupo de endpoints de rede compatível.
      1. Selecione Usar máscara de URL.
      2. Insira uma máscara de URL. Para informações sobre como criar uma máscara de URL, consulte Como criar uma máscara de URL.
      3. Clique em Criar.

  8. Em 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 amostra 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>"

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.

Configurar políticas de roteamento de DNS

Se os clientes estiverem em várias regiões, convém tornar o balanceador de carga de aplicativo interno entre regiões acessível por meio de VIPs nessas regiões. Essa configuração multirregional minimiza os custos de latência e trânsito de rede. Além disso, é possível configurar uma solução de balanceamento de carga global baseada em DNS que oferece resiliência contra interrupções regionais. Para mais informações, consulte Gerenciar políticas de roteamento de DNS e verificações de integridade.

gcloud

Para criar uma entrada de 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:

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

    Por exemplo, service.example.com.

  • REGION_A e REGION_B: as regiões em que o balanceador de carga foi configurado.

API

Crie o registro DNS fazendo uma solicitação POST ao método ResourceRecordSets.create. Substitua PROJECT_ID pelo ID do 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"
              }
            ]
          }
        }
      ]
    }
  }
}

Ativar detecção de outliers

É possível ativar a detecção de outliers em serviços de back-end globais para identificar NEGs sem servidor não íntegros e reduzir o número de solicitações enviadas aos NEGs sem servidor não íntegros.

A detecção de outliers é ativada no serviço de back-end usando um dos seguintes métodos:

  • O método consecutiveErrors (outlierDetection.consecutiveErrors), em que um código de status HTTP da série 5xx se qualifica como erro.
  • O método consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), em que apenas os códigos de status HTTP 502, 503 e 504 se qualificam como erros.

Use as etapas a seguir para ativar a detecção de outliers para um serviço de back-end existente. Observe que, mesmo depois de ativar a detecção de outliers, algumas solicitações podem ser enviadas para o serviço não íntegro e retornar um código de status 5xx aos clientes. Para reduzir ainda mais a taxa de erro, configure valores mais agressivos nos parâmetros de detecção de outliers. Para mais informações, consulte o campo outlierDetection.

Console

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

    Acessar o "Balanceamento de carga"

  2. Clique no nome do balanceador de carga em que está o serviço de back-end a ser editado.

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

  4. Na página Editar balanceador de carga de aplicativo interno entre regiões, clique em Configuração de back-end.

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

  6. Role para baixo e expanda a seção Advanced Configurations.

  7. Na seção Detecção de outliers, marque a caixa de seleção Ativar.

  8. Clique em Editar para configurar a detecção de outliers.

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

    Propriedade Valor
    Erros consecutivos 5
    Interval 1000
    Tempo base de expulsão 30000
    Percentual máximo de expulsão 50
    Como aplicar erros consecutivos 100

    Neste exemplo, a análise de detecção de outliers é executada a cada segundo. Se o número de código de status HTTP 5xx consecutivos recebidos por um proxy Envoy for cinco ou mais, o endpoint de back-end será removido do pool de balanceamento de carga desse proxy Envoy por 30 segundos. Quando a porcentagem de aplicação é definida em 100%, o serviço de back-end aplica a remoção de endpoints não íntegros dos pools de balanceamento de carga desses proxies Envoy específicos sempre que a análise de detecção de outliers é executada. Se as condições de remoção forem atendidas, até 50% dos endpoints de back-end do pool de balanceamento de carga poderão ser removidos.

  9. Clique em Salvar.

  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 aplicativo interno entre regiões, clique em Atualizar.

gcloud

  1. Exporte o serviço de back-end para um arquivo 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 detecção de outliers conforme destacado na seguinte configuração YAML, na seção outlierDetection:

    Neste exemplo, a análise de detecção de outliers é executada a cada segundo. Se o número de código de status HTTP 5xx consecutivos recebidos por um proxy Envoy for cinco ou mais, o endpoint de back-end será removido do pool de balanceamento de carga desse proxy Envoy por 30 segundos. Quando a porcentagem de aplicação é definida em 100%, o serviço de back-end aplica a remoção de endpoints não íntegros dos pools de balanceamento de carga desses proxies Envoy específicos sempre que a análise de detecção de outliers é executada. Se as condições de remoção forem atendidas, até 50% dos endpoints de back-end do pool de balanceamento de carga poderão ser removidos. 

    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:

    • BACKEND_SERVICE_NAME: o nome do serviço de back-end
    • PROJECT_ID: ID do projeto
    • REGION_A e REGION_B: as regiões em que 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 detecção de outliers agora está ativada no serviço de back-end.

Como excluir um NEG sem servidor

Um grupo de endpoints de rede não pode ser excluído se estiver conectado a um serviço de back-end. Antes de excluir um NEG, verifique se ele está separado do serviço de back-end.

Console

  1. Para garantir que o NEG sem servidor que você quer excluir não esteja sendo usado por nenhum serviço de back-end, acesse a guia Serviços de back-end na página Componentes de balanceamento de carga.
    Acesse "Serviços de back-end"
  2. Se o NEG sem servidor estiver em uso no momento, faça o seguinte:
    1. Clique no nome do serviço de back-end que está usando o NEG sem servidor.
    2. Clique em Editar.
    3. Na lista de Back-ends, clique em para remover o back-end NEG sem servidor do serviço de back-end.
    4. Clique em Salvar.

  3. Acesse a página Grupo de endpoints da rede no Console do Google Cloud.
    Acesse "Grupo de endpoints de rede"
  4. Marque a caixa de seleção do NEG sem servidor que você quer excluir.
  5. Clique em Excluir.
  6. Clique em Excluir novamente para confirmar.

gcloud

Para remover um NEG sem servidor de um serviço de back-end, especifique a região em que 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 excluir o NEG sem servidor:

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

A seguir