Panoramica del bilanciatore del carico delle applicazioni interno

Questo documento introduce i concetti che devi comprendere per configurare i bilanciatori del carico delle applicazioni interni.

Un Google Cloud bilanciatore del carico delle applicazioni interno è un bilanciatore del carico di livello 7 basato su proxy che ti consente di eseguire e scalare i servizi dietro un singolo indirizzo IP interno. Il bilanciatore del carico delle applicazioni interno distribuisce il traffico HTTP e HTTPS ai backend ospitati su una serie di piattaforme come Compute Engine, Google Kubernetes Engine (GKE) e Cloud Run. Google Cloud Per maggiori dettagli, vedi Casi d'uso.

Modalità di funzionamento

Puoi configurare un bilanciatore del carico delle applicazioni interno nelle seguenti modalità:

• Bilanciatore del carico delle applicazioni interno tra regioni. Si tratta di un bilanciatore del carico multiregionale implementato come servizio gestito basato sul proxy Envoy open source. La modalità tra regioni consente di bilanciare il carico del traffico verso i servizi di backend distribuiti a livello globale, inclusa la gestione del traffico che contribuisce a garantire che il traffico venga indirizzato al backend più vicino. Questo bilanciatore del carico consente anche l'alta disponibilità. Il posizionamento dei backend in più regioni consente di evitare guasti in una singola regione. Se i backend di una regione non funzionano, il traffico può essere reindirizzato a un'altra regione.

• Bilanciatore del carico delle applicazioni interno regionale. Si tratta di un bilanciatore del carico regionale implementato come servizio gestito basato sul proxy Envoy open source. La modalità regionale richiede che i backend si trovino in una singola regione Google Cloud . I client possono essere limitati a quella regione o possono trovarsi in qualsiasi regione, a seconda che l'accesso globale sia disattivato o attivato nella regola di forwarding. Questo bilanciatore del carico è abilitato con funzionalità avanzate di controllo del traffico basate sui parametri HTTP o HTTPS. Al termine della configurazione, il bilanciatore del carico alloca automaticamente i proxy Envoy per soddisfare le tue esigenze di traffico.

  La seguente tabella descrive le differenze importanti tra le modalità regionale e cross-region:

  Funzionalità	Bilanciatore del carico delle applicazioni interno tra regioni	Bilanciatore del carico delle applicazioni interno regionale
  Indirizzo IP virtuale (VIP) del bilanciatore del carico.	Allocato da una subnet in una regione Google Cloud specifica. Gli indirizzi VIP di più regioni possono condividere lo stesso servizio di backend globale. Puoi configurare il bilanciamento del carico globale basato su DNS utilizzando i criteri di routing DNS per instradare le richieste dei client all'indirizzo VIP più vicino.	Allocato da una subnet in una regione Google Cloud specifica.
  Accesso client	Sempre accessibile a livello globale. I client di qualsiasi Google Cloud regione in un VPC possono inviare traffico al bilanciatore del carico.	Non accessibile a livello globale per impostazione predefinita. Facoltativamente, puoi abilitare l'accesso globale.
  Backend con bilanciamento del carico	Backend globali. Il bilanciatore del carico può inviare il traffico ai backend in qualsiasi regione.	Backend regionali. Il bilanciatore del carico può inviare traffico solo ai backend che si trovano nella stessa regione del proxy del bilanciatore del carico.
  Alta disponibilità e failover	Failover automatico ai backend integri nella stessa regione o in regioni diverse.	Failover automatico ai backend integri nella stessa regione.

Identificare la modalità

Architettura e risorse

Il seguente diagramma mostra le risorse Google Cloud richieste per i bilanciatori del carico delle applicazioni interni:

Per il deployment di un bilanciatore del carico delle applicazioni interno sono necessarie le seguenti risorse:

Subnet solo proxy

Nel diagramma precedente, la subnet solo proxy fornisce un insieme di indirizzi IP che Google utilizza per eseguire i proxy Envoy per tuo conto. Devi creare una subnet solo proxy in ogni regione di una rete VPC in cui utilizzi bilanciatori del carico delle applicazioni interni.

La seguente tabella descrive le differenze tra le subnet solo proxy nelle modalità regionale e cross-region:

Modalità del bilanciatore del carico	Valore del flag --purpose della subnet solo proxy
Bilanciatore del carico delle applicazioni interno tra regioni	GLOBAL_MANAGED_PROXY I bilanciatori del carico regionali e tra regioni diverse non possono condividere le stesse subnet Il bilanciatore del carico basato su Envoy tra regioni deve avere una subnet solo proxy in ogni regione in cui è configurato. I proxy del bilanciatore del carico tra regioni nella stessa regione e rete condividono la stessa subnet solo proxy.
Bilanciatore del carico delle applicazioni interno regionale	REGIONAL_MANAGED_PROXY I bilanciatori del carico regionali e tra regioni diverse non possono condividere le stesse subnet Tutti i bilanciatori del carico basati su Envoy a livello di regione in una regione e nella rete VPC condividono la stessa subnet solo proxy

Inoltre:

• Le subnet solo proxy vengono utilizzate solo per i proxy Envoy, non per i backend.
• Le VM o gli endpoint di backend di tutti i bilanciatori del carico delle applicazioni interni in una regione e nella rete VPC ricevono connessioni dalla subnet solo proxy.
• L'indirizzo IP virtuale di un bilanciatore del carico delle applicazioni interno non si trova nella subnet solo proxy. L'indirizzo IP del bilanciatore del carico è definito dalla regola di forwarding interna gestita, descritta di seguito.

Regola di forwarding e indirizzo IP

Le regole di forwarding instradano il traffico in base a indirizzo IP, porta e protocollo a una configurazione di bilanciamento del carico costituita da un proxy di destinazione e un servizio di backend.

Specifica dell'indirizzo IP. Ogni regola di forwarding fa riferimento a un singolo indirizzo IP regionale che puoi utilizzare nei record DNS per la tua applicazione. Puoi prenotare un indirizzo IP statico da utilizzare o lasciare che Cloud Load Balancing ne assegni uno per te. Ti consigliamo di prenotare un indirizzo IP statico; in caso contrario, devi aggiornare il record DNS con l'indirizzo IP temporaneo appena assegnato ogni volta che elimini una regola di forwarding e ne crei una nuova.

I client utilizzano l'indirizzo IP e la porta per connettersi ai proxy Envoy del bilanciatore del carico. L'indirizzo IP della regola di forwarding è l'indirizzo IP del bilanciatore del carico (a volte chiamato indirizzo IP virtuale o VIP). I client che si connettono a un bilanciatore del carico devono utilizzare HTTP versione 1.1 o successive. Per l'elenco completo dei protocolli supportati, consulta Funzionalità del bilanciatore del carico.

L'indirizzo IP interno associato alla regola di forwarding può provenire da una subnet nella stessa rete e regione dei backend.

Specifica della porta. Ogni regola di forwarding per un bilanciatore del carico delle applicazioni può fare riferimento a una singola porta compresa tra 1 e 65535. Per supportare più porte, devi configurare più regole di forwarding. Puoi configurare più regole di forwarding per utilizzare lo stesso indirizzo IP interno (VIP) e per fare riferimento allo stesso proxy HTTP o HTTPS di destinazione, a condizione che la combinazione complessiva di indirizzo IP, porta e protocollo sia univoca per ogni regola di forwarding. In questo modo, puoi utilizzare un singolo bilanciatore del carico con una mappa URL condivisa come proxy per più applicazioni.

Il tipo di regola di forwarding, indirizzo IP e schema di bilanciamento del carico utilizzati dai bilanciatori del carico delle applicazioni interni dipendono dalla modalità del bilanciatore del carico.

Modalità del bilanciatore del carico	Regola di forwarding, indirizzo IP e subnet solo proxy --purpose	Routing dal client al frontend del bilanciatore del carico
Bilanciatore del carico delle applicazioni interno tra regioni	Regola di forwarding globale Indirizzi IP regionali Schema di bilanciamento del carico: INTERNAL_MANAGED Subnet solo proxy --purpose: GLOBAL_MANAGED_PROXY Indirizzo IP --purpose: SHARED_LOADBALANCER_VIP	L'accesso globale è abilitato per impostazione predefinita per consentire ai client di qualsiasi regione in un VPC di accedere al bilanciatore del carico. I backend possono trovarsi in più regioni.
Bilanciatore del carico delle applicazioni interno regionale	Regola di inoltro regionale Indirizzo IP regionale Schema di bilanciamento del carico: INTERNAL_MANAGED Subnet solo proxy --purpose: REGIONAL_MANAGED_PROXY Indirizzo IP --purpose: SHARED_LOADBALANCER_VIP	Puoi abilitare l'accesso globale per consentire ai client di qualsiasi regione di un VPC di accedere al tuo bilanciatore del carico. I backend devono trovarsi anche nella stessa regione del bilanciatore del carico.

Regole di forwarding e reti VPC

Questa sezione descrive come le regole di forwarding utilizzate dai bilanciatori del carico delle applicazioni interni sono associate alle reti VPC.

Modalità del bilanciatore del carico	Associazione di rete VPC
Bilanciatore del carico delle applicazioni interno tra regioni Bilanciatore del carico delle applicazioni interno regionale	Gli indirizzi IPv4 interni a livello di regione esistono sempre all'interno delle reti VPC. Quando crei la regola di forwarding, devi specificare la subnet da cui viene preso l'indirizzo IP interno. Questa subnet deve trovarsi nella stessa regione e nella stessa rete VPC in cui è stata creata una subnet solo proxy. Pertanto, esiste un'associazione di rete implicita.

Proxy di destinazione

Un proxy HTTP o HTTPS di destinazione termina le connessioni HTTP(S) dai client. Il proxy HTTP(S) consulta la mappa URL per determinare come instradare il traffico ai backend. Un proxy HTTPS di destinazione utilizza un certificato SSL per autenticarsi presso i client.

Il bilanciatore del carico conserva l'intestazione Host della richiesta del client originale. Il bilanciatore del carico aggiunge anche due indirizzi IP all'intestazione X-Forwarded-For:

• L'indirizzo IP del client che si connette al bilanciatore del carico
• L'indirizzo IP della regola di forwarding del bilanciatore del carico

Se nella richiesta in entrata non è presente un'intestazione X-Forwarded-For, questi due indirizzi IP costituiscono l'intero valore dell'intestazione. Se la richiesta ha un'intestazione X-Forwarded-For, altre informazioni, come gli indirizzi IP registrati dai proxy durante il percorso verso il bilanciatore del carico, vengono conservate prima dei due indirizzi IP. Il bilanciatore del carico non verifica gli indirizzi IP che precedono gli ultimi due indirizzi IP in questa intestazione.

Se esegui un proxy come server di backend, questo proxy in genere aggiunge più informazioni all'intestazione X-Forwarded-For e il tuo software potrebbe doverle prendere in considerazione. Le richieste inviate tramite proxy dal bilanciatore del carico provengono da un indirizzo IP nella subnet solo proxy e il proxy sull'istanza di backend potrebbe registrare questo indirizzo, nonché l'indirizzo IP dell'istanza di backend.

A seconda del tipo di traffico che la tua applicazione deve gestire, puoi configurare un bilanciatore del carico con un proxy HTTP di destinazione o un proxy HTTPS di destinazione.

La tabella seguente mostra le API proxy di destinazione richieste dai bilanciatori del carico delle applicazioni interni:

Modalità del bilanciatore del carico	Proxy di destinazione
Bilanciatore del carico delle applicazioni interno tra regioni	Globale targetHttpProxies Globale targetHttpsProxies
Bilanciatore del carico delle applicazioni interno regionale	regionTargetHttpProxies regionTargetHttpsProxies

Certificati SSL

I bilanciatori del carico delle applicazioni interni che utilizzano proxy HTTPS di destinazione richiedono chiavi private e certificati SSL nell'ambito della configurazione del bilanciatore del carico.

La tabella seguente specifica il tipo di certificati SSL richiesti dai bilanciatori del carico delle applicazioni interni in ogni modalità:

Modalità del bilanciatore del carico	Tipo di certificato SSL
Bilanciatore del carico delle applicazioni interno regionale	Certificati SSL regionali di Compute Engine Certificate Manager certificati autogestiti a livello di regione e certificati gestiti da Google. I seguenti tipi di certificati gestiti da Google sono supportati da Gestore certificati: Certificati gestiti a livello di regione da Google con autorizzazione DNS per progetto. Per saperne di più, vedi Eseguire il deployment di un certificato regionale gestito da Google. Certificati gestiti a livello di regione da Google con Certificate Authority Service privato. Per maggiori informazioni, vedi Eseguire il deployment di un certificato regionale gestito da Google con CA Service. I certificati gestiti da Google con l'autorizzazione del bilanciatore del carico non sono supportati.
Bilanciatore del carico delle applicazioni interno tra regioni	Certificate Manager certificati autogestiti e certificati gestiti da Google. I seguenti tipi di certificati gestiti da Google sono supportati da Gestore certificati: Autorizzazione DNS con DNS pubblico. Per maggiori informazioni, vedi Eseguire il deployment di un certificato globale gestito da Google con l'autorizzazione DNS. Servizio di autorità di certificazione privata. Per saperne di più, vedi Creare un certificato gestito da Google emesso dall'istanza di CA Service. I certificati gestiti da Google con l'autorizzazione del bilanciatore del carico non sono supportati. I certificati SSL di Compute Engine non sono supportati.

Mappe URL

Il proxy HTTP(S) di destinazione utilizza le mappe URL per determinare il routing in base agli attributi HTTP (come il percorso della richiesta, i cookie o le intestazioni). In base alla decisione di routing, il proxy inoltra le richieste del client a servizi di backend specifici. La mappa degli URL può specificare azioni aggiuntive da intraprendere, come la riscrittura delle intestazioni, l'invio di reindirizzamenti ai client e la configurazione di criteri di timeout (tra gli altri).

La tabella seguente specifica il tipo di mappa URL richiesto dai bilanciatori del carico delle applicazioni interni in ogni modalità:

Modalità del bilanciatore del carico	Tipo di mappa URL
Bilanciatore del carico delle applicazioni interno tra regioni	Mappe degli URL globali
Bilanciatore del carico delle applicazioni interno regionale	Mappe degli URL delle regioni

Servizio di backend

Un servizio di backend fornisce informazioni di configurazione al bilanciatore del carico in modo che possa indirizzare le richieste ai suoi backend, ad esempio gruppi di istanze Compute Engine o gruppi di endpoint di rete (NEG). Per ulteriori informazioni sui servizi di backend, consulta la Panoramica dei servizi di backend.

Ambito del servizio di backend

La tabella seguente indica la risorsa e l'ambito del servizio di backend utilizzati dai bilanciatori del carico delle applicazioni interni:

Modalità del bilanciatore del carico	Risorsa del servizio di backend
Bilanciatore del carico delle applicazioni interno tra regioni	backendServices (globale)
Bilanciatore del carico delle applicazioni interno regionale	regionBackendServices (regionale)

Protocollo per i backend

I servizi di backend per i bilanciatori del carico delle applicazioni devono utilizzare uno dei seguenti protocolli per inviare richieste ai backend:

• HTTP, che utilizza HTTP/1.1 e nessun protocollo TLS
• HTTPS, che utilizza HTTP/1.1 e TLS
• HTTP/2, che utilizza HTTP/2 e TLS (HTTP/2 senza crittografia non è supportato).
• H2C, che utilizza HTTP/2 su TCP. TLS non è richiesto. H2C non è supportato per i bilanciatori del carico delle applicazioni classici.

Il bilanciatore del carico utilizza solo il protocollo del servizio di backend specificato per comunicare con i backend. Il bilanciatore del carico non esegue il failover a un protocollo diverso se non riesce a comunicare con i backend utilizzando il protocollo del servizio di backend specificato.

Il protocollo del servizio di backend non deve corrispondere al protocollo utilizzato dai client per comunicare con il bilanciatore del carico. Ad esempio, i client possono inviare richieste al bilanciatore del carico utilizzando HTTP/2, ma il bilanciatore del carico può comunicare con i backend utilizzando HTTP/1.1 (HTTP o HTTPS).

Backend

La tabella seguente specifica le funzionalità di backend supportate dai bilanciatori del carico delle applicazioni interni in ogni modalità.

Modalità del bilanciatore del carico	Backend supportati su un servizio di backend1						Supporta i bucket di backend	Supporta Google Cloud Armor	Supporta Cloud CDN	Supporta IAP	Supporta le estensioni di servizio
	Gruppi di istanze2	Zonal NEGs3	NEG internet	NEG serverless	NEG ibride	NEG Private Service Connect
Bilanciatore del carico delle applicazioni interno tra regioni				Cloud Run
Bilanciatore del carico delle applicazioni interno regionale				Cloud Run

Backend e reti VPC

Le limitazioni relative alla posizione dei backend dipendono dal tipo di backend.

• Per i gruppi di istanze, i NEG di zona e i NEG di connettività ibrida, tutti i backend devono trovarsi nello stesso progetto e nella stessa regione del servizio di backend. Tuttavia, un bilanciatore del carico può fare riferimento a un backend che utilizza una rete VPC diversa nello stesso progetto del servizio di backend. La connettività tra la rete VPC del bilanciatore del carico e la rete VPC di backend può essere configurata utilizzando il peering di rete VPC, i tunnel Cloud VPN, i collegamenti VLAN di Cloud Interconnect o un framework Network Connectivity Center.

  Definizione della rete di backend

  • Per i NEG zonali e ibridi, specifica esplicitamente la rete VPC quando crei il NEG.
  • Per i gruppi di istanze gestite, la rete VPC è definita nel modello di istanza.
  • Per i gruppi di istanze non gestite, la rete VPC del gruppo di istanze è impostata in modo che corrisponda alla rete VPC dell'interfaccia nic0 per la prima VM aggiunta al gruppo di istanze.

  Requisiti di rete di backend

  La rete del backend deve soddisfare uno dei seguenti requisiti di rete:

  • La rete VPC del backend deve corrispondere esattamente alla rete VPC della regola di forwarding.

  • La rete VPC del backend deve essere connessa alla rete VPC della regola di forwarding tramite il peering di rete VPC. Devi configurare gli scambi di route di subnet per consentire la comunicazione tra la subnet solo proxy nella rete VPC della regola di forwarding e le subnet utilizzate dalle istanze o dagli endpoint di backend.

• Sia la rete VPC del backend sia la rete VPC della regola di forwarding devono essere raggi VPC collegati allo stesso hub Network Connectivity Center. I filtri di importazione ed esportazione devono consentire la comunicazione tra la subnet solo proxy nella rete VPC della regola di forwarding e le subnet utilizzate dalle istanze o dagli endpoint di backend.

• Per tutti gli altri tipi di backend, tutti i backend devono trovarsi nella stessa rete VPC e nella stessa regione.

Backend e interfacce di rete

Se utilizzi i backend dei gruppi di istanze, i pacchetti vengono sempre inviati a nic0. Se vuoi inviare pacchetti a interfacce non nic0 (vNIC o interfacce di rete dinamiche), utilizza i backend NEG.

Se utilizzi backend NEG a livello di zona, i pacchetti vengono inviati a qualsiasi interfaccia di rete rappresentata dall'endpoint nel NEG. Gli endpoint NEG devono trovarsi nella stessa rete VPC della rete VPC definita esplicitamente per il NEG.

Sottoinsieme del backend

Il sottoinsieme di backend è una funzionalità facoltativa supportata dai bilanciatori del carico delle applicazioni interni regionali che migliora le prestazioni e la scalabilità assegnando un sottoinsieme di backend a ciascuna delle istanze proxy.

Per impostazione predefinita, il sottoinsieme del backend è disattivato. Per informazioni sull'attivazione di questa funzionalità, consulta Impostazione secondaria del backend per i bilanciatori del carico delle applicazioni interni regionali.

Controlli di integrità

Ogni servizio di backend specifica un controllo di integrità che monitora periodicamente la disponibilità dei backend a ricevere una connessione dal bilanciatore del carico. In questo modo si riduce il rischio che le richieste vengano inviate a backend che non possono gestirle. I controlli di integrità non verificano se l'applicazione stessa funziona.

Affinché i probe del controllo di integrità vadano a buon fine, devi creare una regola firewall Ingress allow che consenta ai probe del controllo di integrità di raggiungere le tue istanze di backend. In genere, i probe di controllo di integrità provengono dal meccanismo di controllo di integrità centralizzato di Google. Tuttavia, per i NEG ibridi, i controlli di integrità hanno origine dalla subnet solo proxy. Per maggiori dettagli, vedi Controlli di integrità di Envoy distribuiti.

Protocollo di controllo di integrità

Sebbene non sia obbligatorio e non sia sempre possibile, è una best practice utilizzare un controllo di integrità il cui protocollo corrisponda al protocollo del servizio di backend. Ad esempio, un controllo di integrità HTTP/2 verifica con maggiore precisione la connettività HTTP/2 ai backend. Al contrario, i bilanciatori del carico delle applicazioni interni che utilizzano backend NEG ibridi non supportano i controlli di integrità gRPC. Per l'elenco dei protocolli di controllo di integrità supportati, consulta le funzionalità di bilanciamento del carico nella sezione Controlli di integrità.

La tabella seguente specifica l'ambito dei controlli di integrità supportati dai bilanciatori del carico delle applicazioni interni:

Modalità del bilanciatore del carico	Tipo di controllo di integrità
Bilanciatore del carico delle applicazioni interno tra regioni	Global
Bilanciatore del carico delle applicazioni interno regionale	A livello di regione

Per saperne di più sui controlli di integrità, consulta le seguenti risorse:

• Panoramica dei controlli di integrità
• Crea controlli di integrità

Regole firewall

Un bilanciatore del carico delle applicazioni interno richiede le seguenti regole firewall:

• Una regola di autorizzazione in entrata che consente il traffico dagli intervalli di controllo di integrità centrali di Google. Per saperne di più sugli intervalli di indirizzi IP specifici dei probe del controllo di integrità e sul motivo per cui è necessario consentire il traffico proveniente da questi intervalli, consulta Intervalli IP dei probe e regole firewall.
• Una regola di autorizzazione in entrata che consente il traffico dalla subnet solo proxy.

Esistono alcune eccezioni ai requisiti delle regole del firewall per questi intervalli:

• L'autorizzazione del traffico dagli intervalli di probe del controllo di integrità di Google non è obbligatoria per i NEG ibridi. Tuttavia, se utilizzi una combinazione di NEG ibridi e zonali in un unico servizio di backend, devi consentire il traffico dagli intervalli di probecontrollo di integritào dell'integrità di Google per i NEG zonali.
• Per i NEG internet a livello di regione, i controlli di integrità sono facoltativi. Il traffico proveniente dai bilanciatori del carico che utilizzano NEG internet regionali ha origine dalla subnet proxy-only e viene poi tradotto con NAT (utilizzando Cloud NAT) in indirizzi IP NAT allocati manualmente o automaticamente. Questo traffico include sia i probe del controllo di integrità sia le richieste degli utenti dal bilanciatore del carico ai backend. Per maggiori dettagli, vedi NEG regionali: utilizzare un gateway Cloud NAT.

Accesso client

I client possono trovarsi nella stessa rete o in una rete VPC connessa tramite peering di rete VPC.

Per i bilanciatori del carico delle applicazioni interni tra regioni, l'accesso globale è abilitato per impostazione predefinita. I client di qualsiasi regione di un VPC possono accedere al tuo bilanciatore del carico.

Per i bilanciatori del carico delle applicazioni interni regionali, i client devono trovarsi nella stessa regione del bilanciatore del carico per impostazione predefinita. Puoi abilitare l'accesso globale per consentire ai client di qualsiasi regione di un VPC di accedere al tuo bilanciatore del carico.

La tabella seguente riepiloga l'accesso client per i bilanciatori del carico delle applicazioni interni regionali:

Accesso globale disattivato	Accesso globale abilitato
I client devono trovarsi nella stessa regione del bilanciatore del carico. Devono inoltre trovarsi nella stessa rete VPC del bilanciamento del carico o in una rete VPC connessa alla rete VPC del bilanciamento del carico tramite il peering di rete VPC.	I client possono trovarsi in qualsiasi regione. Devono comunque trovarsi nella stessa rete VPC del bilanciatore del carico o in una rete VPC connessa alla rete VPC del bilanciatore del carico tramite il peering di rete VPC.
I client on-premise possono accedere al bilanciatore del carico tramite tunnel VPN Cloud o collegamenti VLAN. Questi tunnel o allegati devono trovarsi nella stessa regione del bilanciatore del carico.	I client on-premise possono accedere al bilanciatore del carico tramite tunnel Cloud VPN o collegamenti VLAN. Questi tunnel o allegati possono trovarsi in qualsiasi regione.

Assistenza GKE

GKE utilizza i bilanciatori del carico delle applicazioni interni nei seguenti modi:

• I gateway interni creati utilizzando il controller GKE Gateway possono utilizzare qualsiasi modalità di un bilanciatore del carico delle applicazioni interno. Controlli la modalità del bilanciatore del carico scegliendo una GatewayClass. Il controller GKE Gateway utilizza sempre i backend NEG zonali GCE_VM_IP_PORT.

• Gli ingress interni creati utilizzando il controller Ingress di GKE sono sempre bilanciatori del carico delle applicazioni interni a livello di regione. Il controller Ingress GKE utilizza sempre backend NEG zonali GCE_VM_IP_PORT.

• Puoi utilizzare i GCE_VM_IP_PORT NEG di zona creati e gestiti dai servizi GKE come backend per qualsiasi bilanciatore del carico delle applicazioni o bilanciatore del carico di rete proxy. Per ulteriori informazioni, vedi Bilanciamento del carico nativo del container tramite NEG standalone a livello di zona.

Architetture VPC condiviso

I bilanciatori del carico delle applicazioni interni supportano le reti che utilizzano il VPC condiviso. Una VPC condiviso consente alle organizzazioni di connettere risorse di più progetti a una rete VPC comune così che possano comunicare tra loro in modo sicuro ed efficiente utilizzando IP interni di quella rete. Se non hai familiarità con il VPC condiviso, leggi la documentazione di panoramica del VPC condiviso.

Esistono molti modi per configurare un bilanciatore del carico delle applicazioni interno in una rete VPC condiviso. Indipendentemente dal tipo di deployment, tutti i componenti del bilanciatore del carico devono trovarsi nella stessa organizzazione.

Subnet e indirizzo IP	Componenti frontend	Componenti di backend
Crea la rete e le subnet richieste (inclusa la subnet solo proxy) nel progetto host VPC condiviso. L'indirizzo IP interno del bilanciatore del carico può essere definito nel progetto host o in un progetto di servizio, ma deve utilizzare una subnet nella rete VPC condiviso desiderata nel progetto host. L'indirizzo stesso proviene dall'intervallo IP principale della subnet a cui viene fatto riferimento.	L'indirizzo IP interno regionale, la regola di forwarding, il proxy HTTP(S) di destinazione e la mappa URL associata devono essere definiti nello stesso progetto. Questo progetto può essere il progetto host o un progetto di servizio.	Puoi eseguire una delle seguenti operazioni: Crea servizi di backend e backend (gruppi di istanze, NEG serverless o qualsiasi altro tipo di backend supportato) nello stesso progetto di servizio dei componenti frontend. Crea servizi di backend e backend (gruppi di istanze, NEG serverless o qualsiasi altro tipo di backend supportato) in tutti i progetti di servizio necessari. Una singola mappa URL può fare riferimento a servizi di backend in progetti diversi. Questo tipo di deployment è noto come riferimento tra progetti. Ogni servizio di backend deve essere definito nello stesso progetto dei backend a cui fa riferimento. I controlli di integrità associati ai servizi di backend devono essere definiti nello stesso progetto del servizio di backend.

Sebbene tu possa creare tutti i componenti di bilanciamento del carico e i backend nel progetto host del VPC condiviso, questo tipo di deployment non separa le responsabilità di amministrazione di rete e sviluppo dei servizi.

Tutti i componenti del bilanciatore del carico e i backend in un progetto di servizio

Il seguente diagramma dell'architettura mostra un deployment VPC condiviso standard in cui tutti i componenti del bilanciatore del carico e i backend si trovano in un progetto di servizio. Questo tipo di deployment è supportato da tutti i bilanciatori del carico delle applicazioni.

Il bilanciatore del carico utilizza indirizzi IP e subnet del progetto host. I client possono accedere a un bilanciatore del carico delle applicazioni interno se si trovano nella stessa rete VPC condiviso e nella stessa regione del bilanciatore del carico. I client possono trovarsi nel progetto host, in un progetto di servizio collegato o in qualsiasi rete collegata.

Backend serverless in un ambiente VPC condiviso

Per un bilanciatore del carico delle applicazioni interno che utilizza un backend NEG serverless, il servizio Cloud Run di supporto deve trovarsi nello stesso progetto di servizio del servizio di backend e del NEG serverless. I componenti frontend del bilanciatore del carico (regola di forwarding, proxy di destinazione, mappa URL) possono essere creati nel progetto host, nello stesso progetto di servizio dei componenti di backend o in qualsiasi altro progetto di servizio nello stesso ambiente VPC condiviso.

Riferimento ai servizi tra progetti

Il riferimento al servizio tra progetti è un modello di deployment in cui il frontend e la mappa URL del bilanciatore del carico si trovano in un progetto, mentre il servizio di backend e i backend del bilanciatore del carico si trovano in un progetto diverso.

Il riferimento ai servizi tra progetti consente alle organizzazioni di configurare un bilanciatore del carico centrale e instradare il traffico a centinaia di servizi distribuiti su più progetti diversi. Puoi gestire centralmente tutte le regole di routing del traffico e le policy in una mappa URL. Puoi anche associare il bilanciatore del carico a un unico insieme di nomi host e certificati SSL. Puoi quindi ottimizzare il numero di bilanciatori del carico necessari per il deployment dell'applicazione e ridurre i requisiti di gestibilità, i costi operativi e le quote.

Se hai progetti diversi per ciascuno dei tuoi team funzionali, puoi anche ottenere una separazione dei ruoli all'interno della tua organizzazione. I proprietari dei servizi possono concentrarsi sulla creazione di servizi nei progetti di servizio, mentre i team di rete possono eseguire il provisioning e la manutenzione dei bilanciatori del carico in un altro progetto ed entrambi possono essere collegati utilizzando i riferimenti di servizio tra progetti.

I proprietari dei servizi possono mantenere l'autonomia sull'esposizione dei propri servizi e controllare quali utenti possono accedervi utilizzando il bilanciatore del carico. Ciò si ottiene tramite un ruolo IAM speciale chiamato Utente dei servizi bilanciatore del carico Compute (roles/compute.loadBalancerServiceUser).

Per i bilanciatori del carico delle applicazioni interni, il riferimento ai servizi tra progetti è supportato solo negli ambienti VPC condiviso.

Per scoprire come configurare VPC condiviso per un bilanciatore del carico delle applicazioni interno, con e senza riferimento ai servizi tra progetti, consulta Configurare un bilanciatore del carico delle applicazioni interno con VPC condiviso.

Note sull'utilizzo per il riferimento ai servizi tra progetti

• Non puoi fare riferimento a un servizio di backend tra progetti se il servizio di backend ha backend NEG internet regionali. Sono supportati tutti gli altri tipi di backend.
• Google Cloud non distingue le risorse (ad esempio, i servizi di backend) che utilizzano lo stesso nome in più progetti. Pertanto, quando utilizzi i riferimenti ai servizi tra progetti, ti consigliamo di utilizzare nomi dservizio di backendnd univoci nei progetti all'interno della tua organizzazione.

Esempio 1: frontend e backend del bilanciatore del carico in progetti di servizio diversi

Di seguito è riportato un esempio di deployment VPC condiviso in cui il frontend e la mappa URL del bilanciatore del carico vengono creati nel progetto di servizio A e la mappa URL fa riferimento a un servizio di backend nel progetto di servizio B.

In questo caso, gli amministratori di rete o gli amministratori del bilanciatore del carico nel progetto di servizio A richiedono l'accesso ai servizi di backend nel progetto di servizio B. Gli amministratori del progetto di servizio B concedono il ruolo Utente dei servizi bilanciatore del carico Compute (roles/compute.loadBalancerServiceUser) agli amministratori del bilanciatore del carico nel progetto di servizio A che vogliono fare riferimento al servizio di backend nel progetto di servizio B.

Esempio 2: frontend del bilanciatore del carico nel progetto host e backend nei progetti di servizio

Di seguito è riportato un esempio di deployment VPC condiviso in cui il frontend e la mappa URL del bilanciatore del carico vengono creati nel progetto host e i servizi di backend (e i backend) vengono creati nei progetti di servizio.

In questo caso, gli amministratori di rete o gli amministratori del bilanciatore del carico nel progetto host richiedono l'accesso ai servizi di backend nel progetto di servizio. Gli amministratori del progetto di servizio concedono il ruolo Utente dei servizi bilanciatore del carico Compute (roles/compute.loadBalancerServiceUser) agli amministratori del bilanciatore del carico nel progetto host A che vogliono fare riferimento al servizio di backend nel progetto di servizio.

Timeout e nuovi tentativi

I bilanciatori del carico delle applicazioni interni supportano i seguenti tipi di timeout:

Tipo e descrizione del timeout	Valori predefiniti	Supporta valori personalizzati
		Tra regioni	Regionale
Timeout del servizio di backend Un timeout di richiesta e risposta. Rappresenta il tempo massimo consentito tra l'invio del primo byte di una richiesta al backend da parte del bilanciatore del carico e la restituzione dell'ultimo byte della risposta HTTP al bilanciatore del carico da parte del backend. Se il backend non ha restituito l'intera risposta HTTP al bilanciatore del carico entro questo limite di tempo, i dati di risposta rimanenti vengono eliminati.	Per i NEG serverless su un servizio di backend: 60 minuti Per tutti gli altri tipi di backend su un servizio di backend: 30 secondi
Timeout keepalive HTTP client Il tempo massimo durante il quale la connessione TCP tra un client e il proxy Envoy gestito del bilanciatore del carico può rimanere inattiva. (La stessa connessione TCP potrebbe essere utilizzata per più richieste HTTP.)	610 secondi
Timeout keepalive HTTP di backend Il tempo massimo durante il quale la connessione TCP tra il proxy Envoy gestito del bilanciatore del carico e un backend può rimanere inattiva. (La stessa connessione TCP potrebbe essere utilizzata per più richieste HTTP.)	10 minuti (600 secondi)

Timeout del servizio di backend

Il timeout del servizio di backend configurabile rappresenta la quantità massima di tempo in cui il bilanciatore del carico attende che il backend elabori una richiesta HTTP e restituisca la risposta HTTP corrispondente. Ad eccezione dei NEG serverless, il valore predefinito per il timeout del servizio di backend è 30 secondi.

Ad esempio, se vuoi scaricare un file da 500 MB e il valore del timeout del servizio di backend è 90 secondi, il bilanciamento del carico si aspetta che il backend fornisca l'intero file da 500 MB entro 90 secondi. È possibile configurare il timeout del servizio di backend in modo che non sia sufficiente per consentire al backend di inviare la risposta HTTP completa. In questa situazione, se il bilanciatore del carico ha ricevuto almeno le intestazioni della risposta HTTP dal backend, restituisce le intestazioni della risposta complete e la parte del corpo della risposta che è riuscito a ottenere entro il timeout del servizio di backend.

Ti consigliamo di impostare il timeout del servizio di backend sul periodo di tempo più lungo che prevedi che il backend impieghi per elaborare una risposta HTTP. Se il software in esecuzione sul backend ha bisogno di più tempo per elaborare una richiesta HTTP e restituire l'intera risposta, ti consigliamo di aumentare il timeout del servizio di backend.

Il timeout del servizio di backend accetta valori compresi tra 1 e 2,147,483,647 secondi; tuttavia, valori più grandi non sono opzioni di configurazione pratiche. Google Cloud inoltre non garantisce che una connessione TCP sottostante possa rimanere aperta per l'intera durata del timeout del servizio di backend. I sistemi client devono implementare la logica di ripetizione anziché fare affidamento su una connessione TCP che rimanga aperta per lunghi periodi di tempo.

Per le connessioni WebSocket utilizzate con i bilanciatori del carico delle applicazioni interni, le connessioni WebSocket attive non rispettano il timeout del servizio di backend. Le connessioni websocket inattive vengono chiuse dopo il timeout del servizio di backend.

Google Cloud riavvia o modifica periodicamente il numero di attività del software Envoy di pubblicazione. Più lungo è il valore di timeout del servizio di backend, più è probabile che i riavvii o le sostituzioni dei task Envoy terminino le connessioni TCP.

Per configurare il timeout del servizio di backend, utilizza uno dei seguenti metodi:

Timeout keepalive HTTP del client

Il timeout keepalive HTTP client rappresenta la quantità massima di tempo in cui una connessione TCP può rimanere inattiva tra il client (downstream) e un proxy Envoy. Il valore predefinito del timeout keepalive HTTP del client è 610 secondi. Puoi configurare il timeout con un valore compreso tra 5 e 1200 secondi.

Un timeout keepalive HTTP è chiamato anche timeout di inattività TCP.

Il timeout keepalive HTTP del client del bilanciatore del carico deve essere maggiore del timeout keepalive HTTP (inattività TCP) utilizzato dai client o dai proxy downstream. Se un client downstream ha un timeout HTTP keepalive (inattività TCP) maggiore del timeout HTTP keepalive del client del bilanciatore del carico, è possibile che si verifichi una condizione di competizione. Dal punto di vista di un client downstream, una connessione TCP stabilita può rimanere inattiva per un periodo di tempo più lungo di quello consentito dal bilanciatore del carico. Ciò significa che il client downstream può inviare pacchetti dopo che il bilanciatore del carico considera chiusa la connessione TCP. In questo caso, il bilanciatore del carico risponde con un pacchetto di ripristino TCP (RST).

Quando scade il timeout keepalive HTTP del client, il proxy GFE o Envoy invia un TCP FIN al client per chiudere correttamente la connessione.

Timeout keepalive HTTP del backend

I bilanciatori del carico delle applicazioni interni sono proxy che utilizzano una prima connessione TCP tra il client (downstream) e un proxy Envoy e una seconda connessione TCP tra il proxy Envoy e i backend.

Le connessioni TCP secondarie del bilanciatore del carico potrebbero non essere chiuse dopo ogni richiesta; possono rimanere aperte per gestire più richieste e risposte HTTP. Il timeout keepalive HTTP del backend definisce il timeout di inattività TCP tra il bilanciatore del carico e i backend. Il timeout keepalive HTTP del backend non si applica ai websocket.

Il timeout keepalive del backend è impostato su 10 minuti (600 secondi) e non può essere modificato. Ciò contribuisce a garantire che il bilanciatore del carico mantenga le connessioni inattive per almeno 10 minuti. Trascorso questo periodo, il bilanciatore del carico può inviare pacchetti di terminazione al backend in qualsiasi momento.

Il timeout keepalive del backend del bilanciatore del carico deve essere inferiore al timeout keepalive utilizzato dal software in esecuzione sui backend. In questo modo si evita una race condition in cui il sistema operativo dei backend potrebbe chiudere le connessioni TCP con un reset TCP (RST). Poiché il timeout keepalive del backend per il bilanciatore del carico non è configurabile, devi configurare il software di backend in modo che il valore di timeout keepalive HTTP (inattività TCP) sia superiore a 600 secondi.

Quando scade il timeout keepalive HTTP del backend, il GFE o il proxy Envoy invia un TCP FIN alla VM di backend per chiudere correttamente la connessione.

La tabella seguente elenca le modifiche necessarie per modificare i valori di timeout keepalive per i software server web comuni.

Software del server web	Parametro	Impostazione predefinita	Impostazione consigliata
Apache	KeepAliveTimeout	KeepAliveTimeout 5	KeepAliveTimeout 620
nginx	keepalive_timeout	keepalive_timeout 75s;	keepalive_timeout 620s;

Nuovi tentativi

Per configurare i tentativi, puoi utilizzare un criterio di ripetizione dei tentativi nella mappa URL. Il numero predefinito di tentativi (numRetries) è 1. Il valore massimo configurabile di perTryTimeout è 24 ore.

Senza un criterio di ripetizione, le richieste non riuscite che non hanno un corpo HTTP (ad esempio, le richieste GET) che generano risposte HTTP 502, 503 o 504 vengono riprovate una volta.

I tentativi di richiesta HTTP POST non vengono ripetuti.

I tentativi di richiesta generano una sola voce di log per la risposta finale.

Per saperne di più, consulta Logging e monitoraggio del bilanciatore del carico delle applicazioni interno.

Accedere alle reti connesse

I client possono accedere a un bilanciatore del carico delle applicazioni interno nella tua rete VPC da una rete connessa utilizzando quanto segue:

• Peering di rete VPC
• Cloud VPN e Cloud Interconnect

Per esempi dettagliati, vedi Bilanciatori del carico delle applicazioni interni e reti connesse.

Failover

Se un backend non è integro, il traffico viene reindirizzato automaticamente ai backend integri.

La tabella seguente descrive il comportamento di failover in ogni modalità:

Modalità del bilanciatore del carico	Comportamento di failover	Comportamento quando tutti i backend non sono integri
Bilanciatore del carico delle applicazioni interno tra regioni	Failover automatico ai backend integri nella stessa regione o in altre regioni. Il traffico viene distribuito tra i backend integri che si estendono su più regioni in base alla distribuzione del traffico configurata.	Restituisce HTTP 503
Bilanciatore del carico delle applicazioni interno regionale	Failover automatico ai backend integri nella stessa regione. Il proxy Envoy invia il traffico ai backend integri in una regione in base alla distribuzione del traffico configurata.	Restituisce HTTP 503

Alta disponibilità e failover tra regioni

Per i bilanciatori del carico delle applicazioni interni regionali

Per ottenere un'alta disponibilità, implementa più bilanciatori del carico delle applicazioni interni regionali individuali nelle regioni che supportano meglio il traffico della tua applicazione. Utilizzi poi una policy di routing basata sulla geolocalizzazione di Cloud DNS per rilevare se un bilanciatore del carico risponde durante un'interruzione regionale. Un criterio di geolocalizzazione indirizza il traffico alla regione disponibile più vicina in base all'origine della richiesta del client. Il controllo di integrità è disponibile per impostazione predefinita per i bilanciatori del carico delle applicazioni interni.

Per i bilanciatori del carico delle applicazioni interni tra regioni

Puoi configurare un bilanciatore del carico delle applicazioni interno tra regioni in più regioni per ottenere i seguenti vantaggi:

1. Se il bilanciatore del carico delle applicazioni interno tra regioni in una regione non funziona, le norme di routing DNS instradano il traffico a un bilanciatore del carico delle applicazioni interno tra regioni in un'altra regione.

   L'esempio di deployment ad alta disponibilità mostra quanto segue:

   • Un bilanciatore del carico delle applicazioni interno tra regioni con indirizzo IP virtuale (VIP) frontend nelle regioni RegionA e RegionB della tua rete VPC. I tuoi clienti si trovano nella regione RegionA.
   • Puoi rendere accessibile il bilanciatore del carico utilizzando VIP frontend di due regioni e utilizzare le policy di routing DNS per restituire il VIP ottimale ai tuoi client. Utilizza i criteri di routing basati sulla geolocalizzazione se vuoi che i tuoi client utilizzino il VIP geograficamente più vicino.
   • Le norme di routing DNS possono rilevare se un VIP non risponde durante un'interruzione regionale e restituire il VIP successivo più ottimale ai tuoi client, garantendo che la tua applicazione rimanga attiva anche durante le interruzioni regionali.

   

2. Se i backend in una determinata regione non sono attivi, il traffico del bilanciatore del carico delle applicazioni interno tra regioni esegue il failover ai backend in un'altra regione in modo controllato.

   L'esempio di deployment di failover tra regioni mostra quanto segue:

   • Un bilanciatore del carico delle applicazioni interno tra regioni con un indirizzo VIP frontend nella regione RegionA della tua rete VPC. I tuoi clienti si trovano anche nella regione RegionA.
   • Un servizio di backend globale che fa riferimento ai backend nelle regioni RegionA e RegionB Google Cloud .
   • Quando i backend nella regione RegionA non sono disponibili, il traffico esegue il failover nella regione RegionB.

   

Supporto di WebSocket

Google Cloud I bilanciatori del carico basati su HTTP(S) supportano il protocollo WebSocket quando utilizzi HTTP o HTTPS come protocollo per il backend. Il bilanciatore del carico non richiede alcuna configurazione per il proxy delle connessioni websocket.

Il protocollo WebSocket fornisce un canale di comunicazione full-duplex tra i client e il bilanciatore del carico. Per ulteriori informazioni, consulta RFC 6455.

Il protocollo WebSocket funziona nel seguente modo:

1. Il bilanciatore del carico riconosce una richiesta Upgrade WebSocket da un client HTTP o HTTPS. La richiesta contiene le intestazioni Connection: Upgrade e Upgrade: websocket, seguite da altre intestazioni di richiesta pertinenti relative ai websocket.
2. Il backend invia una risposta websocket Upgrade. L'istanza di backend invia una risposta 101 switching protocol con le intestazioni Connection: Upgrade e Upgrade: websocket e altre intestazioni di risposta correlate ai websocket.
3. Il bilanciatore del carico funge da proxy per il traffico bidirezionale per la durata della connessione corrente.

Se l'istanza di backend restituisce un codice di stato 426 o 502, il bilanciatore del carico chiude la connessione.

L'affinità sessione per i websocket funziona come per qualsiasi altra richiesta. Per saperne di più, consulta Affinità di sessione.

Supporto di HTTP/2

HTTP/2 è una revisione importante del protocollo HTTP/1. Esistono due modalità di supporto di HTTP/2:

• HTTP/2 su TLS
• Testo in chiaro HTTP/2 su TCP

HTTP/2 su TLS

HTTP/2 su TLS è supportato per le connessioni tra i client e il bilanciatore del carico delle applicazioni esterno e per le connessioni tra il bilanciatore del carico e i relativi backend.

Il bilanciatore del carico negozia automaticamente HTTP/2 con i client nell'ambito dell'handshake TLS utilizzando l'estensione TLS ALPN. Anche se un bilanciatore del carico è configurato per utilizzare HTTPS, i client moderni utilizzano HTTP/2 per impostazione predefinita. Questo è controllato sul client, non sul bilanciatore del carico.

Se un client non supporta HTTP/2 e il bilanciatore del carico è configurato per utilizzare HTTP/2 tra il bilanciatore del carico e le istanze di backend, il bilanciatore del carico potrebbe comunque negoziare una connessione HTTPS o accettare richieste HTTP non protette. Queste richieste HTTPS o HTTP vengono quindi trasformate dal bilanciatore del carico per eseguire il proxy delle richieste su HTTP/2 alle istanze di backend.

Per utilizzare HTTP/2 su TLS, devi attivare TLS sui backend e impostare il protocollo del servizio di backend su HTTP2. Per ulteriori informazioni, vedi Crittografia dal bilanciatore del carico ai backend.

Numero massimo di flussi di dati in parallelo HTTP/2

L'impostazione HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS descrive il numero massimo di flussi accettati da un endpoint, avviati dal peer. Il valore pubblicizzato da un client HTTP/2 a un bilanciatore del caricoGoogle Cloud è effettivamente privo di significato perché il bilanciatore del carico non avvia stream al client.

Nei casi in cui il bilanciatore del carico utilizza HTTP/2 per comunicare con un server in esecuzione su una VM, il bilanciatore del carico rispetta il valore SETTINGS_MAX_CONCURRENT_STREAMS annunciato dal server. Se viene pubblicizzato un valore pari a zero, il bilanciatore del carico non può inoltrare le richieste al server e ciò potrebbe causare errori.

Limitazioni di HTTP/2

• HTTP/2 tra il bilanciatore del carico e l'istanza può richiedere molte più connessioni TCP all'istanza rispetto a HTTP o HTTPS. Il pool di connessioni, un'ottimizzazione che riduce il numero di queste connessioni con HTTP o HTTPS, non è disponibile con HTTP/2. Di conseguenza, potresti notare latenze di backend elevate perché le connessioni di backend vengono effettuate più frequentemente.
• HTTP/2 tra il bilanciatore del carico e il backend non supporta l'esecuzione del protocollo WebSocket su un singolo flusso di una connessione HTTP/2 (RFC 8441).
• HTTP/2 tra il bilanciatore del carico e il backend non supporta il push del server.
• Il tasso di errori e il volume delle richieste gRPC non sono visibili nell'APIGoogle Cloud o nella console Google Cloud . Se l'endpoint gRPC restituisce un errore, i log del bilanciamento del carico e i dati di monitoraggio riportano il codice di stato HTTP 200 OK.

Testo non crittografato HTTP/2 su TCP (H2C)

HTTP/2 di testo non crittografato su TCP, noto anche come H2C, consente di utilizzare HTTP/2 senza TLS. H2C è supportato per entrambe le seguenti connessioni:

• Connessioni tra i client e il bilanciatore del carico. Non è richiesta alcuna configurazione speciale.

• Connessioni tra il bilanciatore del carico e i relativi backend.

  Per configurare H2C per le connessioni tra il bilanciatore del carico e i relativi backend, imposta il protocollo del servizio di backend su H2C.

Il supporto H2C è disponibile anche per i bilanciatori del carico creati utilizzando il controller GKE Gateway e Cloud Service Mesh.

H2C non è supportato per i bilanciatori del carico delle applicazioni classici.

Supporto gRPC

gRPC è un framework open source per le chiamate di procedura remota. È basato sullo standard HTTP/2. Ecco alcuni casi d'uso per gRPC:

• Sistemi distribuiti a bassa latenza e altamente scalabili
• Sviluppare client mobile che comunicano con un server cloud
• Progettazione di nuovi protocolli che devono essere accurati, efficienti e indipendenti dalla lingua
• Progettazione a livelli per consentire l'estensione, l'autenticazione e la registrazione

Per utilizzare gRPC con le tue Google Cloud applicazioni, devi eseguire il proxy delle richieste end-to-end su HTTP/2. Per farlo, crea un bilanciatore del carico delle applicazioni con una delle seguenti configurazioni:

• Per il traffico non criptato end-to-end (senza TLS): crea un bilanciatore del carico HTTP (configurato con un proxy HTTP di destinazione). Inoltre, configura il bilanciatore del carico in modo che utilizzi HTTP/2 per le connessioni non criptate tra il bilanciatore del carico e i relativi backend impostando il protocollo del servizio di backend su H2C.

• Per il traffico criptato end-to-end (con TLS): crei un bilanciatore del carico HTTPS (configurato con un proxy HTTPS di destinazione e un certificato SSL). Il bilanciatore del carico negozia HTTP/2 con i client nell'ambito dell'handshake SSL utilizzando l'estensione TLS ALPN.

  Inoltre, devi assicurarti che i backend possano gestire il traffico TLS e configurare il bilanciatore del carico in modo che utilizzi HTTP/2 per le connessioni criptate tra il bilanciatore del carico e i relativi backend impostando il protocollo del servizio di backend su HTTP2.

  Il bilanciatore del carico potrebbe comunque negoziare HTTPS con alcuni client o accettare richieste HTTP non protette su un bilanciatore del carico configurato per utilizzare HTTP/2 tra il bilanciatore del carico e le istanze di backend. Queste richieste HTTP o HTTPS vengono trasformate dal bilanciatore del carico per eseguire il proxy delle richieste su HTTP/2 alle istanze di backend.

Supporto TLS

Per impostazione predefinita, un proxy target HTTPS accetta solo TLS 1.0, 1.1, 1.2 e 1.3 quando termina le richieste SSL del client.

Quando il bilanciatore del carico delle applicazioni interno utilizza HTTPS come protocollo del servizio di backend, può negoziare TLS 1.2 o 1.3 con il backend.

Supporto di mutual TLS

TLS reciproco o mTLS è un protocollo standard di settore per l'autenticazione reciproca tra un client e un server. mTLS contribuisce a garantire che sia il client che il server si autentichino a vicenda verificando che ciascuno disponga di un certificato valido emesso da un'autorità di certificazione (CA) attendibile. A differenza di TLS standard, in cui viene autenticato solo il server, mTLS richiede che sia il client sia il server presentino certificati, confermando le identità di entrambe le parti prima che venga stabilita la comunicazione.

Tutti i bilanciatori del carico delle applicazioni supportano mTLS. Con mTLS, il bilanciatore del carico richiede al client di inviare un certificato per autenticarsi durante l'handshake TLS con il bilanciatore del carico. Puoi configurare un archivio attendibilità di Certificate Manager che il bilanciatore del carico utilizza per convalidare la catena di attendibilità del certificato client.

Per ulteriori informazioni su mTLS, vedi Autenticazione TLS reciproca.

Limitazioni

• Non è garantito che una richiesta di un client in una zona della regione venga inviata a un backend che si trova nella stessa zona del client. L'affinità di sessione non riduce la comunicazione tra le zone.

• I bilanciatori del carico delle applicazioni interni non sono compatibili con le seguenti funzionalità:

  • Cloud CDN
  • Certificati SSL gestiti da Google di Compute Engine (sono supportati i certificati gestiti da Google di Certificate Manager)

• Per utilizzare i certificati Certificate Manager con i bilanciatori del carico delle applicazioni interni, devi utilizzare l'API o gcloud CLI. La console Google Cloud non supporta i certificati di Certificate Manager.

• Un bilanciatore del carico delle applicazioni interno supporta HTTP/2 solo su TLS.

• I client che si connettono a un bilanciatore del carico delle applicazioni interno devono utilizzare la versione HTTP 1.1 o successive. HTTP 1.0 non è supportato.

• Google Cloud non ti avvisa se la tua subnet solo proxy esaurisce gli indirizzi IP.

• La regola di forwarding interna utilizzata dal bilanciatore del carico delle applicazioni interno deve avere esattamente una porta.

• Quando utilizzi un bilanciatore del carico delle applicazioni interno con Cloud Run in un ambiente VPC condiviso, le reti VPC autonome nei progetti di servizio possono inviare traffico a qualsiasi altro servizio Cloud Run di cui è stato eseguito il deployment in qualsiasi altro progetto di servizio all'interno dello stesso ambiente VPC condiviso. Questo è un problema noto.

• Google Cloud non garantisce che una connessione TCP sottostante possa rimanere aperta per l'intera durata del timeout del servizio di backend. I sistemi client devono implementare la logica di ripetizione anziché fare affidamento su una connessione TCP che rimanga aperta per lunghi periodi di tempo.

• I bilanciatori del carico delle applicazioni interni non supportano Cloud Functions (1ª generazione) e App Engine. Per saperne di più, vedi Panoramica dei NEG serverless: bilanciatori del carico supportati.

• I bilanciatori del carico delle applicazioni interni non supportano Cloud Trace.

Passaggi successivi

• Per configurare il bilanciamento del carico in una configurazione di VPC condiviso, consulta Configurare un bilanciatore del carico delle applicazioni interno con VPC condiviso.

• Per configurare il bilanciamento del carico per i servizi in esecuzione nei pod GKE, consulta Deployment dei gateway GKE, Bilanciamento del carico nativo dei container con NEG autonomi e la sezione Collegamento di un bilanciatore del carico delle applicazioni interno a NEG autonomi.

• Per gestire la risorsa subnet solo proxy, consulta Subnet solo proxy per i bilanciatori del carico basati su Envoy.

• Per configurare l'impostazione secondaria del backend sui bilanciatori del carico delle applicazioni interni regionali, consulta Impostazione secondaria del backend.

• Per configurare un bilanciatore del carico delle applicazioni interno regionale con Private Service Connect, consulta Accedere alle API di Google regionali tramite i backend.

• Per inserire una logica personalizzata nel percorso dei dati di bilanciamento del carico, configura le estensioni di Cloud Load Balancing.