Questo documento mostra come eseguire il deployment di un bilanciatore del carico delle applicazioni interno tra regioni con Cloud Run. Per configurarlo, utilizza un backend NEG serverless per il bilanciatore del carico.
I NEG serverless 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 tra regioni offre ridondanza, in modo che, se una regione non è raggiungibile, il traffico venga automaticamente dirottato su un'altra regione. In base alla posizione di Envoy, il traffico proxy viene distribuito ai servizi Cloud Run come segue:
- Se i servizi Cloud Run su più regioni sono configurati nella stessa regione di Envoy, è preferibile il NEG che si trova nella stessa regione di Envoy. Il traffico viene inviato alla regione di failover solo se il rilevamento di outlier è abilitato e il NEG locale non è integro.
- Se i servizi Cloud Run in più regioni non sono configurati nella stessa regione di Envoy, il traffico viene distribuito uniformemente tra tutti i NEG. I NEG situati più vicino non sono preferiti.
- Se Identity-Aware Proxy è abilitato, è supportato un solo NEG serverless. Tuttavia, puoi configurare servizi Cloud Run aggiuntivi, ma il bilanciatore del carico non vi invia traffico.
Prima di iniziare
Prima di seguire questa guida, acquisisci familiarità con quanto segue:
- Panoramica del bilanciatore del carico delle applicazioni interno, inclusa la sezione Limitazioni
- Regole firewall VPC
- Panoramica dei gruppi di endpoint di rete serverless
esegui il deployment di un servizio Cloud Run
Le istruzioni 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 il traffico in entrata a internal
. Il traffico proveniente dal bilanciatore del carico delle applicazioni interno è considerato traffico interno.
Collocare il servizio Cloud Run in più regioni aiuta a prevenire gli errori in un'unica 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 del 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 una rete in un progetto. Devi essere un proprietario o un editor del progetto oppure devi disporre di tutti i seguenti ruoli IAM di Compute Engine.
Attività | Ruolo richiesto |
---|---|
Crea reti, subnet e componenti del bilanciatore del carico | Amministratore rete Compute |
Aggiungi e rimuovi regole firewall | Amministratore sicurezza Compute |
Creare istanze | Amministratore istanze Compute |
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:
Come mostrato nel diagramma, questo esempio crea un Application Load Balancer interno tra regioni 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 come segue:
Una rete VPC con le seguenti subnet:
- Subnet
SUBNET_A
e una subnet solo proxy inREGION_A
. - Subnet
SUBNET_B
e una subnet solo proxy inREGION_B
.
Devi creare subnet solo proxy in ogni regione di una rete VPC in cui utilizzi Application Load Balancer interni tra regioni. La subnet solo proxy della regione è condivisa tra tutti gli Application Load Balancer interni tra regioni della 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 principali pari a10.129.0.0/23
e perREGION_B
ha un intervallo di indirizzi IP principali pari a10.130.0.0/23
, che corrisponde alla dimensione consigliata della subnet.- Subnet
Una regola firewall che consente i flussi di traffico di subnet solo proxy nella rete. Ciò significa che viene aggiunta una regola che consente il traffico delle porte TCP
80
,443
e8080
da10.129.0.0/23
e10.130.0.0/23
(l'intervallo delle subnet solo proxy in questo esempio).Un'altra regola firewall per i probe del controllo di integrità.
Una configurazione ad alta disponibilità con backend serverless per i deployment di Cloud Run nelle regioni
REGION_A
eREGION_B
. Se i backend in un'area geografica sono inattivi, il traffico non viene eseguito verso l'altra.Un servizio di backend globale che monitora l'utilizzo e l'integrità dei backend. Assicurati di abilitare il rilevamento outlier sul servizio di backend.
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.
Un proxy HTTP o HTTPS di destinazione globale, che riceve una richiesta dall'utente e la inoltra alla mappa degli URL. Per HTTPS, configura una risorsa certificato SSL a livello di regione. Il proxy di destinazione utilizza il certificato SSL per decriptare il traffico SSL se configuri il bilanciamento del carico HTTPS. Il proxy di destinazione può inoltrare il traffico alle istanze tramite HTTP o HTTPS.
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 nella stessa regione. Tieni presente le seguenti condizioni:
- L'indirizzo IP può provenire (ma non è necessario) 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 suGLOBAL_MANAGED_PROXY
. - Se vuoi utilizzare lo stesso indirizzo IP interno con più regole di forwarding, imposta il flag
--purpose
dell'indirizzo IP suSHARED_LOADBALANCER_VIP
.
Facoltativo: configura i criteri di routing DNS di tipo
GEO
per instradare il traffico client al VIP del bilanciatore del carico nella regione più vicina al client.
Configurare 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, la regione e le subnet:
Rete. La rete è una rete VPC in modalità personalizzata denominata
NETWORK
.Subnet per i backend. Una subnet denominata
SUBNET_A
nella regioneREGION_A
utilizza10.1.2.0/24
come intervallo IP principale. La subnet denominataSUBNET_A
nella regioneREGION_B
utilizza10.1.3.0/24
come intervallo IP principale.Subnet per i proxy. Una subnet denominata
PROXY_SN_A
nella regioneREGION_A
utilizza10.129.0.0/23
come intervallo IP principale. Una subnet denominataPROXY_SN_B
nella regioneREGION_B
utilizza10.130.0.0/23
come intervallo IP principale.
È 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 bilanciatore del carico.
Configura le subnet di backend
Console
Nella console Google Cloud, vai alla pagina Reti VPC.
Fai clic su Crea rete VPC.
Specifica un nome per la rete.
Nella sezione Subnet, imposta Modalità di creazione subnet su Personalizzata.
Crea una subnet per i backend del bilanciatore del carico. Nella sezione Nuova subnet, inserisci le informazioni seguenti:
- Specifica un nome per la subnet.
- Seleziona una regione: REGION_A
- Inserisci un intervallo di indirizzi IP:
10.1.2.0/24
Fai clic su Fine.
Fai clic su Aggiungi subnet.
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
Fai clic su Fine.
Fai clic su Crea.
gcloud
Crea la rete VPC personalizzata con il comando
gcloud compute networks create
:gcloud compute networks create NETWORK --subnet-mode=custom
Crea una subnet nella rete
NETWORK
nella regioneREGION_A
con il comandogcloud compute networks subnets create
:gcloud compute networks subnets create SUBNET_A \ --network=NETWORK \ --range=10.1.2.0/24 \ --region=REGION_A
Crea una subnet nella rete
NETWORK
nella regioneREGION_B
con il comandogcloud 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 a livello di regione basati su Envoy nella stessa regione della rete VPC. Può esistere 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 sulla pagina Bilanciamento del carico.
Se vuoi creare subito una subnet solo proxy, segui questi passaggi:
Nella console Google Cloud, vai alla pagina Reti VPC.
- Fai clic sul nome della rete VPC.
- Nella scheda Subnet, fai clic su Aggiungi subnet.
- Specifica un nome per la subnet solo proxy.
- Nell'elenco Regione, seleziona REGION_A.
- Nell'elenco Scopo, seleziona Proxy gestito tra regioni.
- Nel campo Intervallo di indirizzi IP, inserisci
10.129.0.0/23
. - Fai clic su Aggiungi.
Crea la subnet solo proxy in REGION_B
- Fai clic su Aggiungi subnet.
- Specifica un nome per la subnet solo proxy.
- Nell'elenco Regione, seleziona REGION_B.
- Nell'elenco Scopo, seleziona Proxy gestito tra regioni.
- Nel campo Intervallo di indirizzi IP, inserisci
10.130.0.0/23
. - 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 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
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 che passa dal bilanciatore del carico ai backend NEG serverless utilizza route speciali definite all'esterno del VPC che non sono soggette alle regole firewall. Pertanto, 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
Nella console Google Cloud, vai alla pagina Bilanciamento del carico.
- Fai clic su Crea bilanciatore del carico.
- In Tipo di bilanciatore del carico, seleziona Bilanciatore del carico delle applicazioni (HTTP/HTTPS) e fai clic su Avanti.
- In Pubblico o interno, seleziona Interno e fai clic su Avanti.
- Per Deployment tra regioni o regioni singole, seleziona Ideale per carichi di lavoro tra regioni e fai clic su Avanti.
- Fai clic su Configura.
Configurazione di base
- Specifica un nome per il bilanciatore del carico.
- In Rete, seleziona NETWORK.
Configura il frontend con due regole di forwarding
Per HTTP:
- Fai clic su Configurazione frontend.
- Specifica un nome per la regola di forwarding.
- Nell'elenco Regione subnet, seleziona REGION_A.
Prenota una subnet solo proxy
- Nell'elenco Subnet, seleziona SUBNET_A.
- 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.
- Fai clic su Fine.
- Per aggiungere la seconda regola di forwarding, fai clic su Aggiungi IP e porta frontend.
- Specifica un nome per la regola di forwarding.
- Nell'elenco Regione subnet, seleziona REGION_B.
Prenota una subnet solo proxy
- Nell'elenco Subnet, seleziona SUBNET_B.
- 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.
- 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 all-regions
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, collegalo 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 seguente documentazione:
Esegui il deployment di un certificato autogestito a livello di regione.
- Fai clic su Configurazione frontend.
- Specifica un nome per la regola di forwarding.
- Nel campo Protocollo, seleziona
HTTPS (includes HTTP/2)
. - Verifica che la porta sia impostata su
443
. - Nell'elenco Regione subnet, seleziona REGION_A.
Prenota una subnet solo proxy
- Nell'elenco Subnet, seleziona SUBNET_A.
- 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.
- Nella sezione Aggiungi certificato, seleziona il certificato.
- (Facoltativo) Per aggiungere certificati oltre al certificato SSL principale:
- Fai clic su Aggiungi certificato.
- Seleziona il certificato dall'elenco.
- Seleziona un criterio SSL dall'elenco dei criteri SSL. Se non hai creato alcun criterio SSL, viene applicato un criterio Google Cloud SSL predefinito.
- Fai clic su Fine.
- Specifica un nome per la configurazione del frontend.
- Nel campo Protocollo, seleziona
HTTPS (includes HTTP/2)
. - Verifica che la porta sia impostata su
443
. - Nell'elenco Regione subnet, seleziona REGION_B.
Prenota una subnet solo proxy
- Nell'elenco Subnet, seleziona SUBNET_B.
- 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.
- Nella sezione Aggiungi certificato, seleziona il certificato.
- (Facoltativo) Per aggiungere certificati oltre al certificato SSL principale:
- Fai clic su Aggiungi certificato.
- Seleziona il certificato dall'elenco.
- Seleziona un criterio SSL dall'elenco dei criteri SSL. Se non hai creato alcun criterio SSL, viene applicato un criterio Google Cloud SSL predefinito.
- Fai clic su Fine.
- Fai clic su Configurazione backend.
- Nell'elenco Crea o seleziona servizi di backend, fai clic su Crea un servizio di backend.
- Specifica un nome per il servizio di backend.
- In Protocollo, seleziona HTTP.
- In Porta denominata, inserisci
http
. - Nell'elenco Tipo di backend, seleziona Gruppo di endpoint di rete serverless.
- 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.
- Fai clic su Regole di routing.
- In Modalità, seleziona Regola host e percorso semplice.
- Assicurati che esista un solo servizio di backend per qualsiasi host senza corrispondenza e qualsiasi percorso senza corrispondenza.
- Fai clic su Esamina e finalizza.
- Rivedi le impostazioni di configurazione del bilanciatore del carico.
- Fai clic su Crea.
Aggiungi la seconda configurazione di frontend:
Configurare le regole di routing
Esamina la configurazione
gcloud
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
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
Crea la mappa degli URL con il comando
gcloud compute url-maps create
.gcloud compute url-maps create gil7-map \ --default-service=gil7-backend-service \ --global
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, collegalo 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:
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_CERT \ --certificate-file=$LB_PRIVATE_KEY \ –-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
Crea due regole di forwarding: una con un VIP (
10.1.2.99
) nella regioneREGION_B
e un'altra con un VIP (10.1.3.99
) nella regioneREGION_A
.Per le reti personalizzate, devi fare riferimento alla subnet nella regola di forwarding. Tieni presente che questa è la subnet dell'istanza della 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 l'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 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
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. L'esempio seguente mostra come eseguire questa operazione con Python.
Crea il proxy HTTPS di destinazione effettuando una richiesta POST
al metodo 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
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 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 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. In questo esempio viene utilizzato il tag di destinazione allow-ssh
.
gcloud
Crea la regola firewall
fw-allow-ssh
per consentire la connettività SSH alle VM con il tag di reteallow-ssh
. Se omettisource-ranges
, Google Cloud interpreta la regola in modo che indichi 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à
Crea una VM client:
gcloud compute instances create l7-ilb-client-a \ --image-family=debian-10 \ --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-10 \ --image-project=debian-cloud \ --network=NETWORK \ --subnet=SUBNET_B \ --zone=ZONE_B \ --tags=allow-ssh
Connettiti tramite SSH a ogni istanza client.
gcloud compute ssh l7-ilb-client-a \ --zone=ZONE_A
gcloud compute ssh l7-ilb-client-b \ --zone=ZONE_B
Verifica che l'indirizzo IP fornisca il 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 pubblicato la richiesta:
curl 10.1.2.99
curl 10.1.3.99
Per i 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 ignori la convalida del certificato.(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 il failover
Verifica il failover ai backend nell'area geografica
REGION_A
quando i backend nelle regioniREGION_B
non sono integri o non raggiungibili. Simuliamo questa operazione rimuovendo tutti i backend daREGION_B
:gcloud compute backend-services remove-backend gil7-backend-service \ --network-endpoint-group=gl7ilb-serverless-neg-b \ --network-endpoint-group-zone=ZONE_B
Connettiti tramite SSH a una VM client in
REGION_B
.gcloud compute ssh l7-ilb-client-b \ --zone=ZONE_B
Invia le richieste all'indirizzo IP con bilanciamento del carico nella regione
REGION_B
. L'output comando visualizza le risposte delle VM di backend inREGION_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 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 operano 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 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 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 lo hai già fatto, assicurati di leggere la panoramica sui 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 in https://example.com/login
. Questo è l'URL in cui viene pubblicato il servizio login
dell'app.
- Rimuovi
http
ohttps
dall'URL.example.com/login
è rimasto. - 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 al servizio Cloud Run è associato un tag, sostituisci il nome del tag con il segnaposto<tag>
. In questo esempio, la maschera URL che ti rimane èexample.com/<service>
.
- Cloud Run: sostituisci il nome del servizio Cloud Run con il segnaposto
(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 si distingue dal primo carattere barra (
/
). Se nella maschera URL non è presente una barra (/
), la maschera rappresenta solo l'host. Pertanto, per questo esempio, la maschera URL può essere ridotta a/<service>
.Allo stesso modo, se
<service>
può essere estratto dalla parte host dell'URL, puoi omettere del tutto il percorso dalla maschera dell'URL.Puoi anche omettere tutti i componenti host o sottodomini che precedono il primo segnaposto, nonché tutti i componenti del percorso che seguono l'ultimo segnaposto. In questi casi, il segnaposto acquisisce le informazioni richieste per il componente.
Ecco alcuni esempi che dimostrano queste regole:
Questa tabella presuppone che tu abbia un dominio personalizzato denominato example.com
e che tutti i tuoi servizi Cloud Run siano stati mappati a questo dominio.
Servizio, nome tag | URL del dominio personalizzato Cloud Run | Maschera URL |
---|---|---|
service: login | https://login-home.example.com/web | <servizio>-home.example.com |
service: login | https://example.com/login/web | example.com/<service> o /<service> |
service: accesso, tag: test | https://test.login.example.com/web | <tag>.<servizio>.example.com |
service: accesso, tag: test | https://example.com/home/login/test | example.com/home/<service>/<tag> o /home/<service>/<tag> |
service: accesso, tag: test | https://test.example.com/home/login/web | <tag>.example.com/home/<servizio> |
Creazione di un NEG serverless con una maschera URL
Console
Per un nuovo bilanciatore del carico, puoi utilizzare lo stesso processo end-to-end descritto in precedenza in questo documento. Quando configuri il servizio di backend, anziché 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 punto 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:
- Nella console Google Cloud, vai alla pagina Bilanciamento del carico.
Vai a Bilanciamento del carico - Fai clic sul nome del bilanciatore del carico contenente il servizio di backend che vuoi modificare.
- Nella pagina Dettagli del bilanciatore del carico, fai clic su Modifica.
- Nella pagina Modifica bilanciatore del carico delle applicazioni esterno globale, fai clic su Configurazione backend.
- Nella pagina Configurazione backend, fai clic su Modifica in corrispondenza del servizio di backend che vuoi modificare.
- Fai clic su Aggiungi backend.
- Seleziona Crea gruppo di endpoint di rete serverless.
- In Nome, inserisci
helloworld-serverless-neg
. - In Regione, viene visualizzata la regione del bilanciatore del carico.
- In Tipo di gruppo di endpoint di rete serverless, Cloud Run è l'unico tipo di gruppo di endpoint di rete supportato.
- Seleziona Utilizza maschera URL.
- Inserisci una maschera per l'URL. Per informazioni su come creare una maschera URL, consulta la sezione Costruire una maschera URL.
- Fai clic su Crea.
- In Nuovo backend, fai clic su Fine.
- Fai clic su Update (Aggiorna).
gcloud
Per creare un NEG serverless con una maschera URL di esempio 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
Configura i criteri di routing DNS
Se i tuoi clienti si trovano in più regioni, ti consigliamo di rendere accessibile il bilanciatore del carico delle applicazioni interno tra regioni utilizzando i VIP in queste regioni. Questa configurazione per più regioni 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 offra resilienza contro le interruzioni regionali. Per maggiori informazioni, consulta Gestire i controlli di integrità e i criteri di routing DNS.
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
: nome DNS o di dominio del set di recordAd esempio,
service.example.com
REGION_A
eREGION_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": "gil7-forwarding-rule-a", "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": "gil7-forwarding-rule-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 abilitare il rilevamento di outlier sui servizi di backend globali per identificare i NEG serverless integri e ridurre il numero di richieste inviate ai NEG serverless in stato non integro.
Il rilevamento outlier viene abilitato sul servizio di backend tramite uno dei seguenti metodi:
- Il metodo
consecutiveErrors
(outlierDetection.consecutiveErrors
), in cui un codice di stato HTTP della serie5xx
viene classificato come errore. - Il metodo
consecutiveGatewayFailure
(outlierDetection.consecutiveGatewayFailure
), in cui solo i codici di stato HTTP502
,503
e504
vengono considerati come errori.
Segui i passaggi riportati di seguito per abilitare il rilevamento di outlier per un servizio di backend esistente. Tieni presente che, anche dopo aver abilitato il rilevamento di outlier, alcune richieste possono essere inviate al servizio in stato non integro e restituire un codice di stato 5xx
ai client. Per ridurre ulteriormente la percentuale di errori, puoi configurare valori più restrittivi per i parametri di rilevamento outlier. Per ulteriori informazioni, consulta il campo outlierDetection
.
Console
Nella console Google Cloud, vai alla pagina Bilanciamento del carico.
Fai clic sul nome del bilanciatore del carico di cui vuoi modificare il servizio di backend.
Nella pagina Dettagli del bilanciatore del carico, fai clic su
Modifica.Nella pagina Modifica bilanciatore del carico delle applicazioni interno tra regioni, fai clic su Configurazione backend.
Nella pagina Configurazione backend, fai clic su
Modifica per il servizio di backend che vuoi modificare.Scorri verso il basso ed espandi la sezione Configurazioni avanzate.
Nella sezione Rilevamento outlier, seleziona la casella di controllo Abilita.
Fai clic su
Modifica per configurare il rilevamento outlier.Verifica che le seguenti opzioni siano configurate con questi valori:
Proprietà Valore Errori consecutivi 5 Intervallo 1000 Tempo di espulsione base 30000 Percentuale di espulsione massima 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 5, l'endpoint di backend viene espulso dal pool di bilanciamento del carico di quel proxy Envoy per 30 secondi. Se la percentuale di applicazione è impostata al 100%, il servizio di backend applica l'esclusione di endpoint non integri dai pool di bilanciamento del carico di quei proxy Envoy specifici ogni volta che viene eseguita l'analisi del rilevamento dei outlier. Se le condizioni di espulsione sono soddisfatte, è possibile escludere fino al 50% degli endpoint di backend dal pool di bilanciamento del carico.Fai clic su Salva.
Per aggiornare il servizio di backend, fai clic su Aggiorna.
Per aggiornare il bilanciatore del carico, nella pagina Modifica il bilanciatore del carico delle applicazioni interno tra regioni, fai clic su Aggiorna.
gcloud
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.Modifica la configurazione YAML del servizio di backend per aggiungere i campi per il rilevamento outlier, come evidenziato nella seguente configurazione YAML.
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 5, l'endpoint di backend viene espulso dal pool di bilanciamento del carico di quel proxy Envoy per 30 secondi. Se la percentuale di applicazione è impostata al 100%, il servizio di backend applica l'esclusione di endpoint non integri dai pool di bilanciamento del carico di quei proxy Envoy specifici ogni volta che viene eseguita l'analisi del rilevamento dei outlier. Se le condizioni di espulsione sono soddisfatte, è possibile escludere fino al 50% degli endpoint di 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 backendPROJECT_ID
: l'ID del progettoREGION_A
eREGION_B
: le regioni in cui è stato configurato il bilanciatore del carico.SERVERLESS_NEG_NAME
: il nome del primo NEG serverlessSERVERLESS_NEG_NAME_2
: il nome del secondo NEG serverless
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
Impossibile eliminare un gruppo di endpoint di rete se è collegato a un servizio di backend. Prima di eliminare un NEG, assicurati che sia scollegato dal servizio di backend.
Console
- Per assicurarti che il NEG serverless che vuoi eliminare non sia utilizzato da nessun servizio di backend, vai alla scheda Servizi di backend nella pagina Componenti di bilanciamento del carico.
Vai a Servizi di backend - Se il NEG serverless è in uso, segui questi passaggi:
- Fai clic sul nome del servizio di backend che utilizza il NEG serverless.
- Fai clic su Modifica.
- Nell'elenco di Backend, fai clic su per rimuovere il backend NEG serverless dal servizio di backend.
- Fai clic su Salva.
- Vai alla pagina Gruppo di endpoint di rete nella console Google Cloud.
Vai al Gruppo di endpoint di rete - Seleziona la casella di controllo relativa al NEG serverless da eliminare.
- Fai clic su Elimina.
- 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
- Pulisci una configurazione del bilanciamento del carico
- Eseguire il deprovisioning del VPC condiviso
- Logging e monitoraggio del bilanciatore del carico delle applicazioni interno
- Risolvere i problemi relativi ai bilanciatori del carico delle applicazioni interni