Un servizio di backend definisce la modalità di distribuzione del traffico di Cloud Load Balancing. La configurazione del servizio di backend contiene un insieme di valori, ad esempio il protocollo utilizzato per connettersi ai backend, varie impostazioni di distribuzione e sessione, controlli di integrità e timeout. Queste impostazioni forniscono un controllo granulare sul comportamento del bilanciatore del carico. Per iniziare, la maggior parte delle impostazioni ha valori predefiniti che consentono una configurazione rapida. Un servizio di backend ha ambito globale o regionale.
I bilanciatori del carico, i proxy Envoy e i client gRPC senza proxy utilizzano le informazioni di configurazione nella risorsa del servizio di backend per:
- Indirizza il traffico ai backend corretti, ovvero gruppi di istanze o gruppi di endpoint di rete (NEG).
- Distribuisci il traffico in base a una modalità di bilanciamento, che è un'impostazione per ogni backend.
- Determina quale controllo di integrità monitora l'integrità dei backend.
- Specifica l'affinità sessione.
- Determina se sono attivati altri servizi, inclusi i seguenti
servizi disponibili solo per determinati bilanciatori
del carico:
- Cloud CDN
- Criteri di sicurezza di Google Cloud Armor
- Identity-Aware Proxy
- Designa i servizi di backend globali e regionali come servizio nelle applicazioni App Hub.
Questi valori vengono impostati quando crei un servizio di backend o aggiungi un backend al servizio di backend.
La tabella seguente riepiloga i bilanciatori del carico che utilizzano i servizi di backend. Il prodotto che utilizzi determina anche il numero massimo di servizi di backend, l'ambito di un servizio di backend, il tipo di backend supportati e lo schema di bilanciamento del carico del servizio di backend. Lo schema di bilanciamento del carico è un identificatore che Google utilizza per classificare le regole di forwarding e i servizi di backend. Ogni prodotto di bilanciamento del carico utilizza uno schema di bilanciamento del carico per le regole di forwarding e i servizi di backend. Alcuni schemi sono condivisi tra i prodotti.
| Prodotto | Numero massimo di servizi di backend | Ambito del servizio di backend | Tipi di backend supportati | Schema di bilanciamento del carico |
|---|---|---|---|---|
| Bilanciatore del carico delle applicazioni esterno globale | Multiplo | Globale | Ogni servizio di backend supporta una delle seguenti combinazioni di backend:
|
EXTERNAL_MANAGED |
| Bilanciatore del carico delle applicazioni classico | Multiplo | Globale3 | Ogni servizio di backend supporta una delle seguenti combinazioni di backend:
|
ESTERNA4 |
| Bilanciatore del carico delle applicazioni esterno regionale | Multiplo | Regionale | Ogni servizio di backend supporta una delle seguenti combinazioni di backend:
|
EXTERNAL_MANAGED |
| Bilanciatore del carico delle applicazioni interno tra regioni | Multiplo | Globale | Ogni servizio di backend supporta una delle seguenti combinazioni di backend:
|
INTERNAL_MANAGED |
| Bilanciatore del carico delle applicazioni interno regionale | Multiplo | Regionale | Ogni servizio di backend supporta una delle seguenti combinazioni di backend:
|
INTERNAL_MANAGED |
| Bilanciatore del carico di rete proxy esterno globale | 1 | Globale3 | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
EXTERNAL_MANAGED |
| Bilanciatore del carico di rete proxy classico | 1 | Globale3 | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
EXTERNAL |
| Bilanciatore del carico di rete proxy esterno regionale | Senza route TLS: 1 Con le route TLS: più |
Regionale | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
EXTERNAL_MANAGED |
| Bilanciatore del carico di rete proxy interno regionale | Senza route TLS: 1 Con le route TLS: più |
Regionale | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
INTERNAL_MANAGED |
| Bilanciatore del carico di rete proxy interno tra regioni | Senza route TLS: 1 Con le route TLS: più |
Globale | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
INTERNAL_MANAGED |
| Bilanciatore del carico di rete passthrough esterno globale | 1 | Globale | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
EXTERNAL_PASSTHROUGH |
| Bilanciatore del carico di rete passthrough esterno regionale | 1 | Regionale | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
EXTERNAL |
| Bilanciatore del carico di rete passthrough interno | 1 | Regionale, ma configurabile per essere accessibile a livello globale | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
INTERNAL |
| Cloud Service Mesh | Multiplo | Globale | Ogni servizio di backend supporta una delle seguenti combinazioni di backend:
|
INTERNAL_SELF_MANAGED |
- La regola di forwarding e il relativo indirizzo IP esterno sono regionali.
- Tutti i backend connessi al servizio di backend devono trovarsi nella stessa regione della regola di forwarding.
EXTERNAL_MANAGED servizi di backend a
EXTERNAL regole di forwarding. Tuttavia, i servizi di backend EXTERNAL non possono essere collegati alle regole di forwarding EXTERNAL_MANAGED.
Per usufruire delle nuove funzionalità disponibili
solo con il bilanciatore del carico delle applicazioni esterno globale, ti
consigliamo di eseguire la migrazione delle risorse EXTERNAL esistenti a
EXTERNAL_MANAGED utilizzando la procedura di migrazione descritta in
Eseguire la migrazione
delle risorse dal bilanciatore del carico delle applicazioni esterno classico a quello globale.
Denominazione del bilanciatore del carico
Per i bilanciatori del carico di rete proxy e i bilanciatori del carico di rete passthrough, il nome del bilanciatore del carico è sempre uguale al nome del servizio di backend. Il comportamento per ogni Google Cloud interfaccia è il seguente:
- ConsoleGoogle Cloud . Se crei un bilanciatore del carico di rete proxy o un bilanciatore del carico di rete passthrough utilizzando la console Google Cloud , al servizio di backend viene assegnato automaticamente lo stesso nome che hai inserito per il nome del bilanciatore del carico.
- Google Cloud CLI o API. Se crei un bilanciatore del carico di rete proxy o un bilanciatore del carico di rete pass-through utilizzando l'interfaccia a riga di comando gcloud o l'API, inserisci un nome a tua scelta durante la creazione del servizio di backend. Il nome di questo servizio di backend viene poi visualizzato nella console Google Cloud come nome del bilanciatore del carico.
Per scoprire di più sul funzionamento della denominazione per i bilanciatori del carico delle applicazioni, consulta Panoramica delle mappe URL: denominazione del bilanciatore del carico.
Backend
Un backend è uno o più endpoint che ricevono traffico da un bilanciatore del carico Google Cloud, da un proxy Envoy configurato con Cloud Service Mesho da un client gRPC senza proxy. Esistono diversi tipi di backend:
- Un gruppo di istanze contenente istanze di macchine virtuali (VM). Un gruppo di istanze può essere un gruppo di istanze gestite (MIG), con o senza scalabilità automatica, oppure può essere un gruppo di istanze non gestite. Più di un servizio di backend può fare riferimento a un gruppo di istanze, ma tutti i servizi di backend che fanno riferimento al gruppo di istanze devono utilizzare modalità di bilanciamento compatibili. Per ulteriori informazioni, consulta la sezione Restrizioni e indicazioni per i gruppi di istanze di questo documento.
- NEG a livello di zona
- NEG serverless
- NEG Private Service Connect
- NEG internet
- NEG connettività ibrida
- NEG mappatura porte
- Service Directory service bindings (anteprima)
- Backend del servizio pubblicati (anteprima)
Non puoi eliminare un gruppo di istanza di backend o un NEG associato a un servizio di backend. Prima di eliminare un gruppo di istanze o un NEG, devi prima rimuoverlo come backend da tutti i servizi di backend che vi fanno riferimento.
Gruppi di istanze
Questa sezione descrive il funzionamento dei gruppi di istanze con il servizio di backend.
VM di backend e indirizzi IP esterni
Le VM di backend nei servizi di backend non richiedono indirizzi IP esterni:
Per i bilanciatori del carico delle applicazioni esterni globali e i bilanciatori del carico di rete proxy esterni: i client comunicano con un Google Front End (GFE) di primo livello che ospita l'indirizzo IP esterno del bilanciatore del carico. Il GFE del primo livello comunica con un GFE del secondo livello, che si trova nella stessa regione della VM o dell'endpoint di backend. Ogni GFE di secondo livello comunica con le VM o gli endpoint di backend in base alle seguenti regole:
Interfaccia di rete con bilanciamento del carico: l'interfaccia di rete a cui il GFE di secondo livello invia il traffico delle richieste dipende dal tipo di gruppo di backend:
Per i backend dei gruppi di istanze, il bilanciatore del carico distribuisce sempre i pacchetti all'interfaccia
nic0di ogni VM di backend. Questa regola è valida anche se la VM ha più interfacce di rete nella stessa rete VPC o in reti VPC diverse.Per i backend NEG di zona
GCE_VM_IP_PORT, il bilanciatore del carico distribuisce i pacchetti all'interfaccia di rete a cui è associato l'indirizzo IP dell'endpoint. Per le VM di backend con più interfacce di rete, l'interfaccia di rete può trovarsi in qualsiasi rete VPC, ad eccezione di quanto segue: se una VM di backend ha la sua interfaccianic0e una o più interfacce nonnic0nella stessa rete VPC, il bilanciatore del carico distribuisce i pacchetti solo all'interfaccia di retenic0dall'insieme di interfacce di rete nella stessa rete VPC.
Indirizzo IP di destinazione sull'interfaccia con bilanciamento del carico: GFE di secondo livello invia il traffico di richiesta i cui pacchetti hanno i seguenti indirizzi IP di destinazione:
Per i backend dei gruppi di istanze, la destinazione del pacchetto è l'indirizzo IPv4 interno primario dell'interfaccia di rete
nic0o il primo indirizzo IPv6/128dell'intervallo IPv6/96assegnato all'interfaccianic0, a seconda della policy di selezione degli indirizzi IP del servizio di backend e del tipo di stack dell'interfaccia di rete.Per i backend NEG zonali
GCE_VM_IP_PORT, la destinazione del pacchetto corrisponde a un indirizzo IP endpoint specificato nel NEG, a seconda del tipo di stack dell'interfaccia di rete e della policy di selezione dell'indirizzo IP del servizio di backend. Per gli indirizzi IP endpoint validi, consulta NEG con endpointGCE_VM_IP_PORT. Se una VM di backend ha la sua interfaccianic0e una o più interfacce nonnic0nella stessa rete VPC, dall'insieme di interfacce di rete nella stessa rete VPC puoi specificare solo un indirizzo IP endpoint associato all'interfaccia di retenic0.
La comunicazione tra i GFE di secondo livello e i backend è facilitata tramite route speciali.
Per i bilanciatori del carico delle applicazioni esterni regionali e i bilanciatori del carico di rete proxy esterni regionali: i client comunicano con un proxy Envoy gestito che ospita l'indirizzo IP esterno del bilanciatore del carico. Il proxy Envoy si trova in una subnet solo proxy. Ogni proxy Envoy comunica con le VM o gli endpoint di backend in base alle seguenti regole:
Interfaccia di rete con bilanciamento del carico: l'interfaccia di rete a cui il proxy Envoy invia il traffico delle richieste dipende dal tipo di gruppo di backend:
Per i backend dei gruppi di istanze, il bilanciatore del carico distribuisce sempre i pacchetti all'interfaccia
nic0di ogni VM di backend. Questa regola è valida anche se la VM ha più interfacce di rete nella stessa rete VPC o in reti VPC diverse.Per i backend NEG di zona
GCE_VM_IP_PORT, il bilanciatore del carico distribuisce i pacchetti all'interfaccia di rete a cui è associato l'indirizzo IP dell'endpoint. Per le VM di backend con più interfacce di rete, l'interfaccia di rete può trovarsi in qualsiasi rete VPC, ad eccezione di quanto segue: se una VM di backend ha la sua interfaccianic0e una o più interfacce nonnic0nella stessa rete VPC, il bilanciatore del carico distribuisce i pacchetti solo all'interfaccia di retenic0dall'insieme di interfacce di rete nella stessa rete VPC.
Indirizzo IP di destinazione sull'interfaccia con bilanciamento del carico: il proxy Envoy invia traffico di richieste i cui pacchetti hanno i seguenti indirizzi IP di destinazione:
Per i backend dei gruppi di istanze, la destinazione del pacchetto è l'indirizzo IPv4 interno primario dell'interfaccia di rete
nic0o il primo indirizzo IPv6/128dell'intervallo IPv6/96assegnato all'interfaccianic0, a seconda della policy di selezione degli indirizzi IP del servizio di backend e del tipo di stack dell'interfaccia di rete.Per i backend NEG zonali
GCE_VM_IP_PORT, la destinazione del pacchetto corrisponde a un indirizzo IP endpoint specificato nel NEG, a seconda del tipo di stack dell'interfaccia di rete e della policy di selezione dell'indirizzo IP del servizio di backend. Per gli indirizzi IP endpoint validi, consulta NEG con endpointGCE_VM_IP_PORT. Se una VM di backend ha la sua interfaccianic0e una o più interfacce nonnic0nella stessa rete VPC, dall'insieme di interfacce di rete nella stessa rete VPC puoi specificare solo un indirizzo IP endpoint associato all'interfaccia di retenic0.
Per i bilanciatori del carico di rete passthrough esterni globali e regionali: i client comunicano direttamente con i backend utilizzando l'infrastruttura Maglev di Google. I pacchetti vengono instradati e consegnati ai backend con gli indirizzi IP di origine e destinazione originali conservati. Il bilanciatore del carico distribuisce i pacchetti a una delle seguenti interfacce di rete:
Per i bilanciatori del carico di rete passthrough esterni globali con backend di gruppi di istanze, il bilanciatore del carico distribuisce sempre i pacchetti all'interfaccia
nic0. Per saperne di più, consulta Backend dei gruppi di istanze e interfacce di rete.Per i bilanciatori del carico di rete passthrough esterni globali con backend NEG
GCE_VM_IP, il bilanciatore del carico recapita i pacchetti all'interfaccia di rete che si trova nella subnet associata al NEG. Per saperne di più, consulta Backend NEG di zona e interfacce di rete.Per i bilanciatori del carico di rete passthrough esterni regionali basati su servizi di backend con backend di gruppi di istanze, il bilanciatore del carico distribuisce sempre i pacchetti all'interfaccia
nic0. Per saperne di più, consulta Backend dei gruppi di istanze e interfacce di rete.Per i bilanciatori del carico di rete passthrough esterni regionali basati su servizio di backend di backend con backend NEG
GCE_VM_IP, il bilanciatore del carico distribuisce i pacchetti all'interfaccia di rete che si trova nella subnet associata al NEG. Per saperne di più, consulta Backend NEG di zona e interfacce di rete.Per i bilanciatori del carico di rete passthrough esterni regionali basati su pool di destinazione, il bilanciatore del carico distribuisce sempre i pacchetti all'interfaccia
nic0.Se una VM di backend ha la sua interfaccia
nic0e una o più interfacce nonnic0nella stessa rete VPC, il bilanciatore del carico distribuisce i pacchetti solo all'interfaccia di retenic0dall'insieme di interfacce di rete nella stessa rete VPC.
Per i bilanciatori del carico di rete passthrough interni: i client comunicano direttamente con i backend utilizzando lo stack di virtualizzazione di rete Andromeda. I pacchetti vengono instradati e recapitati ai backend con gli indirizzi IP di origine e di destinazione originali conservati. Per i backend dei gruppi di istanze e i backend NEG, il bilanciatore del carico distribuisce i pacchetti a un'interfaccia di rete nella rete VPC del servizio di backend:
GCE_VM_IPLa rete VPC del servizio di backend può essere specificata in modo esplicito oppure può essere ereditata dal primo gruppo di istanza di backend o NEG aggiunto al servizio di backend o dalla prima regola di forwarding che fa riferimento al servizio di backend. Per saperne di più, consulta la specifica della rete di servizi di backend.
Se una VM di backend ha la sua interfaccia
nic0e una o più interfacce nonnic0nella stessa rete VPC, il bilanciatore del carico distribuisce i pacchetti solo all'interfaccia di retenic0dall'insieme di interfacce di rete nella stessa rete VPC.
Porte denominate
L'attributo porta denominata del servizio di backend è applicabile solo ai bilanciatori del carico basati su proxy (bilanciatori del carico delle applicazioni e bilanciatori del carico di rete proxy) che utilizzano backend di gruppi di istanze. La porta denominata definisce la porta di destinazione utilizzata per la connessione TCP tra il proxy (GFE o Envoy) e l'istanza di backend.
Le porte denominate sono configurate nel seguente modo:
Su ogni backend del gruppo di istanze, devi configurare una o più porte denominate utilizzando coppie chiave-valore. La chiave rappresenta un nome di porta significativo che scegli, mentre il valore rappresenta il numero di porta che assegni al nome. La mappatura dei nomi ai numeri viene eseguita singolarmente per ogni backend del gruppo di istanze.
Nel servizio di backend, specifica una singola porta denominata utilizzando solo il nome della porta (
--port-name).
In base al backend di ogni gruppo di istanze, il servizio di backend traduce il nome della porta in un numero di porta. Quando la porta denominata di un gruppo di istanze corrisponde a --port-name del servizio di backend, quest'ultimo utilizza questo numero di porta per la comunicazione con le VM del gruppo di istanze.
Ad esempio, puoi impostare la porta denominata su un gruppo di istanze con il nome
my-service-name e la porta 8888:
gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
--named-ports=my-service-name:8888
Poi fai riferimento alla porta denominata nella configurazione del servizio di backend con
--port-name impostato su my-service-name nel servizio di backend:
gcloud compute backend-services update my-backend-service \
--port-name=my-service-name
Un servizio di backend può utilizzare un numero di porta diverso quando comunica con le VM in gruppi di istanze diversi se ogni gruppo di istanze specifica un numero di porta diverso per lo stesso nome di porta.
Il numero di porta risolto utilizzato dal servizio di backend del bilanciatore del carico proxy non deve corrispondere al numero di porta utilizzato dalle regole di forwarding del bilanciatore del carico. Un bilanciatore del carico proxy è in attesa di connessioni TCP inviate all'indirizzo IP e alla porta di destinazione delle relative regole di forwarding. Poiché il proxy apre una seconda connessione TCP ai suoi backend, la porta di destinazione della seconda connessione TCP può essere diversa.
Le porte denominate sono applicabili solo ai backend dei gruppi di istanze. I NEG di zona con endpoint GCE_VM_IP_PORT, i NEG ibridi con endpoint NON_GCP_PRIVATE_IP_PORT e i NEG internet definiscono le porte utilizzando un meccanismo diverso, ovvero sugli endpoint stessi. I NEG serverless fanno riferimento ai servizi Google e i NEG PSC ai service attachment utilizzando astrazioni che non prevedono la specifica di una porta di destinazione.
I bilanciatori del carico di rete passthrough interni e i bilanciatori del carico di rete passthrough esterni regionali non utilizzano porte denominate. Questo perché sono bilanciatori del carico pass-through che instradano le connessioni direttamente ai backend anziché crearne di nuove. I pacchetti vengono inviati ai backend mantenendo l'indirizzo IP e la porta di destinazione della regola di forwarding del bilanciatore del carico.
Per scoprire come creare porte denominate, segui queste istruzioni:
- Gruppi di istanze non gestite: utilizzo di porte denominate
- Gruppi di istanze gestite: assegnazione di porte denominate a gruppi di istanze gestite
Limitazioni e indicazioni per i gruppi di istanze
Quando utilizzi i backend del gruppo di istanze, tieni presente quanto segue:
Un'istanza VM può appartenere a un solo gruppo di istanze con bilanciamento del carico. Ad esempio, una VM può far parte di due gruppi di istanze non gestite oppure di un gruppo di istanze gestite e di un gruppo di istanze non gestite. Quando una VM è membro di due o più gruppi di istanze, solo uno dei gruppi di istanze può essere referenziato da uno o più servizi di backend del bilanciatore del carico.
Lo stesso gruppo di istanze può essere utilizzato da due o più servizi di backend. Ogni mapping tra un gruppo di istanze e un servizio di backend può utilizzare una modalità di bilanciamento diversa, ad eccezione delle combinazioni di modalità di bilanciamento incompatibili.
Le combinazioni di modalità di bilanciamento incompatibili sono le seguenti:
La modalità di bilanciamento
UTILIZATIONnon è compatibile con tutte le altre modalità di bilanciamento. Se un gruppo di istanze è un backend di più servizi di backend, deve utilizzare la modalità di bilanciamentoUTILIZATIONsu ogni servizio di backend.La modalità di bilanciamento
CUSTOM_METRICSnon è compatibile con tutte le altre modalità di bilanciamento. Se un gruppo di istanze è un backend di più servizi di backend, deve utilizzare la modalità di bilanciamentoCUSTOM_METRICSsu ogni servizio di backend.
A causa delle combinazioni di modalità di bilanciamento incompatibili, se un gruppo di istanze utilizza la modalità di bilanciamento
UTILIZATIONoCUSTOM_METRICScome backend per almeno un servizio di backend, lo stesso gruppo di istanze non può essere utilizzato come backend per il bilanciatore del carico di rete passthrough interno e il bilanciatore del carico di rete passthrough esterno regionale. Questo perché i backend dei gruppi di istanze dei bilanciatori del carico di rete passthrough regionali (bilanciatore del carico di rete passthrough interno e bilanciatore del carico di rete passthrough esterno regionale) utilizzanoCONNECTIONcome modalità di bilanciamento.
Non esiste un singolo comando che possa modificare la modalità di bilanciamento dello stesso gruppo di istanze su più servizi di backend. Se un gruppo di istanze è un backend per due o più servizi di backend e le relative modalità di bilanciamento devono essere aggiornate a una nuova modalità incompatibile con quella attuale, puoi utilizzare la seguente tecnica:
- Rimuovi il gruppo di istanze come backend da tutti i servizi di backend, tranne uno.
- Modifica la modalità di bilanciamento del gruppo di istanze per l'unico servizio di backend rimanente.
- Aggiungi di nuovo il gruppo di istanze come backend agli altri servizi di backend.
Prendi in esame le seguenti best practice, che offrono opzioni più flessibili:
Evita di utilizzare lo stesso gruppo di istanze come backend per due o più servizi di backend. Utilizza invece più NEG.
A differenza dei gruppi di istanze, una VM può avere un endpoint in due o più NEG con bilanciamento del carico.
Ad esempio, se una VM deve essere contemporaneamente un backend di un bilanciatore del carico di rete passthrough e di un bilanciatore del carico di rete proxy o di un bilanciatore del carico delle applicazioni, utilizza più NEG con bilanciamento del carico. Inserisci un endpoint VM in un NEG univoco compatibile con ogni tipo di bilanciatore del carico. Poi associa ogni NEG al servizio di backend del bilanciatore del carico corrispondente.
Non aggiungere un gruppo di istanze gestite con scalabilità automatica a più di un servizio di backend quando utilizzi la metrica di scalabilità automatica Utilizzo del bilanciamento del carico HTTP. Due o più servizi di backend che fanno riferimento allo stesso gruppo di istanze gestite con scalabilità automatica possono contraddirsi a vicenda, a meno che la metrica di scalabilità automatica non sia correlata all'attività del bilanciatore del carico.
Gruppi di endpoint di rete a livello di zona
Gli endpoint di rete rappresentano i servizi in base al loro indirizzo IP o a una combinazione di indirizzo IP e porta, anziché fare riferimento a una VM in un gruppo di istanze. Un gruppo di endpoint di rete (NEG) è un raggruppamento logico di endpoint di rete.
I NEG di zona sono risorse di zona che rappresentano raccolte di indirizzi IP o combinazioni di indirizzi IP e porte per risorseGoogle Cloud all'interno di una singola subnet.
Un servizio di backend che utilizza i NEG di zona come backend distribuisce il traffico tra le applicazioni o i container in esecuzione all'interno delle VM.
Sono disponibili due tipi di endpoint di rete per i NEG zonali:
endpoint
GCE_VM_IPsupportati da tutti i bilanciatori del carico passthrough, ad eccezione dei bilanciatori del carico di rete passthrough esterni regionali basati su pool di destinazione.endpoint
GCE_VM_IP_PORTsupportati da tutti i bilanciatori del carico basati su proxy (bilanciatori del carico delle applicazioni e bilanciatori del carico di rete proxy) e da Cloud Service Mesh.
Per vedere quali prodotti supportano i backend NEG zonali, consulta la tabella Servizi di backend e tipi di backend supportati.
Per maggiori dettagli, vedi Panoramica dei NEG di zona.
Gruppi di endpoint di rete internet
I NEG internet sono risorse che definiscono i backend esterni. Un backend esterno è un backend ospitato all'interno di un'infrastruttura on-premise o su un'infrastruttura fornita da terze parti.
Un NEG internet è una combinazione di un nome host o un indirizzo IP, più una porta facoltativa. Esistono due tipi di endpoint di rete disponibili per i NEG internet: INTERNET_FQDN_PORT e INTERNET_IP_PORT.
Per maggiori dettagli, consulta la panoramica del gruppo di endpoint di rete internet.
Gruppi di endpoint di rete serverless
Un gruppo di endpoint di rete (NEG) specifica un gruppo di endpoint di backend per un bilanciatore del carico. Un NEG serverless è un backend che punta a una risorsa Cloud Run, App Engine, Cloud Run Functions o API Gateway.
Un NEG serverless può rappresentare uno dei seguenti elementi:
- Una risorsa Cloud Run o un gruppo di risorse.
- Una funzione Cloud Run o un gruppo di funzioni (in precedenza Cloud Run Functions2ª generazionen.).
- Una funzione Cloud Run (1ª generazione.) o un gruppo di funzioni
- Un'app dell'ambiente standard di App Engine o dell'ambiente flessibile di App Engine, un servizio specifico all'interno di un'app, una versione specifica di un'app o un gruppo di servizi.
- Un API Gateway che fornisce l'accesso ai tuoi servizi tramite un'API REST coerente in tutti i servizi, indipendentemente dall'implementazione del servizio. Questa funzionalità è in anteprima.
Per configurare un NEG serverless per applicazioni serverless che condividono un pattern URL, utilizza una maschera
URL. Una maschera URL
è un modello dello schema URL (ad esempio, example.com/<service>). Il
NEG serverless utilizzerà questo modello per estrarre il nome <service> dall'URL
della richiesta in entrata e indirizzare la richiesta al servizio
Cloud Run, Cloud Run Functions o App Engine
corrispondente con lo stesso nome.
Per vedere quali bilanciatori del carico supportano i backend NEG serverless, consulta la tabella: servizi di backend e tipi di backend supportati.
Per saperne di più sui NEG serverless, consulta la panoramica dei gruppi di endpoint di rete serverless.
Associazioni dei servizi Service Directory
Un'associazione dei servizi Service Directory è una risorsa di backend che stabilisce una connessione tra un servizio di backend in Cloud Service Mesh e un servizio registrato in Service Directory. Un servizio di backend può fare riferimento a diverse associazioni dei servizi Service Directory. Tuttavia, un servizio di backend con un'associazione di servizi Service Directory non può fare riferimento a nessun altro tipo di risorsa di backend. Per saperne di più, consulta Integrazione di Cloud Service Mesh con Service Directory.
Backend del servizio pubblicato
Se le reti VPC producer e consumer appartengono alla stessa organizzazione, puoi accedere a un servizio pubblicato utilizzando i backend del servizio pubblicato. I backend dei servizi pubblicati consentono di configurare bilanciatori del carico supportati o Cloud Service Mesh per instradare il traffico ai servizi pubblicati tramite gli endpoint Private Service Connect. Per instradare il traffico al servizio pubblicato, associa un servizio di backend regionale a un collegamento del servizio. Questa configurazione è nota come backend del servizio pubblicato.
Questi backend forniscono una connettività unificata consentendo ai bilanciatori del carico supportati e a Cloud Service Mesh di condividere gli endpoint Private Service Connect. Questa connessione viene stabilita fornendo un riferimento al collegamento al servizio del producer. I backend di servizio pubblicati consentono anche la gestione e l'osservabilità avanzate del traffico, ad esempio l'applicazione di policy di sicurezza centralizzate e la raccolta di metriche centralizzate.
Per ulteriori informazioni su come configurare i backend dei servizi pubblicati per i bilanciatori del carico, consulta Accedere ai servizi pubblicati tramite backend ed endpoint dei servizi pubblicati.
Backend misti
Quando aggiungi diversi tipi di backend a un singolo servizio di backend, si applicano le seguenti considerazioni sull'utilizzo:
- Un singolo servizio di backend non può utilizzare contemporaneamente gruppi di istanze e NEG a livello di zona.
- Puoi utilizzare una combinazione di diversi tipi di gruppi di istanze nello stesso servizio di backend. Ad esempio, un singolo servizio di backend può fare riferimento a una combinazione di gruppi di istanze gestite e non gestite. Per informazioni complete sui backend compatibili con i servizi di backend, consulta la tabella nella sezione precedente.
- Con alcuni bilanciatori del carico proxy, puoi utilizzare una combinazione di NEG di zona
(con endpoint
GCE_VM_IP_PORT) e NEG di connettività ibrida (con endpointNON_GCP_PRIVATE_IP_PORT) per configurare il bilanciamento del carico ibrido. Per vedere quali bilanciatori del carico hanno questa funzionalità, consulta la tabella: servizi di backend e tipi di backend supportati.
Protocollo per i backend
Quando crei un servizio di backend, devi specificare il protocollo utilizzato per comunicare con i backend. Puoi specificare un solo protocollo per servizio di backend. Non puoi specificare un protocollo secondario da utilizzare come fallback.
I protocolli validi dipendono dal tipo di bilanciatore del carico o dal fatto che tu stia utilizzando Cloud Service Mesh.
| Famiglia di prodotti | Opzioni di protocollo del servizio di backend |
|---|---|
| Bilanciatore del carico delle applicazioni | HTTP, HTTPS, HTTP/2 |
| Bilanciatore del carico di rete proxy | TCP o SSL I bilanciatori del carico di rete proxy regionali supportano solo TCP. |
| Bilanciatore del carico di rete passthrough esterno globale | NON SPECIFICATO |
| Bilanciatore del carico di rete passthrough regionale | TCP, UDP o UNSPECIFIED |