Configurare un bilanciatore del carico delle applicazioni interno tra regioni con Cloud Run

Questo documento mostra come eseguire il deployment di un bilanciatore del carico delle applicazioni interno tra regioni con Cloud Run. Per configurare questa opzione, utilizzi un backend NEG serverless per il bilanciatore del carico.

Sebbene questo documento descriva una configurazione di Cloud Run, un NEG serverless per Cloud Run può puntare a una risorsa Cloud Run o a una risorsa Cloud Run Functions2ª generazioneen.).

I NEG serverless ti consentono di utilizzare i servizi Cloud Run con il bilanciatore del carico. Dopo aver configurato un bilanciatore del carico con il backend NEG serverless, le richieste al bilanciatore del carico vengono instradate al backend Cloud Run.

Il bilanciamento del carico interregionale fornisce ridondanza, in modo che se una regione non è raggiungibile, il traffico venga reindirizzato automaticamente a un'altra regione. In base alla posizione di Envoy, il traffico proxy viene distribuito ai servizi Cloud Run nel seguente modo:

  • Se i servizi Cloud Run multiregionali sono configurati nella stessa regione di Envoy, viene preferito il NEG che si trova nella stessa regione di Envoy. Il traffico viene inviato alla regione di failover solo se il rilevamento dei valori anomali è abilitato e il NEG locale non è integro.
  • Se i servizi Cloud Run multiregione non sono configurati nella stessa regione di Envoy, il traffico viene distribuito uniformemente su tutti i NEG. Le NEG più vicine non sono preferite.
  • Se Identity-Aware Proxy è abilitato, è supportato un solo NEG serverless. Tuttavia, puoi configurare servizi Cloud Run aggiuntivi, ma il bilanciatore del carico non invia traffico.

Prima di iniziare

Prima di seguire questa guida, acquisisci familiarità con quanto segue:

Esegui il deployment di un servizio Cloud Run

Le istruzioni riportate in questa pagina presuppongono che tu abbia già un servizio Cloud Run in esecuzione.

Per l'esempio in questa pagina, puoi utilizzare una qualsiasi delle guide rapide di Cloud Run per eseguire il deployment di un servizio Cloud Run.

Per impedire l'accesso al servizio Cloud Run da internet, limita l'accesso in entrata a internal. Il traffico dal bilanciatore del carico delle applicazioni interno è considerato traffico interno.

Il posizionamento del servizio Cloud Run in più regioni contribuisce a prevenire errori in una singola regione. Per eseguire il deployment del servizio Cloud Run nelle regioni REGION_A e REGION_B, esegui questi comandi:

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

Prendi nota del nome del servizio che crei. Il resto di questa pagina mostra come configurare un bilanciatore del carico che instrada le richieste a questo servizio.

Configura una risorsa del certificato SSL

Crea una risorsa del certificato SSL di Certificate Manager nel seguente modo:

Ti consigliamo di utilizzare un certificato gestito da Google.

Autorizzazioni

Per seguire questa guida, devi essere in grado di creare istanze e modificare una rete in un progetto. Devi essere un proprietario o un editor del progetto oppure disporre di tutti i seguenti ruoli IAM di Compute Engine.

Attività Ruolo richiesto
Crea reti, subnet e componenti del bilanciatore del carico Compute Network Admin
Aggiungere e rimuovere regole firewall Amministratore sicurezza Compute
Creazione delle istanze Compute Instance Admin

Per ulteriori informazioni, consulta le seguenti guide:

Panoramica della configurazione

Puoi configurare il bilanciatore del carico delle applicazioni interno tra regioni come descritto nel seguente diagramma:

Bilanciatore del carico delle applicazioni interno tra regioni con deployment Cloud Run.
Bilanciatore del carico delle applicazioni interno tra regioni con deployment Cloud Run (fai clic per ingrandire).

Come mostrato nel diagramma, questo esempio crea un bilanciatore del carico delle applicazioni interno interregionale in una rete VPC, con un servizio di backend e due deployment Cloud Run nelle regioni REGION_A e REGION_B.

La configurazione del bilanciatore del carico delle applicazioni interno tra regioni è descritta nel seguente modo:

  1. Una rete VPC con le seguenti subnet:

    • Subnet SUBNET_A e una subnet solo proxy in REGION_A.
    • Subnet SUBNET_B e una subnet solo proxy in REGION_B.

    Devi creare subnet solo proxy in ogni regione di una rete VPC in cui utilizzi bilanciatori del carico delle applicazioni interni multiregionali. La subnet solo proxy della regione è condivisa tra tutti i bilanciatori del carico delle applicazioni interni tra regioni nella regione. Gli indirizzi di origine dei pacchetti inviati dal bilanciatore del carico ai backend del tuo servizio vengono allocati dalla subnet solo proxy. In questo esempio, la subnet solo proxy per la regione REGION_A ha un intervallo di indirizzi IP primari di 10.129.0.0/23 e per REGION_B ha un intervallo di indirizzi IP primari di 10.130.0.0/23, che è la dimensione della subnet consigliata.

  2. Una regola firewall che consente i flussi di traffico della subnet solo proxy nella tua rete. Ciò significa aggiungere una regola che consenta il traffico delle porte TCP 80, 443 e 8080 da 10.129.0.0/23 e 10.130.0.0/23 (l'intervallo delle subnet solo proxy in questo esempio).

  3. Un'altra regola firewall per i probe del controllo di integrità.

  4. Una configurazione ad alta disponibilità con backend serverless per i deployment Cloud Run nelle regioni REGION_A e REGION_B. Se i backend in una regione non sono attivi, il traffico esegue il failover nell'altra regione.

  5. Un servizio di backend globale che monitora l'utilizzo e l'integrità dei backend. Assicurati di abilitare il rilevamento outlier sul servizio di backend.

  6. Una mappa URL globale che analizza l'URL di una richiesta e inoltra le richieste a servizi di backend specifici in base all'host e al percorso dell'URL della richiesta.

  7. Un proxy HTTP o HTTPS di destinazione globale, che riceve una richiesta dall'utente e la inoltra alla mappa URL. Per HTTPS, configura una risorsa del certificato SSL regionale. Se configuri il bilanciamento del carico HTTPS, il proxy di destinazione utilizza il certificato SSL per decriptare il traffico SSL. Il proxy di destinazione può inoltrare il traffico alle tue istanze utilizzando HTTP o HTTPS.

  8. Regole di forwarding globali, che hanno l'indirizzo IP interno del bilanciatore del carico, per inoltrare ogni richiesta in entrata al proxy di destinazione.

    L'indirizzo IP interno associato alla regola di forwarding può provenire da qualsiasi subnet nella stessa rete e regione. Tieni presente le seguenti condizioni:

    • L'indirizzo IP può (ma non deve) provenire dalla stessa subnet dei gruppi di istanza di backend.
    • L'indirizzo IP non deve provenire da una subnet solo proxy riservata con il flag --purpose impostato su GLOBAL_MANAGED_PROXY.
    • Se vuoi utilizzare lo stesso indirizzo IP interno con più regole di inoltro, imposta il flag dell'indirizzo IP --purpose su SHARED_LOADBALANCER_VIP.

  9. (Facoltativo) Configura le policy di routing DNS di tipo GEO per instradare il traffico client al VIP del bilanciatore del carico nella regione più vicina al client.

Configura la rete e le subnet

All'interno della rete VPC, configura una subnet in ogni regione in cui sono configurati i backend. Inoltre, configura un proxy-only-subnet in ogni regione in cui vuoi configurare il bilanciatore del carico.

Questo esempio utilizza la seguente rete VPC, regione e subnet:

  • Rete. La rete è una rete VPC in modalità personalizzata denominata NETWORK.

  • Subnet per i backend. Una subnet denominata SUBNET_A nella regione REGION_A utilizza 10.1.2.0/24 per il suo intervallo IP primario. La subnet denominata SUBNET_B nella regione REGION_B utilizza 10.1.3.0/24 per il suo intervallo IP primario.

  • Subnet per i proxy. Una subnet denominata PROXY_SN_A nella regione REGION_A utilizza 10.129.0.0/23 per il suo intervallo IP primario. Una subnet denominata PROXY_SN_B nella regione REGION_B utilizza 10.130.0.0/23 per il suo intervallo IP primario.

I bilanciatori del carico delle applicazioni interni tra regioni sono accessibili da qualsiasi regione all'interno del VPC. In questo modo, i client di qualsiasi regione possono accedere a livello globale ai backend del bilanciatore del carico.

Configura le subnet di backend

Console

  1. Nella console Google Cloud , vai alla pagina Reti VPC.

    Vai a Reti VPC

  2. Fai clic su Crea rete VPC.

  3. Specifica un nome per la rete.

  4. Nella sezione Subnet, imposta Modalità di creazione subnet su Personalizzata.

  5. Crea una subnet per i backend del bilanciatore del carico. Nella sezione Nuova subnet, inserisci le seguenti informazioni:

    • Specifica un nome per la subnet.
    • Seleziona una regione: REGION_A
    • Inserisci un intervallo di indirizzi IP: 10.1.2.0/24

  6. Fai clic su Fine.

  7. Fai clic su Aggiungi subnet.

  8. Crea una subnet per i backend del bilanciatore del carico. Nella sezione Nuova subnet, inserisci le seguenti informazioni:

    • Specifica un nome per la subnet.
    • Seleziona una regione: REGION_B
    • Inserisci un intervallo di indirizzi IP: 10.1.3.0/24

  9. Fai clic su Fine.

  10. Fai clic su Crea.

gcloud

  1. Crea la rete VPC personalizzata con il comando gcloud compute networks create:

    gcloud compute networks create NETWORK --subnet-mode=custom

  2. Crea una subnet nella rete NETWORK nella regione REGION_A con il 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. Crea una subnet nella rete NETWORK nella regione REGION_B con il 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

Invia una richiesta POST al metodo networks.insert. Sostituisci PROJECT_ID con l'ID progetto.

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

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

Invia una richiesta POST al metodo subnetworks.insert. Sostituisci PROJECT_ID con l'ID progetto.

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

Invia una richiesta POST al metodo subnetworks.insert. Sostituisci PROJECT_ID con l'ID progetto.

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

Configura la subnet solo proxy

Una subnet solo proxy fornisce un insieme di indirizzi IP che Google Cloud utilizza per eseguire i proxy Envoy per tuo conto. I proxy terminano le connessioni dal client e creano connessioni ai backend.

Questa subnet solo proxy viene utilizzata da tutti i bilanciatori del carico regionali basati su Envoy nella stessa regione della rete VPC. Può esserci una sola subnet solo proxy attiva per uno scopo specifico, per regione e per rete.

Console

Se utilizzi la console Google Cloud , puoi attendere e creare la subnet solo proxy in un secondo momento nella pagina Bilanciamento del carico.

Se vuoi creare subito la subnet solo proxy, segui questi passaggi:

  1. Nella console Google Cloud , vai alla pagina Reti VPC.

    Vai a Reti VPC

  2. Fai clic sul nome della rete VPC.
  3. Nella scheda Subnet, fai clic su Aggiungi subnet.
  4. Fornisci un nome per la subnet solo proxy.
  5. Nell'elenco Regione, seleziona REGION_A.
  6. Nell'elenco Scopo, seleziona Proxy gestito cross-region.
  7. Nel campo Intervallo di indirizzi IP, inserisci 10.129.0.0/23.
  8. Fai clic su Aggiungi.

Crea la subnet solo proxy in REGION_B

  1. Fai clic su Aggiungi subnet.
  2. Fornisci un nome per la subnet solo proxy.
  3. Nell'elenco Regione, seleziona REGION_B.
  4. Nell'elenco Scopo, seleziona Proxy gestito cross-region.
  5. Nel campo Intervallo di indirizzi IP, inserisci 10.130.0.0/23.
  6. Fai clic su Aggiungi.

gcloud

Crea le subnet solo proxy con il 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

Crea le subnet solo proxy con il metodo subnetworks.insert, sostituendo PROJECT_ID con l'ID progetto.

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

Crea i NEG serverless

  1. Crea un NEG serverless per il tuo servizio 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

Configura il bilanciatore del carico

Il traffico dal bilanciatore del carico ai backend NEG serverless utilizza route speciali definiti al di fuori del VPC che non sono soggetti a regole firewall. Pertanto, se il bilanciatore del carico ha solo backend NEG serverless, non devi creare regole firewall per consentire il traffico dalla subnet solo proxy al backend serverless.

Console

Seleziona il tipo di bilanciatore del carico

  1. Nella console Google Cloud , vai alla pagina Bilanciamento del carico.

    Vai a Bilanciamento del carico

  2. Fai clic su Crea bilanciatore del carico.
  3. In Tipo di bilanciatore del carico, seleziona Bilanciatore del carico delle applicazioni (HTTP/HTTPS) e fai clic su Avanti.
  4. In Pubblico o interno, seleziona Interno e fai clic su Avanti.
  5. In Deployment tra regioni o in una regione singola, seleziona Ideale per workload tra regioni e fai clic su Avanti.
  6. Fai clic su Configura.

Configurazione di base

  1. Specifica un Nome per il bilanciatore del carico.
  2. In Rete, seleziona NETWORK.

Configura il frontend con due regole di forwarding

Per HTTP:

  1. Fai clic su Configurazione frontend.
    1. Specifica un nome per la regola di forwarding.
    2. Nell'elenco Regione subnet, seleziona REGION_A.

      Riservare una subnet solo proxy

    3. Nell'elenco Subnet, seleziona SUBNET_A.
    4. Nell'elenco Indirizzo IP, fai clic su Crea indirizzo IP. Si apre la pagina Prenota un indirizzo IP interno statico.
      • Fornisci un Nome per l'indirizzo IP statico.
      • Nell'elenco Indirizzo IP statico, seleziona Scelta manuale.
      • Nel campo Indirizzo IP personalizzato, inserisci 10.1.2.99.
      • Seleziona Prenota.
  2. Fai clic su Fine.
  3. Per aggiungere la seconda regola di forwarding, fai clic su Aggiungi IP e porta frontend.
    1. Specifica un nome per la regola di forwarding.
    2. Nell'elenco Regione subnet, seleziona REGION_B.

      Riservare una subnet solo proxy

    3. Nell'elenco Subnet, seleziona SUBNET_B.
    4. Nell'elenco Indirizzo IP, fai clic su Crea indirizzo IP. Si apre la pagina Prenota un indirizzo IP interno statico.
      • Fornisci un Nome per l'indirizzo IP statico.
      • Nell'elenco Indirizzo IP statico, seleziona Scelta manuale.
      • Nel campo Indirizzo IP personalizzato, inserisci 10.1.3.99.
      • Seleziona Prenota.
  4. Fai clic su Fine.

Per HTTPS:

Se utilizzi HTTPS tra il client e il bilanciatore del carico, devi configurare il proxy con una o più risorse di certificati SSL. Per creare un certificato gestito da Google all-regions, consulta la seguente documentazione:

Dopo aver creato il certificato gestito da Google, collegalo direttamente al proxy di destinazione. Le mappe dei certificati non sono supportate dai bilanciatori del carico delle applicazioni interni tra regioni.

Per creare un certificato autogestito all-regions, consulta la seguente documentazione: Esegui il deployment di un certificato autogestito regionale.

  1. Fai clic su Configurazione frontend.
    1. Specifica un nome per la regola di forwarding.
    2. Nel campo Protocollo, seleziona HTTPS (includes HTTP/2).
    3. Assicurati che la Porta sia impostata su 443.
    4. Nell'elenco Regione subnet, seleziona REGION_A.

      Riservare una subnet solo proxy

    5. Nell'elenco Subnet, seleziona SUBNET_A.
    6. Nell'elenco Indirizzo IP, fai clic su Crea indirizzo IP. Si apre la pagina Prenota un indirizzo IP interno statico.
      • Fornisci un Nome per l'indirizzo IP statico.
      • Nell'elenco Indirizzo IP statico, seleziona Scelta manuale.
      • Nel campo Indirizzo IP personalizzato, inserisci 10.1.3.99.
      • Seleziona Prenota.
    7. Nella sezione Aggiungi certificato, seleziona il certificato.
    8. (Facoltativo) Per aggiungere certificati oltre al certificato SSL principale:
      1. Fai clic su Aggiungi certificato.
      2. Seleziona il certificato dall'elenco.
    9. Seleziona un criterio SSL dall'elenco Criterio SSL. Se non hai creato alcun criterio SSL, viene applicato un criterio SSL predefinito Google Cloud .
    10. Fai clic su Fine.

    Aggiungi la seconda configurazione frontend:

    1. Fornisci un nome per la configurazione frontend.
    2. Nel campo Protocollo, seleziona HTTPS (includes HTTP/2).
    3. Assicurati che la Porta sia impostata su 443.
    4. Nell'elenco Regione subnet, seleziona REGION_B.

      Riservare una subnet solo proxy

    5. Nell'elenco Subnet, seleziona SUBNET_B.
    6. Nell'elenco Indirizzo IP, fai clic su Crea indirizzo IP. Si apre la pagina Prenota un indirizzo IP interno statico.
      • Fornisci un Nome per l'indirizzo IP statico.
      • Nell'elenco Indirizzo IP statico, seleziona Scelta manuale.
      • Nel campo Indirizzo IP personalizzato, inserisci 10.1.3.99.
      • Seleziona Prenota.
    7. Nella sezione Aggiungi certificato, seleziona il certificato.
    8. (Facoltativo) Per aggiungere certificati oltre al certificato SSL principale:
      1. Fai clic su Aggiungi certificato.
      2. Seleziona il certificato dall'elenco.
    9. Seleziona un criterio SSL dall'elenco Criterio SSL. Se non hai creato alcun criterio SSL, viene applicato un criterio SSL predefinito Google Cloud .
    10. Fai clic su Fine.
    Configura il servizio di backend
    1. Fai clic su Configurazione backend.
    2. Nell'elenco Crea o seleziona servizi di backend, fai clic su Crea un servizio di backend.
    3. Specifica un nome per il servizio di backend.
    4. In Protocollo, seleziona HTTP.
    5. In Porta denominata, inserisci http.
    6. Nell'elenco Tipo di backend, seleziona Gruppo di endpoint di rete serverless.
    7. Nella sezione Nuovo backend:
      • Nell'elenco Gruppo di endpoint di rete serverless, seleziona gl7ilb-serverless-neg-a.
      • Fai clic su Fine.
      • Per aggiungere un altro backend, fai clic su Aggiungi backend.
      • Nell'elenco Gruppo di endpoint di rete serverless, seleziona gl7ilb-serverless-neg-b.
      • Fai clic su Fine.

    Configurare le regole di routing

    1. Fai clic su Regole di routing.
    2. Per Modalità, seleziona Regola semplice per host e percorso.
    3. Assicurati che esista un solo servizio di backend per qualsiasi host senza corrispondenza e qualsiasi percorso senza corrispondenza.

    Esaminare la configurazione

    1. Fai clic su Esamina e finalizza.
    2. Controlla le impostazioni di configurazione del bilanciatore del carico.
    3. Fai clic su Crea.

gcloud

  1. Definisci il servizio di backend con il comando gcloud compute backend-services create.

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

  2. Aggiungi backend al servizio di backend con il 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. Crea la mappa URL con il comando gcloud compute url-maps create.

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

  4. Crea il proxy di destinazione.

    Per HTTP:

    Crea il proxy di destinazione con il comando gcloud compute target-http-proxies create.

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

    Per HTTPS:

    Per creare un certificato gestito da Google, consulta la seguente documentazione:

    Dopo aver creato il certificato gestito da Google, collegalo direttamente al proxy di destinazione. Le mappe dei certificati non sono supportate dai bilanciatori del carico delle applicazioni interni tra regioni.

    Per creare un certificato autogestito, consulta la seguente documentazione:

    Assegna i percorsi file ai nomi delle variabili.

    export LB_CERT=PATH_TO_PEM_FORMATTED_FILE

    export LB_PRIVATE_KEY=PATH_TO_LB_PRIVATE_KEY_FILE

    Crea un certificato SSL per tutte le regioni utilizzando il 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

    Utilizza il certificato SSL per creare un proxy di destinazione con il 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. Crea due regole di forwarding: una con un VIP (10.1.2.99) nella regione REGION_B e un'altra con un VIP (10.1.3.99) nella regione REGION_A.

    Per le reti personalizzate, devi fare riferimento alla subnet nella regola di inoltro. Tieni presente che questa è la subnet dell'istanza di macchina virtuale (VM), non la subnet proxy.

    Per HTTP:

    Utilizza il comando gcloud compute forwarding-rules create con i flag corretti.

    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

    Per HTTPS:

    Crea la regola di forwarding con il comando gcloud compute forwarding-rules create con i flag corretti.

    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

Crea il servizio di backend globale effettuando una richiesta POST al metodo backendServices.insert, sostituendo PROJECT_ID con il tuo ID progetto.

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

Crea la mappa URL inviando una richiesta POST al metodo urlMaps.insert, sostituendo PROJECT_ID con il tuo ID progetto.

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

Per HTTP:

Crea il proxy HTTP di destinazione effettuando una richiesta POST al metodo targetHttpProxies.insert, sostituendo PROJECT_ID con l'ID progetto.

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

Crea la regola di forwarding effettuando una richiesta POST al metodo globalforwardingRules.insert, sostituendo PROJECT_ID con il tuo ID progetto.

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

Per HTTPS:

Leggi i file del certificato e della chiave privata, quindi crea il certificato SSL. Il seguente esempio mostra come farlo con Python.

Crea il proxy HTTPS di destinazione inviando una richiesta POST al metodo targetHttpsProxies.insert, sostituendo PROJECT_ID con l'ID progetto.

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
}

Crea la regola di forwarding effettuando una richiesta POST al metodo globalForwardingRules.insert, sostituendo PROJECT_ID con il tuo ID progetto.

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

Testa il bilanciatore del carico

Ora che il servizio di bilanciamento del carico è in esecuzione, puoi inviare traffico alla regola di forwarding e osservare la distribuzione del traffico su diverse istanze.

Configura la regola firewall

Questo esempio richiede la regola firewall fw-allow-ssh per la VM client di test. fw-allow-ssh è una regola in entrata applicabile alla VM client di test e che consente la connettività SSH in entrata sulla porta TCP 22 da qualsiasi indirizzo. Puoi scegliere un intervallo di indirizzi IP di origine più restrittivo per questa regola. Ad esempio, puoi specificare solo gli intervalli di indirizzi IP del sistema da cui avvii le sessioni SSH. Questo esempio utilizza il tag target allow-ssh.

gcloud

  1. Crea la regola firewall fw-allow-ssh per consentire la connettività SSH alle VM con il tag di rete allow-ssh. Se ometti source-ranges, Google Cloud interpreta la regola come qualsiasi origine.

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

Crea un'istanza VM per testare la connettività

  1. Crea una VM client:

    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. Connettiti a ogni istanza client tramite SSH.

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

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

  3. Verifica che l'indirizzo IP stia gestendo il proprio nome host.

    • Verifica che la VM client possa raggiungere entrambi gli indirizzi IP. Il comando ha esito positivo e restituisce il nome della VM di backend che ha gestito la richiesta:

      Per il test HTTP:

      curl 10.1.2.99

      curl 10.1.3.99

      Per il test 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

      Sostituisci DOMAIN_NAME con il nome di dominio dell'applicazione, ad esempio test.example.com.

      Il flag -k fa sì che curl salti la convalida del certificato.

    • (Facoltativo) Utilizza il record DNS configurato per risolvere l'indirizzo IP.

      curl service.example.com

Esegui 100 richieste e verifica che siano bilanciate

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

Per HTTPS:

Sostituisci DOMAIN_NAME con il nome di dominio dell'applicazione, ad esempio 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
  }

Testa il failover

  1. Verifica il failover ai backend nella regione REGION_A quando i backend nelle regioni REGION_B non sono integri o non sono raggiungibili. Simuliamo questa situazione rimuovendo tutti i backend da 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. Connettiti, utilizzando SSH, a una VM client in REGION_B.

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

  3. Invia richieste all'indirizzo IP bilanciato del carico nella regione REGION_B. L'output del comando mostra le risposte delle VM di backend in REGION_A.

    Sostituisci DOMAIN_NAME con il nome di dominio dell'applicazione, ad esempio 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
}

Opzioni di configurazione aggiuntive

Questa sezione espande l'esempio di configurazione per fornire opzioni di configurazione alternative e aggiuntive. Tutte le attività sono facoltative. Puoi eseguirle in qualsiasi ordine.

Utilizzo di una maschera URL

Quando crei un NEG serverless, anziché selezionare un servizio Cloud Run specifico, puoi utilizzare una maschera URL per puntare a più servizi che vengono pubblicati nello stesso dominio. Una maschera URL è un modello dello schema URL. Il NEG serverless utilizza questo modello per estrarre il nome del servizio dall'URL della richiesta in entrata e mappare la richiesta al servizio appropriato.

Le maschere URL sono particolarmente utili se il tuo servizio è mappato a un dominio personalizzato anziché all'indirizzo predefinito fornito da Google Cloud per il servizio di cui è stato eseguito il deployment. Una maschera URL ti consente di scegliere come target più servizi e versioni con una singola regola anche quando la tua applicazione utilizza un pattern URL personalizzato.

Se non l'hai ancora fatto, assicurati di leggere la panoramica dei NEGS serverless: maschere URL.

Costruire una maschera URL

Per creare una maschera URL per il bilanciatore del carico, inizia con l'URL del tuo servizio. Questo esempio utilizza un'app serverless di esempio in esecuzione all'indirizzo https://example.com/login. Questo è l'URL in cui viene pubblicato il servizio login dell'app.

  1. Rimuovi http o https dall'URL. Ti rimangono example.com/login.
  2. Sostituisci il nome del servizio con un segnaposto per la maschera URL.
    • Cloud Run: sostituisci il nome del servizio Cloud Run con il segnaposto <service>. Se il servizio Cloud Run ha un tag associato, sostituisci il nome del tag con il segnaposto <tag>. In questo esempio, la maschera URL rimanente è example.com/<service>.

  3. (Facoltativo) Se il nome del servizio può essere estratto dalla parte del percorso dell'URL, il dominio può essere omesso. La parte del percorso della maschera URL è distinta dal primo carattere barra (/). Se non è presente una barra (/) nella maschera URL, si presume che la maschera rappresenti solo l'host. Pertanto, per questo esempio, la maschera URL può essere ridotta a /<service>.

    Allo stesso modo, se è possibile estrarre <service> dalla parte host dell'URL, puoi omettere completamente il percorso dalla maschera URL.

    Puoi anche omettere qualsiasi componente di host o sottodominio che precede il primo segnaposto, nonché qualsiasi componente di percorso che segue l'ultimo segnaposto. In questi casi, il segnaposto acquisisce le informazioni richieste per il componente.

Ecco alcuni altri esempi che dimostrano queste regole:

Questa tabella presuppone che tu abbia un dominio personalizzato chiamato example.com e che tutti i tuoi servizi Cloud Run siano mappati a questo dominio.

Servizio, Nome tag URL del dominio personalizzato Cloud Run Maschera URL
service: login https://login-home.example.com/web <service>-home.example.com
service: login https://example.com/login/web example.com/<service> o /<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> or /home/<service>/<tag>
service: login, tag: test https://test.example.com/home/login/web <tag>.example.com/home/<service>

Creazione di un NEG serverless con una maschera URL

Console

Per un nuovo bilanciamento del carico, puoi utilizzare la stessa procedura end-to-end descritta in precedenza in questo documento. Quando configuri il servizio di backend, invece di selezionare un servizio specifico, inserisci una maschera URL.

Se hai un bilanciatore del carico esistente, puoi modificare la configurazione del backend e fare in modo che il NEG serverless punti a una maschera URL anziché a un servizio specifico.

Per aggiungere un NEG serverless basato su maschera URL a un servizio di backend esistente:

  1. Nella console Google Cloud , vai alla pagina Bilanciamento del carico.
    Vai a Bilanciamento del carico
  2. Fai clic sul nome del bilanciatore del carico che ha il servizio di backend da modificare.
  3. Nella pagina Dettagli del bilanciatore del carico, fai clic su Modifica.
  4. Nella pagina Modifica bilanciatore del carico delle applicazioni esterno globale, fai clic su Configurazione backend.
  5. Nella pagina Configurazione backend, fai clic su Modifica per il servizio di backend che vuoi modificare.
  6. Fai clic su Aggiungi backend.
  7. Seleziona Crea gruppo di endpoint di rete serverless.
    1. In Nome, inserisci helloworld-serverless-neg.
    2. Nella sezione Regione viene visualizzata la regione del bilanciatore del carico.
    3. In Tipo di gruppo di endpoint di rete serverless, Cloud Run è l'unico tipo di gruppo di endpoint di rete supportato.
      1. Seleziona Usa maschera URL.
      2. Inserisci una maschera URL. Per informazioni su come creare una maschera URL, consulta Creazione di una maschera URL.
      3. Fai clic su Crea.

  8. In Nuovo backend, fai clic su Fine.
  9. Fai clic su Aggiorna.

gcloud

Per creare un NEG serverless con una maschera URL di esempio di 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>"

Utilizza lo stesso indirizzo IP tra più regole di forwarding interno

Affinché più regole di forwarding interno condividano lo stesso indirizzo IP interno, devi prenotare l'indirizzo IP e impostare il relativo flag --purpose su SHARED_LOADBALANCER_VIP.

gcloud 

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP
Se devi reindirizzare il traffico HTTP a HTTPS, puoi creare due regole di forwarding che utilizzano un indirizzo IP comune. Per maggiori informazioni, vedi Configurare il reindirizzamento da HTTP a HTTPS per i bilanciatori del carico delle applicazioni interni.

Configura le policy di routing DNS

Se i tuoi client si trovano in più regioni, potresti voler rendere accessibile il bilanciatore del carico delle applicazioni interno tra regioni utilizzando VIP in queste regioni. Questa configurazione multiregionale riduce al minimo la latenza e i costi di transito di rete. Inoltre, ti consente di configurare una soluzione di bilanciamento del carico globale basata su DNS che offre resilienza alle interruzioni a livello di regione. Per saperne di più, vedi Gestire le policy di routing DNS e i controlli di integrità.

gcloud

Per creare una voce DNS con un TTL di 30 secondi, utilizza il 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

Sostituisci quanto segue:

  • DNS_ENTRY: DNS o nome di dominio del record set

    Ad esempio, service.example.com

  • REGION_A e REGION_B: le regioni in cui hai configurato il bilanciatore del carico

API

Crea il record DNS inviando una richiesta POST al metodo ResourceRecordSets.create. Sostituisci PROJECT_ID con l'ID progetto.

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

Abilita rilevamento outlier

Puoi attivare il rilevamento di outlier sui servizi di backend globali per identificare i NEG serverless non integri e ridurre il numero di richieste inviate ai NEG serverless non integri.

Il rilevamento dei valori anomali è abilitato nel servizio di backend utilizzando uno dei seguenti metodi:

  • Il metodo consecutiveErrors (outlierDetection.consecutiveErrors), in cui un codice di stato HTTP della serie 5xx viene considerato un errore.
  • Il metodo consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), in cui solo i codici di stato HTTP 502, 503 e 504 sono considerati errori.

Per attivare il rilevamento degli outlier per un servizio di backend esistente: Tieni presente che, anche dopo aver attivato il rilevamento degli outlier, alcune richieste possono essere inviate al servizio non integro e restituire un codice di stato 5xx ai client. Per ridurre ulteriormente il tasso di errore, puoi configurare valori più aggressivi per i parametri di rilevamento dei valori anomali. Per ulteriori informazioni, vedi il campo outlierDetection.

Console

  1. Nella console Google Cloud , vai alla pagina Bilanciamento del carico.

    Vai a Bilanciamento del carico

  2. Fai clic sul nome del bilanciatore del carico di cui vuoi modificare il servizio di backend.

  3. Nella pagina Dettagli del bilanciatore del carico, fai clic su Modifica.

  4. Nella pagina Modifica bilanciatore del carico delle applicazioni interno cross-region, fai clic su Configurazione backend.

  5. Nella pagina Configurazione backend, fai clic su Modifica per il servizio di backend che vuoi modificare.

  6. Scorri verso il basso ed espandi la sezione Configurazioni avanzate.

  7. Nella sezione Rilevamento outlier, seleziona la casella di controllo Attiva.

  8. Fai clic su Modifica per configurare il rilevamento di valori anomali.

    Verifica che le seguenti opzioni siano configurate con questi valori:

    Proprietà Valore
    Errori consecutivi 5
    Intervallo 1000
    Tempo di espulsione base 30000
    Percentuale massima di espulsione 50
    Applicazione di errori consecutivi 100

    In questo esempio, l'analisi di rilevamento dei valori anomali viene eseguita ogni secondo. Se il numero di codici di stato HTTP 5xx consecutivi ricevuti da un proxy Envoy è pari o superiore a cinque, l'endpoint di backend viene escluso dal pool di bilanciamento del carico di quel proxy Envoy per 30 secondi. Quando la percentuale di applicazione è impostata su 100%, il servizio di backend applica l'espulsione degli endpoint non integri dai pool di bilanciamento del carico di questi proxy Envoy specifici ogni volta che viene eseguita l'analisi di rilevamento outlier. Se le condizioni di espulsione sono soddisfatte, è possibile espellere fino al 50% degli endpoint del backend dal pool di bilanciamento del carico.

  9. Fai clic su Salva.

  10. Per aggiornare il servizio di backend, fai clic su Aggiorna.

  11. Per aggiornare il bilanciatore del carico, nella pagina Modifica bilanciatore del carico delle applicazioni interno tra regioni, fai clic su Aggiorna.

gcloud

  1. Esporta il servizio di backend in un file YAML.

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

    Sostituisci BACKEND_SERVICE_NAME con il nome del servizio di backend.

  2. Modifica la configurazione YAML del servizio di backend per aggiungere i campi per il rilevamento di outlier come evidenziato nella seguente configurazione YAML, nella sezione outlierDetection:

    In questo esempio, l'analisi di rilevamento dei valori anomali viene eseguita ogni secondo. Se il numero di codici di stato HTTP 5xx consecutivi ricevuti da un proxy Envoy è pari o superiore a cinque, l'endpoint di backend viene escluso dal pool di bilanciamento del carico di quel proxy Envoy per 30 secondi. Quando la percentuale di applicazione è impostata su 100%, il servizio di backend applica l'espulsione degli endpoint non integri dai pool di bilanciamento del carico di questi proxy Envoy specifici ogni volta che viene eseguita l'analisi di rilevamento outlier. Se le condizioni di espulsione sono soddisfatte, è possibile espellere fino al 50% degli endpoint del backend dal pool di bilanciamento del carico. 

    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
...

    Sostituisci quanto segue:

    • BACKEND_SERVICE_NAME: il nome del servizio di backend
    • PROJECT_ID: l'ID del tuo progetto
    • REGION_A e REGION_B: le regioni in cui è stato configurato il bilanciatore del carico.
    • SERVERLESS_NEG_NAME: il nome del primo NEG serverless
    • SERVERLESS_NEG_NAME_2: il nome del secondo NEG serverless

  3. Aggiorna il servizio di backend importando la configurazione più recente.

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

    Il rilevamento outlier è ora abilitato sul servizio di backend.

Eliminazione di un NEG serverless

Un gruppo di endpoint di rete non può essere eliminato se è collegato a un servizio di backend. Prima di eliminare un NEG, assicurati che sia scollegato dal servizio di backend.

Console

  1. Per assicurarti che il NEG serverless che vuoi eliminare non sia in uso da alcun servizio di backend, vai alla scheda Servizi di backend nella pagina Componenti di bilanciamento del carico.
    Vai a Servizi di backend
  2. Se il NEG serverless è in uso:
    1. Fai clic sul nome del servizio di backend che utilizza il NEG serverless.
    2. Fai clic su Modifica.
    3. Nell'elenco dei backend, fai clic su per rimuovere il backend NEG serverless dal servizio di backend.
    4. Fai clic su Salva.

  3. Vai alla pagina Gruppo di endpoint di rete nella console Google Cloud .
    Vai al gruppo di endpoint di rete
  4. Seleziona la casella di controllo per il NEG serverless che vuoi eliminare.
  5. Fai clic su Elimina.
  6. Fai di nuovo clic su Elimina per confermare.

gcloud

Per rimuovere un NEG serverless da un servizio di backend, devi specificare la regione in cui è stato creato il NEG.

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

Per eliminare il NEG serverless:

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

Passaggi successivi