Configura 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 in Cloud Run. Per configurarlo, utilizza un Backend serverless NEG per il bilanciatore del carico.

I NEG serverless ti consentono di utilizzare con i servizi Cloud Run con il tuo bilanciatore del carico. Dopo la configurazione 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 tra regioni fornisce ridondanza, in modo che se una regione non raggiungibile, il traffico viene automaticamente reindirizzato a un'altra regione. In base alla posizione di Envoy, il traffico proxy viene distribuito Cloud Run come segue:

• Se i servizi Cloud Run multiregionali sono configurati nello stesso regione di Envoy, il NEG che si trova nella stessa regione di Envoy è preferibile. Il traffico viene inviato alla regione di failover solo se outlier il rilevamento è abilitato e il NEG locale non è integro.
• Se i servizi Cloud Run multiregionali non sono configurati nel nella stessa regione di Envoy, il traffico è distribuito uniformemente tra tutti i NEG. I NEG più vicini non sono preferiti.
• Se Identity-Aware Proxy è abilitato, solo un singolo il NEG serverless è supportato. Tuttavia, puoi configurare ulteriori ma il bilanciatore del carico non invia alcun servizio Cloud Run. e il traffico verso di loro.

Prima di iniziare

Prima di seguire questa guida, acquisisci familiarità con i seguenti argomenti:

• Panoramica del bilanciatore del carico delle applicazioni interno, incluse le Limitazioni sezione
• Regole firewall VPC
• Panoramica dei gruppi di endpoint di rete serverless

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 uno qualsiasi dei Guide di avvio rapido di Cloud Run per eseguire il deployment dal servizio Cloud Run.

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

Posizionare il servizio Cloud Run in più regioni consente per evitare errori in una singola regione. Per eseguire il deployment servizio Cloud Run in REGION_A e REGION_B regioni, 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 Gestore certificati come segue:

• Esegui il deployment di un certificato autogestito globale
• Crea un certificato gestito da Google emesso dalla tua istanza di Certificate Authority Service
• Crea un certificato gestito da Google con autorizzazione DNS

Ti consigliamo di utilizzare un certificato gestito da Google.

Autorizzazioni

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

Attività	Ruolo richiesto
Creazione di reti, subnet e componenti del bilanciatore del carico	Amministratore rete Compute
Aggiungi e rimuovi regole firewall	Amministratore sicurezza Compute
Creazione delle istanze	Amministratore istanze Compute

Per ulteriori informazioni, consulta le seguenti guide:

• Ruoli e autorizzazioni
• Condizioni IAM per le regole di forwarding

Panoramica della configurazione

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

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 tra regioni in un una rete VPC, con un backend e due deployment Cloud Run REGION_A e REGION_B regioni.

La configurazione del bilanciatore del carico delle applicazioni interno tra regioni è descritta come segue:

1. Una rete VPC con le seguenti subnet:

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

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

2. Una regola firewall che consenta i flussi di traffico della subnet solo proxy nel tuo in ogni rete. Ciò significa aggiungere una regola che consenta la porta TCP 80, 443 e 8080 da 10.129.0.0/23 e 10.130.0.0/23 (l'intervallo di subnet solo proxy in questo esempio).

3. Un'altra regola firewall per l'integrità per controllare i probe.

4. Una configurazione ad alta disponibilità con backend serverless per Deployment di Cloud Run in REGION_A e REGION_B regioni. Se i backend in una regione sono inattivi, viene eseguito il failover del traffico all'altra regione.

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

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

7. Un proxy HTTP o HTTPS di destinazione globale che riceve una richiesta dall' l'utente e lo inoltra alla mappa URL. Per HTTPS, configura un protocollo SSL a livello di regione di una risorsa di certificazione. Il proxy di destinazione utilizza il certificato SSL per decriptare il protocollo SSL se configuri il bilanciamento del carico HTTPS. Il proxy di destinazione può inoltrare alle istanze utilizzando HTTP o HTTPS.

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

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

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

9. (Facoltativo) Configura i criteri di routing DNS di tipo GEO per instradare il traffico client al VIP del bilanciatore del carico la regione più vicina al cliente.

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 rete VPC, la regione e subnet:

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

• Subnet per i backend. Una subnet denominata SUBNET_A nel La regione REGION_A utilizza 10.1.2.0/24 come principale Intervallo IP. Subnet denominata SUBNET_A nel La regione REGION_B utilizza 10.1.3.0/24 come principale Intervallo IP.

• Subnet per i proxy. Una subnet denominata PROXY_SN_A nel La regione REGION_A utilizza 10.129.0.0/23 come principale Intervallo IP. Una subnet denominata PROXY_SN_B nel La regione REGION_B utilizza 10.130.0.0/23 come principale Intervallo IP.

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

Nota: i passaggi successivi di questa guida utilizzano la rete, la regione e i parametri di subnet, come descritto qui.

Configura le subnet di backend

Console

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

   Vai alle reti VPC

2. Fai clic su Crea rete VPC.

3. Specifica un nome per la rete.

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

5. Creare 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. Creare una subnet per i backend del bilanciatore del carico. Nel 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 in 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 in 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 a Metodo networks.insert. Sostituisci PROJECT_ID con il tuo 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 a Metodo subnetworks.insert. Sostituisci PROJECT_ID con il tuo 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 a Metodo subnetworks.insert. Sostituisci PROJECT_ID con il tuo 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 una 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 di backend.

Questa subnet solo proxy viene utilizzata da tutto il carico a livello di regione basato su Envoy nella stessa regione della rete VPC. Possono esserci solo una subnet solo proxy attiva per uno scopo specifico, per regione e per rete.

Importante: non provare ad assegnare indirizzi della subnet solo proxy al carico la regola di forwarding o i backend del bilanciatore del carico. Assegni l'IP della regola di forwarding e gli indirizzi IP dell'istanza di backend uno o più intervalli di subnet diversi, non questo. Google Cloud riserva questo intervallo di subnet per sui proxy.

Console

Se utilizzi la console Google Cloud, puoi attendere e creare l'account più avanti nella pagina Bilanciamento del carico.

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

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

   Vai alle reti VPC

2. Fai clic sul nome della rete VPC.
3. Nella scheda Subnet, fai clic su Aggiungi subnet.
4. Specifica un nome per la subnet solo proxy.
5. Nell'elenco Regione, seleziona REGION_A.
6. Nell'elenco Finalità, seleziona Proxy gestito tra regioni.
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. Specifica un nome per la subnet solo proxy.
3. Nell'elenco Regione, seleziona REGION_B.
4. Nell'elenco Finalità, seleziona Proxy gestito tra regioni.
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 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 subnetworks.insert, in sostituzione PROJECT_ID con il tuo 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 Cloud Run servizio:

   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 che va dal bilanciatore del carico ai backend NEG serverless utilizza l'uso speciale route definite all'esterno del VPC che non sono soggette al firewall le regole del caso. Di conseguenza, se il bilanciatore del carico ha solo backend NEG serverless, Non è necessario creare regole firewall per consentire il traffico dalla subnet solo proxy al backend serverless.

Console

Avvia la configurazione

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. Per Tipo di bilanciatore del carico, seleziona Bilanciatore del carico delle applicazioni (HTTP/HTTPS) e fai clic su Avanti.
4. Per Pubblico o interno, seleziona Interno e fai clic Avanti.
5. Per Deployment tra più regioni o in una singola regione, seleziona Ideale per carichi di lavoro 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.
   

   Prenotare una subnet solo proxy

Se hai già configurato subnet solo proxy, il pulsante Prenota subnet non viene visualizzato. Puoi continuare con i passaggi successivi.
3. Nell'elenco Subnet, seleziona SUBNET_A.
4. Nell'elenco Indirizzo IP, fai clic su Crea indirizzo IP. Viene visualizzata la pagina Prenota un indirizzo IP interno statico.
• Specifica un nome per l'indirizzo IP statico.
• Nell'elenco Indirizzo IP statico, seleziona Fammi scegliere.
• 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.
   

   Prenotare una subnet solo proxy

Poiché hai già configurato una subnet solo proxy, il pulsante Prenota subnet non viene visualizzato. Puoi continuare con i passaggi successivi.
3. Nell'elenco Subnet, seleziona SUBNET_B.
4. Nell'elenco Indirizzo IP, fai clic su Crea indirizzo IP. Viene visualizzata la pagina Prenota un indirizzo IP interno statico.
• Specifica un nome per l'indirizzo IP statico.
• Nell'elenco Indirizzo IP statico, seleziona Fammi scegliere.
• 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, sono necessarie una o più risorse del certificato SSL per configurare il proxy. Per creare un certificato gestito da Google all-regions, consulta la documentazione seguente:

• Crea un certificato gestito da Google emesso dalla tua istanza di Certificate Authority Service.
• Crea un certificato gestito da Google con autorizzazione DNS.

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

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

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.
   

   Prenotare una subnet solo proxy

Poiché hai già configurato subnet solo proxy, il pulsante Prenota subnet non viene visualizzato. Puoi continuare con i passaggi successivi.
5. Nell'elenco Subnet, seleziona SUBNET_A.
6. Nell'elenco Indirizzo IP, fai clic su Crea indirizzo IP. Viene visualizzata la pagina Prenota un indirizzo IP interno statico.
• Specifica un nome per l'indirizzo IP statico.
• Nell'elenco Indirizzo IP statico, seleziona Fammi scegliere.
• 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 dei criteri SSL, Se non hai creato qualsiasi criterio SSL, viene applicato un criterio SSL predefinito di Google Cloud.
10. Fai clic su Fine.

Aggiungi la seconda configurazione frontend:

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

   Prenotare una subnet solo proxy

Poiché hai già configurato subnet solo proxy, il pulsante Prenota subnet non viene visualizzato. Puoi continuare con i passaggi successivi.
5. Nell'elenco Subnet, seleziona SUBNET_B.
6. Nell'elenco Indirizzo IP, fai clic su Crea indirizzo IP. Viene visualizzata la pagina Prenota un indirizzo IP interno statico.
• Specifica un nome per l'indirizzo IP statico.
• Nell'elenco Indirizzo IP statico, seleziona Fammi scegliere.
• 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 dei criteri SSL, Se non hai creato qualsiasi criterio SSL, viene applicato un criterio SSL predefinito di 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 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 Serverless network endpoint group (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 Serverless network endpoint group (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. In Modalità, seleziona Regola host e percorso semplice.
3. Assicurati che esista un solo servizio di backend per qualsiasi host senza corrispondenza a qualsiasi percorso senza corrispondenza.

Rivedi la configurazione

1. Fai clic su Esamina e finalizza.
2. Rivedi 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:

   • Crea un certificato gestito da Google emesso dalla tua istanza di Certificate Authority Service
   • Crea un certificato gestito da Google con autorizzazione DNS

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

   Per creare un certificato autogestito, consulta la seguente documentazione:

   • Crea una chiave privata e un certificato

   Assegna i percorsi dei 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 REGION_B regione e un'altra con un VIP (10.1.3.99) nel Regione REGION_A.

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

   Per HTTP:

   Usa 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 all'istanza 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 alla 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 targetHttpProxies.insert, sostituendo PROJECT_ID con il tuo 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 all'oggetto 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 l'SSL certificato. L'esempio seguente mostra come fare questo con Python.

Crea il proxy HTTPS di destinazione effettuando una richiesta POST al targetHttpsProxies.insert, sostituendo PROJECT_ID con il tuo 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 all'oggetto 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 il traffico al server di una regola di forwarding e osserva il traffico distribuito in 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 del client di test e che consente la connettività SSH in entrata sulla porta TCP 22 da qualsiasi . Puoi scegliere un intervallo di indirizzi IP di origine più restrittivo regola; Ad esempio, puoi specificare solo gli intervalli di indirizzi IP del sistema che avvii sessioni SSH. Questo esempio utilizza il tag target allow-ssh.

gcloud

1. Crea la regola firewall fw-allow-ssh per consentire la connettività SSH a VM con il tag di rete allow-ssh. Se ometti source-ranges, Google Cloud interpreta la regola nel significato che Fonte.

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

   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 utilizzi il suo 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:

     curl 10.1.2.99
     

     curl 10.1.3.99
     

     Per il test HTTPS, sostituisci curl con:

     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
     

     Il flag -k fa sì che curl salti la convalida dei certificati.

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

     curl service.example.com
     

Eseguire 100 richieste e verificare che siano con bilanciamento del carico

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:

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

Testa failover

1. Verifica il failover ai backend in REGION_A di regione quando i backend REGION_B regioni sono in stato non integro o non raggiungibile. Simuliamo questo processo rimuovendo tutti backend di 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 tramite SSH a una VM client in REGION_B.

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

3. Invia richieste all'indirizzo IP con bilanciamento del carico nella Regione REGION_B. L'output comando mostra le risposte delle VM di backend in 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
   }
   

Opzioni di configurazione aggiuntive

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

Utilizzo di una maschera URL

Quando si crea un NEG serverless, invece di selezionare una specifica servizio Cloud Run, puoi utilizzare una maschera URL per puntare di più servizi nello stesso dominio. Una maschera per l'URL è un modello Schema dell'URL. Il NEG serverless utilizza questo modello per estrarre il servizio dell'URL della richiesta in arrivo e mappa la richiesta al completamente gestito di Google Cloud.

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

Se non lo hai già fatto, assicurati di leggere il documento Serverless NEGS panoramica: URL Maschere.

Creare una maschera URL

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

1. Rimuovi http o https dall'URL. Non hai più 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 segnaposto <service>. Se l'istanza di Cloud Run servizio è associato a un tag, sostituisci il nome del tag con il segnaposto <tag>. In questo esempio, la maschera dell'URL rimane example.com/<service>.

3. (Facoltativo) Se il nome del servizio può essere estratti dalla porzione del percorso dell'URL, il dominio può essere omesso. La del percorso della maschera dell'URL non viene dalla prima barra (/). Se non è presente una barra (/) nella Maschera URL, questa maschera può rappresentare solo l'host. Pertanto, per in questo esempio, la maschera URL può essere ridotta a /<service>.

   Analogamente, se è possibile estrarre <service> dalla parte host dell'istruzione URL, puoi omettere del tutto il percorso dalla maschera URL.

   Puoi anche omettere qualsiasi componente di host o di sottodominio che precede il primo segnaposto come nonché tutti i componenti del percorso successivi all'ultimo segnaposto. In tale nei casi d'uso, 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 denominato example.com e tutti i tuoi servizi Cloud Run sono in fase di mappatura a questo dominio.

Servizio, nome tag	URL di dominio personalizzato Cloud Run	Maschera URL
servizio: accesso	https://login-home.example.com/web	<service>-home.example.com
servizio: accesso	https://example.com/login/web	example.com/&lt;service&gt; o /<service>
service: login, tag: test	https://test.login.example.com/web	&lt;tag&gt;.&lt;service&gt;.example.com
service: login, tag: test	https://example.com/home/login/test	example.com/home/&lt;service&gt;/&lt;tag&gt; o /home/<servizio>/<tag>
service: login, tag: test	https://test.example.com/home/login/web	&lt;tag&gt;.example.com/home/&lt;service&gt;

Creazione di un NEG serverless con una maschera URL

Console

Per un nuovo bilanciatore del carico, puoi utilizzare lo stesso processo end-to-end di descritti in precedenza in questo documento. Quando configuri il servizio di backend, invece di selezionare un servizio specifico, inserisci una maschera URL.

Se hai già un bilanciatore del carico, 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 di URL a un servizio di backend esistente, procedi nel seguente modo:

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 contenente il servizio di backend che che vuoi modificare.
3. Nella pagina Dettagli 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 del servizio di backend che desideri modificare.
6. Fai clic su Aggiungi backend.
7. Seleziona Crea gruppo di endpoint di rete serverless.
1. In Nome, inserisci helloworld-serverless-neg.
2. In Regione, viene visualizzata la regione del bilanciatore del carico.
3. In Tipo di gruppo di endpoint di rete serverless, Cloud Run è la supportato solo il tipo di gruppo di endpoint di rete.
1. Seleziona Utilizza maschera URL.
2. Inserisci una maschera per l'URL. Per informazioni su come creare una maschera URL, consulta Realizzazione di una maschera URL.
3. Fai clic su Crea.
8. In Nuovo backend, fai clic su Fine.
9. Fai clic su Aggiorna.

gcloud

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

Per fare in modo che più regole di forwarding interno condividano lo stesso indirizzo IP interno, devi prenotare l'indirizzo IP e impostare il 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 opzioni che usano un indirizzo IP comune. Per ulteriori informazioni, consulta la sezione Configurazione reindirizzamento da HTTP a HTTPS per bilanciatori del carico delle applicazioni interni.

Configura i criteri di routing del DNS

Se i tuoi clienti 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 della rete. Inoltre, consente di configurare una soluzione di bilanciamento del carico globale e basata su DNS che offre resilienza contro le interruzioni regionali. Per ulteriori informazioni, vedi Gestire i criteri di routing DNS e i controlli di integrità.

gcloud

Per creare una voce DNS con un TTL di 30 secondi, utilizza la 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: nome DNS o di dominio del set di record

  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 effettuando una richiesta POST alla Metodo ResourceRecordSets.create. Sostituisci PROJECT_ID con il tuo 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 gli outlier rilevamento sui servizi di backend globali per identificare i NEG serverless in stato non integro e ridurre numerare le richieste inviate ai NEG serverless in stato non integro.

Il rilevamento outlier viene attivato nel servizio di backend utilizzando uno dei seguenti metodi:

• Il metodo consecutiveErrors (outlierDetection.consecutiveErrors), in che un codice di stato HTTP della serie 5xx viene classificato come errore.
• Il metodo consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), in cui solo 502, I codici di stato HTTP 503 e 504 vengono considerati un errore.

Utilizza i seguenti passaggi per abilitare il rilevamento di outlier per un backend esistente completamente gestito di Google Cloud. Tieni presente che anche dopo aver abilitato il rilevamento outlier, alcune richieste possono essere inviato al servizio non integro e restituisce un codice di stato 5xx a con i clienti. Per ridurre ulteriormente la percentuale di errori, puoi configurare modelli per i parametri di rilevamento outlier. Per ulteriori informazioni, consulta 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 eseguire il servizio di backend modifica.

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

4. Nella pagina Modifica il bilanciatore del carico delle applicazioni interno tra regioni, fai clic su Configurazione backend.

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

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

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

8. Fai clic su Modifica per configurare il rilevamento degli outlier.

   Verifica che le seguenti opzioni siano configurate con questi valori:

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

   In questo esempio, l'analisi del rilevamento di outlier viene eseguita ogni secondo. Se Il numero di codici di stato HTTP 5xx consecutivi ricevuto da un Il proxy Envoy è pari o superiore a cinque, l'endpoint di backend viene escluso dalla di bilanciamento del carico del proxy Envoy per 30 secondi. Quando la percentuale di applicazione è impostata al 100%, il servizio di backend applica esclusione di endpoint in stato non integro dai rispettivi pool di bilanciamento del carico proxy Envoy specifici ogni volta che viene eseguita l'analisi del rilevamento outlier. Se sono soddisfatte le condizioni di espulsione, fino al 50% degli endpoint di backend il pool di bilanciamento del carico può essere escluso.

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 di servizio di backend.

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

   In questo esempio, l'analisi del rilevamento di outlier viene eseguita ogni secondo. Se Il numero di codici di stato HTTP 5xx consecutivi ricevuto da un Il proxy Envoy è pari o superiore a cinque, l'endpoint di backend viene escluso dalla di bilanciamento del carico del proxy Envoy per 30 secondi. Quando la percentuale di applicazione è impostata al 100%, il servizio di backend applica esclusione di endpoint in stato non integro dai rispettivi pool di bilanciamento del carico proxy Envoy specifici ogni volta che viene eseguita l'analisi del rilevamento outlier. Se sono soddisfatte le condizioni di espulsione, fino al 50% degli endpoint di backend il pool di bilanciamento del carico può essere escluso.

   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 backend servizio
   • PROJECT_ID: l'ID del progetto
   • REGION_A e REGION_B: e 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 l'ultima configurazione.

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

   Il rilevamento outlier è ora abilitato nel servizio di backend.

Eliminazione di un NEG serverless

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

Console

1. Per assicurarti che il NEG serverless che vuoi eliminare non sia in uso da un servizio di backend, vai alla scheda Servizi di backend Pagina Componenti di bilanciamento del carico.
   Vai a Servizi di backend
2. Se il NEG serverless è in uso, segui questi passaggi:
1. Fai clic sul nome del servizio di backend che utilizza il NEG serverless.
2. Fai clic su Modifica.
3. Nell'elenco Backend, fai clic su per rimuovere il NEG serverless di backend 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

• Esegui il deployment di un bilanciatore del carico delle applicazioni interno con Cloud Run utilizzando Terraform
• Eseguire la pulizia di una configurazione di bilanciamento del carico
• Esegui il deprovisioning di un VPC condiviso
• Logging e monitoraggio del bilanciatore del carico delle applicazioni interno
• Risolvere i problemi relativi ai bilanciatori del carico delle applicazioni interni