Il bilanciatore del carico di rete proxy interno Google Cloud è un bilanciatore del carico basato su proxy, basato sul software proxy Envoy open source e sullo stack di virtualizzazione di rete Andromeda.
Il bilanciatore del carico di rete proxy interno è un bilanciatore del carico di livello 4 che ti consente di eseguire e scalare il traffico del servizio TCP dietro un indirizzo IP interno regionale accessibile solo ai client nella stessa rete VPC o ai client connessi alla tua rete VPC. Il bilanciatore del carico termina innanzitutto la connessione TCP tra il client e il bilanciatore del carico in un proxy Envoy. Il proxy apre una seconda connessione TCP ai backend ospitati in Google Cloud, on-premise o in altri ambienti cloud. Per altri casi d'uso, consulta la panoramica del bilanciatore del carico di rete proxy.
Modalità di funzionamento
Puoi configurare un bilanciatore del carico di rete proxy interno nelle seguenti modalità:
Bilanciatore del carico di rete proxy interno regionale. Si tratta di un bilanciatore del carico regionale implementato come servizio gestito basato sul proxy Envoy open source. Con la modalità a livello di regione, tutti i client e i backend provengono da una regione specificata, il che è utile quando è necessaria la conformità a livello di regione.
Bilanciatore del carico di rete proxy 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 con backend in più regioni, inclusa la gestione del traffico che garantisce che il traffico venga indirizzato al backend più vicino. Questo bilanciatore del carico consente anche l'alta affidabilità. Il posizionamento dei backend in più regioni consente di evitare errori in una singola regione. Se i backend di una regione non sono disponibili, il traffico può eseguire il failover in un'altra regione. Gli indirizzi IP della regola di forwarding del bilanciatore del carico sono sempre accessibili in tutte le regioni.
La seguente tabella descrive le differenze importanti tra le modalità a livello di regione e tra regioni:
Funzionalità Bilanciatore del carico di rete proxy interno regionale Bilanciatore del carico di rete proxy interno tra regioni Indirizzo IP virtuale (VIP) del bilanciatore del carico. Allocato da una subnet in una regione Google Cloud specifica. Allocato da una subnet in una regione Google Cloud specifica. Gli indirizzi VIP di più regioni possono condividere lo stesso servizio di backend globale.
Accesso client Non accessibile a livello globale per impostazione predefinita.
(Facoltativo) Abilita l'accesso globale.Sempre accessibile a livello globale. I client di qualsiasi regione Google Cloud possono inviare traffico al bilanciatore del carico. Backend con bilanciamento del carico Backend regionali.
Il bilanciatore del carico può inviare il traffico solo ai backend che si trovano nella stessa regione del proxy del bilanciatore del carico.Backend globali.
Il bilanciatore del carico può inviare il traffico ai backend in qualsiasi regione.Alta affidabilità e failover Failover automatico ai backend integri nella stessa regione. Failover automatico ai backend integri nella stessa regione o in regioni diverse.
Identifica la modalità
Console
Nella console Google Cloud , vai alla pagina Bilanciamento del carico.
Nella scheda Bilanciatori del carico puoi visualizzare il tipo di bilanciatore del carico, il protocollo e la regione. Se la regione è vuota, il bilanciatore del carico è in modalità tra regioni. La tabella seguente riassume come identificare la modalità del bilanciatore del carico.
Modalità del bilanciatore del carico Tipo di bilanciatore del carico Tipo di accesso Regione Bilanciatore del carico di rete proxy interno regionale Rete (proxy) Interno Specifica una regione Bilanciatore del carico di rete proxy interno tra regioni Rete (proxy) Interno
gcloud
Per determinare la modalità di un bilanciatore del carico, esegui questo comando:
gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
Nell'output comando, controlla lo schema di bilanciamento del carico, la regione e il livello di rete. La tabella seguente riassume come identificare la modalità del bilanciatore del carico.
| Modalità del bilanciatore del carico | Schema di bilanciamento del carico | Regola di forwarding |
|---|---|---|
| Bilanciatore del carico di rete proxy interno regionale | INTERNAL_MANAGED | Regionale |
| Bilanciatore del carico di rete proxy interno tra regioni | INTERNAL_MANAGED | Globale |
Architettura
Il seguente diagramma mostra le risorse Google Cloud necessarie per i bilanciatori del carico di rete proxy interni.
Regionale
Questo diagramma mostra i componenti di un deployment di un bilanciatore del carico di rete proxy interno regionale nel livello Premium.
Tra regioni
Questo diagramma mostra i componenti di un deployment di un bilanciatore del carico di rete proxy interno tra regioni nel livello Premium all'interno della stessa rete VPC. Ogni regola di forwarding globale utilizza un indirizzo IP regionale utilizzato dai client per connettersi.
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 un bilanciatore del carico di rete proxy interno basato su Envoy.
La tabella seguente descrive i requisiti delle subnet solo proxy per i bilanciatori del carico di rete proxy interni:
| Modalità del bilanciatore del carico | Valore del flag --purpose |
Valore del flag --stack-type |
|---|---|---|
| Bilanciatore del carico di rete proxy interno regionale |
I bilanciatori del carico a livello di regione e tra regioni non possono condividere le stesse subnet Tutti i bilanciatori del carico basati su Envoy a livello di regione in una regione e in una rete VPC condividono la stessa subnet solo proxy. |
|
| Bilanciatore del carico di rete proxy interno tra regioni |
I bilanciatori del carico a livello di regione e tra regioni 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 il bilanciatore del carico. I proxy del bilanciatore del carico tra regioni nella stessa regione e rete condividono la stessa subnet solo proxy. |
|
Inoltre:
- Le subnet solo proxy vengono utilizzate solo per i proxy Envoy, non per i backend.
- Le istanze di macchine virtuali (VM) o gli endpoint di backend di tutti i bilanciatori del carico di rete proxy interni in una regione e in una rete VPC ricevono connessioni dalla subnet solo proxy.
- L'indirizzo IP di un bilanciatore del carico di rete proxy interno non si trova nella subnet solo proxy. L'indirizzo IP del bilanciatore del carico è definito dalla regola di forwarding gestita interna.
Regole di forwarding e indirizzi IP
Le regole di forwarding instradano il traffico in base a indirizzo IP, porta e protocollo verso una configurazione di bilanciamento del carico composta 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 sia Cloud Load Balancing ad assegnarne uno. 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 TCP. Per l'elenco completo dei protocolli supportati, consulta Confronto delle funzionalità dei bilanciatori del carico.
L'indirizzo IP interno associato alla regola di forwarding può provenire da una subnet nella stessa rete e nella stessa regione dei backend.
Specifica della porta. Ogni regola di forwarding utilizzata in un bilanciatore del carico di rete proxy interno può fare riferimento a una singola porta compresa tra 1 e 65535. Per supportare più porte, devi configurare più regole di forwarding.
La tabella seguente mostra i requisiti delle regola di forwarding per i bilanciatori del carico di rete proxy interni:
| 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 di rete proxy interno regionale |
Schema di bilanciamento del carico:
Subnet solo proxy
Indirizzo IP
|
Puoi abilitare l'accesso globale per consentire ai client di qualsiasi regione di accedere al tuo bilanciatore del carico. Anche i backend devono trovarsi nella stessa regione del bilanciatore del carico. |
| Bilanciatore del carico di rete proxy interno tra regioni |
Schema di bilanciamento del carico:
Subnet solo proxy
Indirizzo IP
|
L'accesso globale è abilitato per impostazione predefinita per consentire ai client di qualsiasi regione di accedere al bilanciatore del carico. I backend possono trovarsi in più regioni. |
Regole di forwarding e reti VPC
Questa sezione descrive come le regole di forwarding utilizzate dai bilanciatori del carico delle applicazioni esterni sono associate alle reti VPC.
| Modalità del bilanciatore del carico | Associazione di rete VPC |
|---|---|
|
A seconda che utilizzi un indirizzo IPv4 o un intervallo di indirizzi IPv6, esiste sempre una rete VPC esplicita o implicita associata alla regola di forwarding.
|
Proxy di destinazione
Il bilanciatore del carico di rete proxy interno termina le connessioni TCP dal client e crea nuove connessioni ai backend. Per impostazione predefinita, le informazioni sull'indirizzo IP client e sulla porta originali non vengono conservate. Puoi conservare queste informazioni utilizzando il protocollo PROXY. Il proxy di destinazione instrada le richieste in entrata direttamente al servizio di backend del bilanciatore del carico.
La tabella seguente mostra le API dei proxy di destinazione richieste dai bilanciatori del carico di rete del proxy interno:
| Modalità del bilanciatore del carico | Proxy di destinazione | Riferimento |
|---|---|---|
| Bilanciatore del carico di rete proxy interno regionale | Regionale regionTargetTcpProxies |
Il proxy di destinazione fa riferimento a un singolo servizio di backend o a una o più route TLS. |
| Bilanciatore del carico di rete proxy interno tra regioni | Globale targetTcpProxies |
Il proxy di destinazione fa riferimento a un singolo servizio di backend o a una o più route TLS. |
Route TLS
Una risorsa route TLS consente di definire il modo in cui il traffico viene indirizzato ai servizi di backend in base ai nomi host SNI.
Se il proxy TCP di destinazione del bilanciatore del carico non è referenziato da una route TLS, viene utilizzato solo il singolo servizio di backend predefinito e il valore del nome host SNI inviato dal client o la sua assenza non sono rilevanti.
Puoi collegare una configurazione di route TLS al proxy di destinazione di un bilanciatore del carico utilizzando i comandi gcloud network-services tls-routes.
La tabella seguente mostra le API Routes TLS richieste dai bilanciatori del carico di rete del proxy interno:
| Modalità del bilanciatore del carico | Route TLS | Riferimento |
|---|---|---|
| Bilanciatore del carico di rete proxy interno regionale | Regionale tlsRoutes |
Ogni route TLS può fare riferimento a uno o più servizi di backend. |
| Bilanciatore del carico di rete proxy interno tra regioni | Globale tlsRoutes |
Ogni route TLS può fare riferimento a uno o più servizi di backend. |
Servizio di backend
Un servizio di backend indirizza il traffico in entrata a uno o più backend collegati. Un backend è un gruppo di istanze o un gruppo di endpoint di rete. Il backend contiene informazioni sulla modalità di bilanciamento per definire la pienezza in base alle connessioni (o, solo per i backend dei gruppi di istanze, all'utilizzo).
Ogni bilanciatore del carico ha almeno una risorsa del servizio di backend. Se utilizzi le route TLS per configurare il routing, puoi configurare più servizi di backend per il bilanciatore del carico. Senza route TLS, puoi utilizzare un solo servizio di backend per bilanciatore del carico.
La tabella seguente specifica le API dei servizio di backend per i bilanciatori del carico di rete proxy interni:
| Modalità del bilanciatore del carico | Tipo di servizio di backend |
|---|---|
| Bilanciatore del carico di rete proxy interno regionale | Regionale regionBackendServices |
| Bilanciatore del carico di rete proxy interno tra regioni | Globale backendServices |
Backend supportati
Il bilanciatore del carico di rete proxy interno supporta i seguenti tipi di backend:
| Modalità del bilanciatore del carico | Backend supportati su un servizio di backend | ||||||
|---|---|---|---|---|---|---|---|
| Gruppi di istanze | NEG a livello di zona | NEG Internet | NEG serverless | NEG ibridi | NEG Private Service Connect | GKE | |
| Bilanciatore del carico di rete proxy interno regionale |
Endpoint di tipo GCE_VM_IP_PORT |
Solo NEG a livello di regione | Aggiungi un NEG Private Service Connect | ||||
| Bilanciatore del carico di rete proxy interno tra regioni |
Endpoint di tipo GCE_VM_IP_PORT |
Aggiungi un NEG Private Service Connect | |||||
Tutti i backend devono essere dello stesso tipo (gruppi di istanze o NEG). Puoi utilizzare contemporaneamente diversi tipi di backend di gruppi di istanze o diversi tipi di backend NEG, ma non puoi utilizzare i backend di gruppi di istanze e NEG insieme nello stesso servizio di backend.
Puoi combinare NEG di zona e NEG ibridi nello stesso servizio di backend.
Per ridurre al minimo le interruzioni del servizio per gli utenti, attiva lo svuotamento della connessione sui servizi di backend. Queste interruzioni possono verificarsi quando un backend viene terminato, rimosso manualmente o rimosso da un gestore della scalabilità automatica. Per saperne di più sull'utilizzo dello svuotamento della connessione per ridurre al minimo le interruzioni del servizio, consulta Abilita lo svuotamento della connessione.
Backend e reti VPC
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 di zona e i NEG ibridi, devi specificare esplicitamente la rete VPC quando crei il NEG.
- Per i gruppi di istanze gestite, la rete VPC è definita nel template di istanza.
- Per i gruppi di istanze non gestite, la rete VPC del gruppo di istanze è impostata in modo da corrispondere alla rete VPC dell'interfaccia
nic0per la prima VM aggiunta al gruppo di istanze.
Requisiti di rete del 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 di backend o dagli endpoint.
Requisiti della subnet IPv6 di backend
La versione IP utilizzata per la connessione frontend è indipendente dalla connessione backend. Poiché la subnet solo proxy è a doppio stack (IPV4_IPV6), può comunicare con i backend utilizzando IPv4 o IPv6.
Se le istanze di backend gestiscono il traffico IPv6, la subnet di backend può essere configurata con un tipo di stack
IPV4_ONLYoIPV4_IPV6(a doppio stack). Se il tipo di stack della subnet di backend include IPv6, devi impostare esplicitamente il valore ipv6-access-type della subnet suINTERNAL.
- Sia la rete VPC del backend sia la rete VPC della regola di forwarding devono essere spoke VPC collegati allo stesso hub NCC. 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 di backend o dagli endpoint.
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 backend di 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 invece i backend NEG.
Se utilizzi backend NEG di zona, i pacchetti vengono inviati all'interfaccia di rete rappresentata dall'endpoint nel NEG. Gli endpoint NEG devono trovarsi nella stessa rete VPC della rete VPC definita esplicitamente del NEG.
Protocollo per la comunicazione con i backend
Quando configuri un servizio di backend per un bilanciatore del carico di rete proxy interno, imposti il protocollo utilizzato dal servizio di backend per comunicare con i backend. Il bilanciatore del carico utilizza solo il protocollo specificato e non tenta di negoziare una connessione con l'altro protocollo. I bilanciatori del carico di rete proxy interni supportano solo TCP per la comunicazione con i backend.
Controllo di integrità
Ogni servizio di backend specifica un controllo di integrità che monitora periodicamente l'idoneità 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.
Protocollo di controllo di integrità
Sebbene non sia obbligatorio e non 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à TCP testa con la massima precisione la connettività TCP ai backend. Per l'elenco dei protocolli di controllo di integrità supportati, consulta la sezione Controlli di integrità della pagina di confronto delle funzionalità del bilanciatore del carico.
La tabella seguente specifica l'ambito dei controlli di integrità supportati dai bilanciatori del carico di rete proxy interni in ciascuna modalità:
| Modalità del bilanciatore del carico | Tipo di controllo di integrità |
|---|---|
| Bilanciatore del carico di rete proxy interno regionale | Regionale regionHealthChecks |
| Bilanciatore del carico di rete proxy interno tra regioni | Globale healthChecks |
Per saperne di più sui controlli di integrità, consulta le seguenti risorse:
Regole firewall
I bilanciatori del carico di rete proxy interni richiedono le seguenti regole firewall:
- Una regola di autorizzazione in entrata che consente il traffico proveniente dai probe del controllo di integrità di Google. Per saperne di più sugli intervalli di indirizzi IP specifici dei probe per 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.
Le porte per queste regole firewall devono essere configurate come segue:
Consenti il traffico verso la porta di destinazione per il controllo di integrità di ogni servizio di backend.
Per i backend dei gruppi di istanze: determina le porte da configurare in base alla mappatura tra la porta denominata del servizio di backend e i numeri di porta associati alla porta denominata in ogni gruppo di istanze. I numeri di porta possono variare tra i gruppi di istanze assegnati allo stesso servizio di backend.
Per i backend NEG
GCE_VM_IP_PORT, consenti il traffico verso i numeri di porta degli endpoint.
Esistono alcune eccezioni ai requisiti delle regole firewall per questi bilanciatori del carico:
- Per i NEG ibridi non è necessario consentire il traffico proveniente dagli intervalli di probe del controllo di integrità di Google. Tuttavia, se utilizzi una combinazione di NEG di zona e ibridi in un unico servizio di backend, devi consentire il traffico dagli intervalli di probe del controllo di integrità di Google per i NEG di zona.
- 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 solo proxy e viene poi tradotto tramite NAT (utilizzando Cloud NAT) in indirizzi IP NAT allocati manualmente o con allocazione automatica. Questo traffico include sia i probe del controllo di integrità sia le richieste degli utenti dal bilanciatore del carico ai backend. Per maggiori dettagli, consulta NEG a livello di regione: utilizza un gateway Cloud NAT.
Utilizza le regole delle policy del firewall di Cloud NGFW per controllare l'accesso dei client alle regole di forwarding dei bilanciatori del carico basati su proxy Envoy, come i bilanciatori del carico di rete proxy interni regionali e i bilanciatori del carico di rete proxy interni tra regioni. Queste funzionalità sono supportate sia da Cloud NGFW Essentials sia da Cloud NGFW Standard.
Per saperne di più, consulta Utilizza le policy del firewall di rete regionale per proteggere i bilanciatori del carico delle applicazioni interni e i bilanciatori del carico di rete proxy interni.
Accesso client
I client possono trovarsi nella stessa rete o in una rete VPC connessa tramite il peering di rete VPC.
Per i bilanciatori del carico di rete proxy 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 accedere al bilanciatore del carico.
Per i bilanciatori del carico di rete proxy interni tra regioni, l'accesso globale è abilitato per impostazione predefinita. I client di qualsiasi regione possono accedere al bilanciatore del carico.
La tabella seguente riassume l'accesso dei client ai bilanciatori del carico di rete proxy interni regionali:
| Accesso globale disabilitato | Accesso globale abilitato |
|---|---|
| I client devono trovarsi nella stessa regione del bilanciatore del carico. Inoltre, devono 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 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 Cloud VPN o collegamenti VLAN. Questi tunnel o collegamenti 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 collegamenti possono trovarsi in qualsiasi regione. |
Architettura VPC condiviso
Il bilanciatore del carico di rete proxy interno supporta le reti che utilizzano il VPC condiviso. Un VPC condiviso ti consente di mantenere una chiara separazione delle responsabilità tra amministratori di rete e sviluppatori di servizi. I team di sviluppo possono concentrarsi sulla creazione di servizi nei progetti di servizio, mentre i team dell'infrastruttura di rete possono eseguire il provisioning e l'amministrazione del bilanciamento del carico. Se non hai ancora familiarità con il VPC condiviso, leggi la documentazione di panoramica del VPC condiviso.
| Indirizzo IP | Regola di forwarding | Proxy di destinazione | Componenti di backend |
|---|---|---|---|
Un indirizzo IP interno deve essere definito nello stesso progetto dei backend. Affinché il bilanciatore del carico sia disponibile in una rete VPC condiviso, l'indirizzo IP interno deve essere definito nello stesso progetto di servizio in cui si trovano le VM di backend e deve fare riferimento a una subnet nella rete VPC condiviso desiderata nel progetto host. L'indirizzo stesso proviene dall'intervallo IP principale della subnet di riferimento. |
Una regola di forwarding interno deve essere definita nello stesso progetto dei backend. Affinché il bilanciatore del carico sia disponibile in una rete VPC condiviso, la regola di forwarding interno deve essere definita nello stesso progetto di servizio in cui si trovano le VM di backend e deve fare riferimento alla stessa subnet (nella rete VPC condiviso) a cui fa riferimento l'indirizzo IP interno associato. |
Il proxy di destinazione deve essere definito nello stesso progetto dei backend. | In uno scenario di VPC condiviso, le VM di backend si trovano in genere in un progetto di servizio. Un servizio di backend interno regionale e un controllo di integrità devono essere definiti nel progetto di servizio. |
Distribuzione del traffico
Un bilanciatore del carico di rete proxy interno distribuisce il traffico ai suoi backend come segue:
- Le connessioni provenienti da un singolo client vengono inviate alla stessa zona, purché siano disponibili backend integri (gruppi di istanze o NEG) all'interno di quella zona e abbiano capacità, come determinato dalla modalità di bilanciamento.
Per i bilanciatori del carico di rete proxy interni regionali, la modalità di bilanciamento può essere
CONNECTION(backend di gruppi di istanze o NEG) oUTILIZATION(solo backend di gruppi di istanze). - Le connessioni da un client vengono inviate allo stesso backend se hai configurato l'affinità di sessione.
- Dopo aver selezionato un backend, il traffico viene distribuito tra le istanze (in un gruppo di istanze) o gli endpoint (in un NEG) in base a una policy di bilanciamento del carico. Per gli algoritmi delle policy di bilanciamento del carico supportati, consulta l'impostazione
localityLbPolicynella documentazione dell'API del servizio di backend regionale.
Routing basato su SNI con route TLS
Il routing basato su SNI consente ai bilanciatori del carico di rete proxy TCP di instradare il traffico a servizi di backend specifici in base al nome host SNI (Server Name Indication) fornito durante il TLS handshake. SNI è un'estensione TLS che consente a un client di specificare il nome di dominio che vuole raggiungere prima che venga stabilito il tunnel criptato.
Il nome host SNI viene trasmesso in un formato non criptato all'interno del messaggio ClientHello, in modo che il bilanciatore del carico possa ispezionare questo valore e instradare il traffico al servizio di backend appropriato.
Puoi utilizzare una risorsa di configurazione della route TLS per mappare nomi host SNI specifici ai servizi di backend. Quando è configurato il routing basato su SNI, il bilanciatore del carico attiva il passthrough TLS, in cui il flusso di byte criptato viene passato direttamente al backend senza essere decriptato dal bilanciatore del carico.
Questa funzionalità sblocca alcuni casi d'uso chiave, ad esempio:
- Utilizza un unico indirizzo IP anycast globale e una porta per gestire più applicazioni, riducendo il consumo di indirizzi IPv4.
- Supporta i deployment con crittografia end-to-end in cui i certificati possono rimanere sui backend, garantendo che il traffico non venga mai decriptato in transito.
- Consente agli amministratori della piattaforma di gestire l'infrastruttura di base, mentre i proprietari dei servizi gestiscono in modo indipendente i propri backend e route specifici.
- Consente il routing a shard specifici per applicazioni stateful non HTTP (come MongoDB) in base all'SNI fornito dal client.
Come viene distribuito il traffico quando vengono utilizzate le route TLS
Quando è configurato il routing basato su SNI, il traffico viene instradato ai servizi di backend come segue:
- Il bilanciatore del carico rimane in ascolto sull'IP e sulla porta definiti nella regola di forwarding.
- Quando un client avvia una connessione TLS, il bilanciatore del carico intercetta il messaggio
ClientHelloed estrae il nome host SNI. L'SNI estratto viene confrontato con i nomi host definiti nelle route TLS configurate. Il bilanciatore del carico utilizza la seguente logica per determinare quale servizio di backend deve ricevere il traffico:
- Se il client non utilizza il protocollo TLS, il bilanciatore del carico chiude la connessione.
- Se il client non invia alcun nome host SNI nel messaggio
ClientHello, il bilanciatore del carico chiude la connessione. - Se il client invia un nome host SNI che non è un nome DNS valido, il bilanciatore del carico chiude la connessione.
- Se il client invia un nome host SNI che non corrisponde a nessuno dei nomi host SNI associati a una route TLS, il bilanciatore del carico chiude la connessione.
In tutte le altre situazioni: il bilanciatore del carico seleziona un servizio di backend utilizzando il seguente processo di corrispondenza:
La corrispondenza viene eseguita in base al suffisso più lungo (più lungo in termini di numero di sottodomini). Per illustrare il metodo di corrispondenza, considera una route TLS con SNI
*.foo.com, un'altra route TLS con SNI*.bar.foo.come una terza route TLS con SNIbaz.bar.foo.com.- Se il nome host SNI del client è
baz.bar.foo.com, il bilanciatore del carico seleziona un servizio di backend a cui fa riferimento la route TLS il cui SNI èbaz.bar.foo.com. - Se il nome host SNI del client è
qux.bar.foo.com, il bilanciatore del carico seleziona un servizio di backend a cui fa riferimento la route TLS il cui SNI è*.bar.foo.com. - Se il nome host SNI del client è
qux.qux.foo.com, il bilanciatore del carico seleziona un servizio di backend a cui fa riferimento la route TLS il cui SNI è*.foo.com.
- Se il nome host SNI del client è
Una volta trovata una corrispondenza, il flusso di byte criptato viene inviato direttamente tramite proxy al servizio di backend assegnato senza terminare la connessione TLS (per il passthrough TLS).
Limitazioni
Quando utilizzi le route TLS per configurare il routing basato su SNI, si applicano le seguenti limitazioni:
- Un proxy TCP di destinazione può fare riferimento a un singolo servizio di backend o a una o più route TLS. Non puoi configurare entrambe le opzioni.
I bilanciatori del carico di rete proxy non possono rilevare la coalescenza delle connessioni HTTP, il che potrebbe portare a richieste HTTP indirizzate in modo errato.
Per impostazione predefinita, i browser uniscono già le connessioni HTTP. Ad esempio, quando un browser apre una connessione a
www.example.come il server presenta un certificato per*.example.comdurante il TLS handshake, il browser riutilizza questa connessione per tutte le richieste a*.example.com, a condizione che il nome host venga risolto nello stesso indirizzo IP. Questo è conforme alla RFC 7540.Con il routing basato su SNI, una volta stabilita una connessione, questa viene associata in modo permanente al backend di destinazione. Considera un deployment in cui
*.example.comè gestito da un backend HTTPS con un certificato TLS*.example.comemy.example.comè gestito da un altro backend HTTPS. Se viene stabilita prima una connessione a*.example.com, le richieste HTTP successive amy.example.comvengono raggruppate nella stessa connessione, utilizzando il backend HTTPS*.example.com.
Affinità di sessione
L'affinità di sessione consente di configurare il servizio di backend del bilanciatore del carico in modo che invii tutte le richieste dello stesso client allo stesso backend, purché quest'ultimo sia integro e abbia capacità.
I bilanciatori del carico di rete proxy interni offrono i seguenti tipi di affinità sessione:Nessuna
Un'impostazione di affinità sessione pari a
NONEnon significa che non esiste un'affinità sessione. Significa che non è configurata esplicitamente alcuna opzione di affinità sessione.L'hashing viene sempre eseguito per selezionare un backend. Un'impostazione di affinità sessione pari a
NONEindica che il bilanciatore del carico utilizza un hash a 5 tuple per selezionare un backend. L'hash a 5 tuple è costituito dall'indirizzo IP di origine, dalla porta di origine, dal protocollo, dall'indirizzo IP di destinazione e dalla porta di destinazione.Un'affinità sessione
NONEè il valore predefinito.Affinità IP client
L'affinità sessione IP client (
CLIENT_IP) è un hash di 2 tuple creato dagli indirizzi IP di origine e di destinazione del pacchetto. L'affinità IP client inoltra tutte le richieste dallo stesso indirizzo IP client allo stesso backend, purché quest'ultimo abbia capacità e rimanga integro.Quando utilizzi l'affinità IP client, tieni presente quanto segue:
- L'indirizzo IP di destinazione del pacchetto corrisponde all'indirizzo IP della regola di forwarding del bilanciatore del carico solo se il pacchetto viene inviato direttamente al bilanciatore del carico.
- L'indirizzo IP di origine del pacchetto potrebbe non corrispondere a un indirizzo IP associato al client originale se il pacchetto viene elaborato da un sistema NAT o proxy intermedio prima di essere consegnato a un bilanciatore del carico Google Cloud . In situazioni in cui molti client condividono lo stesso indirizzo IP di origine effettivo, alcune VM di backend potrebbero ricevere più connessioni o richieste rispetto ad altre.
Tieni presente quanto segue quando configuri l'affinità sessione:
Non fare affidamento sull'affinità sessione per scopi di autenticazione o sicurezza. L'affinità di sessione può interrompersi ogni volta che cambia il numero di backend attivi e integri. Per maggiori dettagli, consulta Perdita dell'affinità di sessione.
I valori predefiniti dei flag
--session-affinitye--subsetting-policysono entrambiNONEe solo uno di questi può essere impostato su un valore diverso alla volta.
Perdita dell'affinità di sessione
Tutte le opzioni di affinità sessione richiedono quanto segue:
- L'istanza di backend o l'endpoint selezionato deve rimanere configurato come backend. L'affinità di sessione può interrompersi quando si verifica uno dei seguenti eventi:
- Rimuovi l'istanza selezionata dal relativo gruppo di istanze.
- La scalabilità automatica o la riparazione automatica del gruppo di istanze gestite rimuove l'istanza selezionata dal gruppo di istanze gestite.
- Rimuovi l'endpoint selezionato dal relativo NEG.
- Rimuovi dal servizio di backend il gruppo di istanze o il NEG che contiene l'istanza o l'endpoint selezionato.
- L'istanza o l'endpoint di backend selezionato deve rimanere integro. L'affinità di sessione può interrompersi se l'istanza o l'endpoint selezionato non supera i controlli di integrità.
Il gruppo di istanze o il NEG che contiene l'istanza o l'endpoint selezionato non deve essere pieno, come definito dalla sua capacità target. (Per i gruppi di istanze gestite a livello di regione, il componente a livello di zona del gruppo di istanze che contiene l'istanza selezionata non deve essere pieno.) L'affinità di sessione può interrompersi quando il gruppo di istanze o il NEG è pieno e altri gruppi di istanze o NEG non lo sono. Poiché la pienezza può cambiare in modi imprevedibili quando utilizzi la modalità di bilanciamento
UTILIZATION, devi utilizzare la modalità di bilanciamentoRATEoCONNECTIONper ridurre al minimo le situazioni in cui l'affinità sessione può interrompersi.Il numero totale di istanze o endpoint di backend configurati deve rimanere costante. Quando si verifica almeno uno dei seguenti eventi, il numero di istanze di backend o endpoint configurati cambia e l'affinità sessione può interrompersi:
Aggiunta di nuove istanze o endpoint:
- Aggiungi istanze a un gruppo di istanze esistente nel servizio di backend.
- La scalabilità automatica dei gruppi di istanze gestite aggiunge istanze a un gruppo di istanze gestite nel servizio di backend.
- Aggiungi endpoint a un NEG esistente nel servizio di backend.
- Aggiungi gruppi di istanze o NEG non vuoti al servizio di backend.
Rimozione di qualsiasi istanza o endpoint, non solo dell'istanza o dell'endpoint selezionati:
- Rimuovi un'istanza dal backend di un gruppo di istanze.
- La scalabilità automatica o il ripristino automatico del gruppo di istanze gestite rimuove un'istanza dal backend di un gruppo di istanze gestite.
- Rimuovi un endpoint da un backend NEG.
- Rimuovi dal servizio di backend qualsiasi gruppo di istanze o NEG di backend esistente e non vuoto.
Il numero totale di istanze di backend o endpoint integri deve rimanere costante. Quando si verifica almeno uno dei seguenti eventi, il numero di istanze o endpoint di backend integri cambia e l'affinità sessione può interrompersi:
- Qualsiasi istanza o endpoint supera il controllo di integrità, passando da non integro a integro.
- Qualsiasi istanza o endpoint non supera il controllo di integrità, passando da integro a non integro o timeout.
Failover
Se un backend non è integro, il traffico viene reindirizzato automaticamente ai backend integri.
La tabella seguente descrive il comportamento di failover per i bilanciatori del carico di rete proxy interni:
| Modalità del bilanciatore del carico | Comportamento di failover | Comportamento quando tutti i backend non sono integri |
|---|---|---|
| Bilanciatore del carico di rete proxy interno regionale | Il bilanciatore del carico implementa un algoritmo di failover graduale per zona. Anziché attendere che tutti i backend di una zona diventino non integri, il bilanciatore del carico inizia a reindirizzare il traffico a una zona diversa quando il rapporto tra backend integri e non integri in una zona è inferiore a una determinata soglia percentuale (70%; questa soglia non può essere configurata). Se tutti i backend in tutte le zone non sono integri, il bilanciatore del carico termina immediatamente la connessione client. Il proxy Envoy invia il traffico ai backend integri in una regione in base alla distribuzione del traffico configurata. |
Termina la connessione |
| Bilanciatore del carico di rete proxy interno tra regioni | Failover automatico ai backend integri nella stessa regione o in altre regioni. Il traffico viene distribuito tra i backend integri in più regioni in base alla distribuzione del traffico configurata. |
Termina la connessione |
Bilanciamento del carico per le applicazioni GKE
Se stai creando applicazioni in Google Kubernetes Engine (GKE), puoi utilizzare i NEG di zona autonomi per bilanciare il carico del traffico direttamente nei container. Con i NEG autonomi, sei responsabile della creazione dell'oggetto Service che crea il NEG di zona e dell'associazione del NEG al servizio di backend in modo che il bilanciatore del carico possa connettersi ai pod.
Documentazione di GKE correlata:
Quote e limiti
Per informazioni su quote e limiti, consulta Quote e limiti.
Limitazioni
- Il bilanciatore del carico di rete proxy interno non supporta i deployment VPC condiviso in cui il frontend del bilanciatore del carico si trova in un progetto host o di servizio e il servizio di backend e i backend si trovano in un altro progetto di servizio (noto anche come riferimento ai servizi tra progetti).
- Google Cloud non fornisce alcuna garanzia sulla durata delle connessioni TCP quando utilizzi i bilanciatori del carico di rete proxy interni. I client devono essere resilienti alle interruzioni delle connessioni, sia a causa di problemi di internet più ampi sia a causa dei riavvii pianificati regolarmente dei proxy Envoy che gestiscono le connessioni.
Passaggi successivi
Configura un bilanciatore del carico di rete proxy interno regionale con un backend NEG di zona
Configura un bilanciatore del carico di rete proxy interno regionale con un backend NEG ibrido
Configura un bilanciatore del carico di rete proxy interno regionale con un backend NEG internet