Panoramica dei gruppi di endpoint di rete internet

Cloud Load Balancing supporta il proxy del traffico verso backend esterni al di fuori di Google Cloud. Per definire un backend esterno per un bilanciatore del carico, utilizza una risorsa chiamata gruppo di endpoint di rete (NEG) internet.

Puoi usare questo tipo di deployment quando vuoi fornire contenuti da un ma vuoi che il bilanciatore del carico Google Cloud sia il frontend. In questo modo potrai:

  • Utilizza l'infrastruttura Google Edge per terminare le connessioni degli utenti.
  • Indirizza le connessioni al tuo backend esterno.
  • Invia il traffico al tuo endpoint pubblico tramite la dorsale privata di Google, che migliora l'affidabilità e può ridurre la latenza tra client e server.
  • Con i bilanciatori del carico globali, puoi utilizzare Cloud CDN per memorizzare i contenuti nella cache per il backend esterno.

La figura 1 mostra un bilanciatore del carico delle applicazioni esterno con più backend di Compute Engine, uno dei quali è un backend esterno configurato con un NEG internet.

Gruppi di endpoint di rete internet nel bilanciamento del carico.
Figura 1. Gruppi di endpoint di rete internet nel bilanciamento del carico (fai clic per ingrandire).

I backend NEG internet sono supportati con diversi carichi globali e a livello di regione bilanciatori del carico e bilanciatori del carico. A seconda del bilanciatore del carico (globale o regionale), il supporto del NEG su internet è diverso per quanto riguarda il DNS, il controllo dell'integrità, il numero di endpoint disponibili e i comportamenti di instradamento del traffico.

Le sezioni che seguono spiegano come vengono utilizzati i backend esterni e Cloud Load Balancing. Se vuoi utilizzare un backend esterno Cloud Service Mesh, consulta Cloud Service Mesh con endpoint di rete internet gruppi di lavoro.

Terminologia

I termini seguenti vengono a volte usati in modo intercambiabile perché hanno significati uguali o simili:

  • Backend esterno: un backend esterno a Google Cloud e accessibile tramite internet. L'endpoint in un NEG internet.
  • origine personalizzata:uguale a un backend esterno. In CDN, origin è il parametro termine standard del settore per un'istanza di backend che gestisce contenuti web.
  • Gruppo di endpoint di rete internet (NEG): la risorsa dell'API Google Cloud che utilizzi per specificare un backend esterno.
  • endpoint esterno: uguale a un backend esterno.

Questo documento utilizza il termine backend esterno, tranne quando si fa riferimento alla risorsa dell'API NEG internet.

Componenti del bilanciatore del carico

Questa sezione descrive l'architettura di bilanciamento del carico e le risorse necessarie per configurare un bilanciatore del carico con un backend esterno. Il bilanciatore del carico richiede una configurazione speciale solo per il servizio di backend. La la configurazione frontend è uguale a quella di qualsiasi altro bilanciatore del carico.

Le figure seguenti mostrano le risorse Google Cloud necessarie per configurare un bilanciatore del carico con un backend esterno.

Esterno globale

Questa figura mostra le risorse Google Cloud necessarie per configurare un bilanciatore del carico delle applicazioni esterno globale con un backend esterno.

Bilanciatore del carico delle applicazioni esterno globale con backend esterno
Bilanciatore del carico delle applicazioni esterno globale con backend esterno (fai clic per ingrandire).

Esterno regionale

Questa figura mostra le risorse Google Cloud necessarie per configurare un bilanciatore del carico delle applicazioni esterno regionale con un backend esterno.

Bilanciatore del carico delle applicazioni esterno regionale con un backend esterno.
Bilanciatore del carico delle applicazioni esterno regionale con backend esterno (fai clic per ingrandire).

Interno a livello di regione

Questa figura mostra le risorse Google Cloud necessarie per configurare un bilanciatore del carico delle applicazioni interno regionale con un backend esterno.

Bilanciatore del carico delle applicazioni interno regionale con un backend esterno.
Bilanciatore del carico delle applicazioni interno regionale con un backend esterno (fai clic per ingrandire).

Questa figura mostra le risorse Google Cloud necessarie per configurare un bilanciatore del carico di rete proxy interno regionale con un backend esterno.

Bilanciatore del carico di rete proxy interno regionale con un backend esterno.
Bilanciatore del carico di rete proxy interno regionale con backend esterno (fai clic per ingrandire).

Puoi utilizzare i NEG internet solo nel livello Premium di Network Service Tiers.

Configurazione frontend

Non è richiesta alcuna configurazione frontend speciale per creare un bilanciatore del carico con un backend NEG internet. Le regole di forwarding vengono utilizzate per instradare il traffico in base a indirizzo IP, porta e protocollo a un proxy di destinazione. Il proxy di destinazione termina quindi le connessioni dei client. Inoltre, i bilanciatori del carico basati su Envoy richiedono una subnet solo proxy.

I bilanciatori del carico delle applicazioni utilizzano anche le mappe URL per configurare l'instradamento delle richieste in base all'URL ai servizi di backend appropriati.

Per ulteriori dettagli su ciascuno di questi componenti, consulta le sezioni sull'architettura del rispettivo bilanciatore del carico:

NEG Internet

Un NEG internet è una risorsa utilizzata per definire un backend esterno per con il bilanciatore del carico di rete passthrough esterno regionale. Il backend esterno a cui fa riferimento il NEG internet deve essere raggiungibile tramite internet. L'endpoint non può essere raggiungibile solo tramite Cloud VPN o Cloud Interconnect. Se il backend esterno fa riferimento a un'API o a un servizio Google, il servizio deve essere raggiungibile tramite Porta TCP 80 o 443 utilizzando il protocollo HTTP, HTTPS o HTTP/2.

Esistono due modi per configurare l'endpoint esterno a cui fa riferimento il NEG:INTERNET_FQDN_PORT o INTERNET_IP_PORT. Inoltre, ciascuno di questi endpoint è disponibile in due ambiti: globale o regionale.

I NEG internet globali sono basati sulle tecnologie Google Front End (GFE). Utilizzano un insieme fisso di indirizzi IP fissi per il traffico in uscita a tutti i clienti. Supportano un solo endpoint per NEG e un NEG internet per servizio di backend.

La seguente tabella descrive in che modo i diversi bilanciatori del carico supportano i NEG internet globali.

Bilanciatori del carico Tipo di endpoint Definizione di endpoint Ambito Controlli di integrità
  • Bilanciatore del carico delle applicazioni esterno globale
  • Bilanciatore del carico delle applicazioni classico

INTERNET_FQDN_PORT

Un nome di dominio completo risolvibile pubblicamente e una porta facoltativa. Ad esempio: backend.example.com:443†.

Il nome di dominio deve essere risolvibile da DNS pubblico di Google infrastruttura.

È consentito un solo endpoint per NEG.

 Globale Non supportata

INTERNET_IP_PORT

Un indirizzo IP routabile pubblicamente e una porta facoltativa. Ad esempio, 8.8.8.8:4431.

L'indirizzo IP non può essere un indirizzo RFC 1918.

È consentito un solo endpoint per NEG.

† Se non specifichi una porta durante l'aggiunta dell'endpoint, viene utilizzata la porta predefinita del NEG. Se non hai specificato una porta predefinita per NEG, la porta nota per il protocollo di backend (80 per HTTP e 443 per HTTPS e HTTP/2).

I NEG di internet regionali sono basati su proxy Envoy gestiti e gateway Cloud NAT. Supportano più endpoint per NEG e più NEG internet per servizio di backend. Gli indirizzi IP utilizzati per il traffico in uscita ai client possono essere configurati utilizzando i gateway Cloud NAT.

La tabella seguente descrive in che modo i diversi bilanciatori del carico supportano i NEG internet regionali.

Bilanciatori del carico Tipo di endpoint Definizione di endpoint Ambito Controlli di integrità
  • Bilanciatore del carico delle applicazioni esterno regionale
  • Bilanciatore del carico delle applicazioni interno regionale
  • Bilanciatore del carico di rete proxy esterno regionale
  • Bilanciatore del carico di rete proxy interno regionale

INTERNET_FQDN_PORT

Un modello completo risolvibile pubblicamente un nome di dominio e una porta facoltativa. Ad esempio: backend.example.com:443*

Il nome di dominio deve essere risolvibile da Cloud DNS o dall'infrastruttura DNS pubblico di Google.

Sono consentiti massimo 256 endpoint per NEG.

 Regionale Integrità distribuita di Envoy controlli

INTERNET_IP_PORT

Un indirizzo IP instradabile pubblicamente e una porta facoltativa. Ad esempio, 8.8.8.8:4432.

L'indirizzo IP non può essere un indirizzo RFC 1918.

Sono consentiti massimo 256 endpoint per NEG.

* Con i NEG internet a livello di regione, devi specificare una porta. Puoi specificare una porta predefinita durante la creazione del NEG oppure puoi specificare una porta ogni volta che aggiungi un endpoint al NEG, oppure puoi eseguire entrambe le operazioni. In caso contrario specifica una porta quando aggiungi un endpoint, la porta predefinita del NEG in uso.

Risoluzione DNS per gli endpoint INTERNET_FQDN_PORT regionali

Se il tuo dominio è risolvibile tramite internet, non sono necessarie altre configurazioni per configurare il DNS. Tuttavia, per risolvere i problemi relativi a nomi di dominio completi privati, dovrai: e configurare Cloud DNS per facilitare la risoluzione DNS. Il nome deve essere ospitato su Cloud DNS o essere risolvibile utilizzando il forwarding DNS da Cloud DNS a un DNS on-premise.

Per iniziare, crea una zona Cloud DNS per ospitare i record DNS nel tuo progetto. quindi aggiungi i record DNS. Per le procedure di configurazione specifiche, vedi consulta la documentazione di Cloud DNS.

Se utilizzi un VPC condiviso, tieni presente i requisiti della rete specifici. Puoi anche utilizzare altre funzionalità di Cloud DNS, come le zone di inoltro, per recuperare i record da un server DNS on-premise.

Risoluzione degli indirizzi IP per gli endpoint INTERNET_FQDN_PORT globali

Quando un endpoint INTERNET_FQDN_PORT punta a un record DNS che restituisce più indirizzi IP, l'indirizzo IP viene risolto nel seguente modo:

  • Il bilanciatore del carico utilizza un resolver DNS in una regione Google Cloud che più vicino al suo client su internet. Se il record DNS per il tuo endpointINTERNET_FQDN_PORT restituisce indirizzi IP diversi in base alla posizione del client, assicurati che ciascuno di questi indirizzi IP possa essere raggiunto dal bilanciatore del carico.

  • Il bilanciatore del carico tenta di connettersi al primo IP nella risposta DNS. Se quell'indirizzo IP non è raggiungibile, il carico il bilanciatore restituisce una risposta HTTP 502 (Bad Gateway). Ciò vale anche se sono disponibili altri indirizzi IP dalla risposta DNS.

Per ulteriori informazioni sugli intervalli IP e sulle località utilizzati dall'infrastruttura del resolver DNS di Google, consulta la documentazione di Google Public DNS. I nomi che non possono essere risolti dal sistema DNS pubblico non sono utilizzabili come backend esterni.

Risoluzione degli indirizzi IP per gli endpoint INTERNET_FQDN_PORT a livello di regione

I NEG internet a livello di regione supportano la risoluzione dei nomi di dominio utilizzando sia Cloud DNS e il DNS pubblico di Google. Nel caso dei server DNS pubblici, Cloud DNS inoltra il traffico ai server DNS pubblici.

Se il server DNS restituisce più indirizzi IP, Envoy bilancia il traffico tra gli indirizzi IP restituiti in base all'algoritmo di bilanciamento del carico configurato (round robin, richiesta minima e così via). L’elenco degli endpoint viene periodicamente vengono aggiornate in base al TTL del DNS. Puoi configurare riprova criteri per forzare Envoy a tentare di connettersi a un altro indirizzo IP in caso di errore.

Servizio di backend

I servizi di backend forniscono la configurazione le informazioni al bilanciatore del carico. I bilanciatori del carico utilizzano le informazioni in un servizio di backend per indirizzare il traffico in entrata a uno o più backend collegati.

Per configurare un bilanciatore del carico con un backend esterno, devi configurare il backend con un backend NEG internet. Quando aggiungi un NEG internet a un servizio di backend, si applicano le seguenti considerazioni, a seconda dell'ambito del NEG:

  • Il servizio di backend non può utilizzare anche altri tipi di backend (ad esempio NEG a livello di zona o gruppi di istanze) come backend.

  • Numero di NEG per servizio di backend

    • NEG globali. Puoi aggiungere un solo backend NEG internet a un di servizio di backend.
    • NEG a livello di regione. Puoi aggiungere fino a 50 NEG internet allo stesso servizio di backend.

  • Numero di endpoint per NEG

    • NEG globali. Puoi aggiungere un solo endpoint a un NEG internet.

      Poiché in ogni NEG internet globale è consentito un solo endpoint, il bilanciamento del carico non viene effettivamente eseguito. Il bilanciatore del carico funge da frontend unicamente e esegue il proxy del traffico al backend esterno specificato. Ciò significa che non puoi utilizzare nessuna delle modalità di bilanciamento del carico, come frequenza, connessione o utilizzo.

    • NEG a livello di regione. Puoi aggiungere fino a 256 endpoint per NEG allo stesso servizio di backend.

    I NEG regionali non supportano le modalità di bilanciamento del carico, come frequenza, connessione o utilizzo. Tutti gli endpoint di tutti i NEG collegati a un backend sono raggruppati in un unico gruppo. Bilanciamento del carico del traffico tra questi il pool di endpoint viene gestito utilizzando gli algoritmi di bilanciamento del carico di Envoy. Per gli algoritmi dei criteri di bilanciamento del carico supportati, consulta localityLbPolicy nella documentazione dell'API del servizio di backend regionale.

  • Controlli di integrità

  • Lo schema di bilanciamento del carico del servizio di backend deve corrispondere a quello richiesto da dal bilanciatore del carico di cui esegui il deployment. Per l'elenco completo, consulta Servizi di backend.

  • Il protocollo del servizio di backend deve essere HTTP, HTTPS o HTTP2.

    Ti consigliamo vivamente di utilizzare HTTPS o HTTP/2 come protocollo quando si configura un servizio di backend con un NEG internet, in modo che tra il bilanciatore del carico e il backend è criptato e autenticato quando in transito nella rete internet pubblica.

    Inoltre, quando utilizzi HTTPS o HTTP/2 come protocollo di backend, assicurati di utilizzare un endpoint INTERNET_FQDN_PORT per creare il backend esterno. Questo approccio presenta due vantaggi:

    • Garantisce che il bilanciatore del carico convalidi il certificato del server SSL presentato dal backend esterno e verifichi che le seguenti informazioni siano vere:

      • Il certificato è firmato da autorità di certificazione (CA) note.
      • Il certificato non è scaduto.
      • La firma del certificato è valida.
      • Il nome di dominio completo configurato corrisponde a uno dei nomi alternativi del soggetto (SAN) nel certificato.

      Se crei il backend esterno utilizzando un endpoint INTERNET_IP_PORT, La convalida dei certificati server SSL non viene eseguita.

    • L'estensione SSL Server Name Indication (SNI) è supportata solo con gli endpointINTERNET_FQDN_PORT. Il nome di dominio completo configurato è ha inviato uno SNI nel client hello durante l'handshake SSL tra il carico e l'endpoint esterno. L'SNI non viene inviato quando utilizzi un Endpoint INTERNET_IP_PORT perché i valori letterali degli indirizzi IP non sono consentiti in il campo HostName di un payload SNI.

Controlli di integrità

La configurazione del controllo di integrità varia in base al tipo di bilanciatore del carico:

  • Bilanciatore del carico delle applicazioni esterno globale e bilanciatore del carico delle applicazioni classico. Un servizio di backend con un NEG internet globale non supporta i controlli di integrità.

    Se il backend esterno non è raggiungibile o se il nome host configurato (FQDN) non può essere risolto, il bilanciatore del carico restituisce una risposta HTTP 502 (Bad Gateway) ai client.

  • Bilanciatore del carico delle applicazioni esterno regionale, bilanciatore del carico delle applicazioni interno regionale, Network Load Balancer proxy esterno regionale e bilanciatore del carico di rete proxy interno regionale. Salute i controlli sono facoltativi. I probe del controllo di integrità per questi bilanciatori del carico provengono dalla sottorete solo proxy e vengono poi tradotti tramite NAT (utilizzando Cloud NAT) in indirizzi IP pre-riservati o in indirizzi IP NAT allocati automaticamente. Per maggiori dettagli, consulta NEG a livello di regione: Utilizza un gateway Cloud NAT.

    I controlli di integrità di Envoy distribuiti vengono creati utilizzando le stesse console Google Cloud, interfacce a riga di comando gcloud e API dei controlli di integrità centralizzati. Non sono richieste altre configurazioni.

    Aspetti da considerare:

    • I controlli di integrità gRPC non sono supportati.
    • I controlli di integrità con protocollo PROXY v1 abilitato non sono supportati.

    • Poiché il piano dati Envoy gestisce i controlli di integrità, non puoi utilizzare Console Google Cloud, l'API o gcloud CLI per verificare stato di integrità di questi endpoint esterni. Per i NEG ibridi con bilanciatori del carico basati su Envoy, la console Google Cloud mostra lo stato del controllo di integrità come N/A. È previsto.

    • Ogni proxy Envoy assegnato alla subnet solo proxy nella regione nella La rete VPC avvia i controlli di integrità in modo indipendente. Di conseguenza, potresti notare un aumento del traffico di rete a causa del controllo dell'integrità. L'aumento dipende dal numero di proxy Envoy assegnati alla rete VPC in una regione, dalla quantità di traffico ricevuta da questi proxy e dal numero di endpoint di cui ogni proxy Envoy deve eseguire il controllo di salute. Nello scenario peggiore, il traffico di rete a causa dei controlli di integrità aumenta a una velocità quadratica (O(n^2)).

    • I log dei controlli di integrità per i controlli di integrità di Envoy distribuiti non includono stati di integrità dettagliati. Per informazioni dettagliate su cosa viene registrato, consulta Logging dei controlli di integrità. Per andare oltre risolvere i problemi di connettività dai proxy Envoy agli endpoint NEG, e devi controllare anche i rispettivi log del bilanciatore del carico.

Attivare il backend esterno per la ricezione delle richieste

Configura il backend esterno per consentire il traffico da Google Cloud.

Questa procedura dipende dall'ambito del NEG: globale o regionale.

NEG globali: inserisci nella lista consentita gli indirizzi IP di uscita predefiniti di Google

Se utilizzi un NEG di internet globale, devi aggiungere gli intervalli di indirizzi IP utilizzati da Google per inviare richieste ai backend esterni a un elenco consentiti. Per cercare gli indirizzi IP da aggiungere a una lista consentita, esegui una query sul record TXT DNS _cloud-eoips.googleusercontent.com utilizzando uno strumento come dig o nslookup.

Per un esempio, consulta Consenti al backend esterno di ricevere traffico da Google Cloud.

NEG regionali: utilizza un gateway Cloud NAT

Se utilizzi un NEG internet regionale, devi prima configurare un gateway Cloud NAT per allocare un insieme di intervalli di indirizzi IP da cui deve provenire il traffico di Google Cloud.

L'endpoint del gateway deve essere di tipo ENDPOINT_TYPE_MANAGED_PROXY_LB.

Il gateway Cloud NAT può essere configurato per allocare automaticamente gli indirizzi IP esterni in base alla domanda o utilizzare un insieme di indirizzi IP esterni prenotati manualmente.

  • Indirizzi IP allocati automaticamente

    Utilizza indirizzi IP allocati automaticamente se il tuo ambiente di backend esterno non richiede di aggiungere indirizzi IP Google Cloud specifici che possono inviare traffico al backend esterno a una lista consentita.

  • Indirizzi IP allocati manualmente

    Utilizza gli indirizzi IP allocati manualmente solo se il tuo ambiente di backend esterno richiede di aggiungere indirizzi IP Google Cloud specifici a una lista consentita. Poiché ogni Envoy assegnato alla subnet del proxy consuma un intero indirizzo IP, assicurati che il pool di indirizzi IP riservati sia sufficientemente grande per ospitare tutti gli Envoy.

    Se riscontri problemi di connettività su larga scala, controlla se hai raggiunto i limiti di Cloud NAT. Per impostazione predefinita, puoi avere un massimo di 50 indirizzi IP NAT assegnati manualmente per gateway.

Questa configurazione Cloud NAT si applica all'intera subnet solo proxy. Traffico Internet associato a tutto il carico regionale basato su Envoy bilanciatori della regione lo stesso gateway NAT.

L'utilizzo di Cloud NAT comporta addebiti sia per il traffico utente sia per il controllo di integrità per via del traffico. Per dettagli su come funzionano i prezzi del NEG internet a livello di regione, vedi Prezzi NEG internet a livello di regione.

Esistono alcune limitazioni per i gateway NAT configurati su subnet solo proxy:

  • Viene eseguita solo la traduzione NAT uno a uno. La condivisione dell'indirizzo IP non è supportati.
  • Il logging e il monitoraggio non sono supportati. Questo i flag --enable-logging e --log-filter non sono supportati.
  • Le funzionalità relative alle porte, come l'allocazione statica e dinamica delle porte, l'impostazione del numero massimo e minimo di porte per VM e la mappatura indipendente dagli endpoint, non sono supportate. Ogni proxy riceve tutte le 65536 porte.

Autentica le richieste nel backend esterno

Questa sezione si applica solo ai bilanciatori del carico delle applicazioni.

Per autenticare le richieste inviate al tuo backend esterno, puoi eseguire una delle seguenti operazioni:

  • Imposta un'intestazione personalizzata per indicare che la richiesta proviene da un bilanciatore del carico Google Cloud utilizzando un'intestazione personalizzata della richiesta. Ad esempio, puoi utilizzare 16 o più byte casuali crittografici come chiave condivisa.

    L'implementazione delle trasformazioni delle intestazioni personalizzate dipende dal tipo di bilanciatore del carico in uso:

    • Bilanciatore del carico delle applicazioni esterno globale e bilanciatore del carico delle applicazioni classico. Le trasformazioni degli intestazioni personalizzate possono essere configurate nel servizio di backend o nella mappa di URL.

      Ad esempio, puoi configurare il backend esterno in modo che preveda un determinato valore per l'intestazione Host della richiesta HTTP e puoi configurare il bilanciatore del carico in modo che imposti l'intestazione Host su quel valore previsto. In caso contrario configurare un'intestazione della richiesta personalizzata, il bilanciatore del carico conserva usato dal client per connettersi al bilanciatore del carico e include nella sua risposta. Tuttavia, tieni presente che la modifica dell'intestazione Host non supportato nella mappa URL.

      Esistono ulteriori limitazioni associate alla configurazione Intestazione Host. Per maggiori dettagli, consulta Creare intestazioni personalizzate nel backend Google Cloud. Per un example specifico, consulta Configurare un bilanciatore del carico delle applicazioni esterno globale con un backend esterno.

    • Bilanciatore del carico delle applicazioni esterno regionale e bilanciatore del carico delle applicazioni interno regionale. Intestazione personalizzata le trasformazioni possono essere configurate solo sull'URL mappa.

      Per questi bilanciatori del carico basati su Envoy, Host e authority sono chiavi speciali riservate a Google Cloud. Non puoi modificare queste intestazioni per questi bilanciatori del carico. Ti consigliamo invece di creare altri intestazioni personalizzate (ad esempio MyHost) in modo da non interferire con i nomi delle intestazioni riservate.

  • Attiva l'IAP e verifica che il JWT firmato nell'intestazione della richiesta sia firmato da Google e che il claim aud (segmento di pubblico) contenga il numero del progetto in cui è definito il bilanciatore del carico.

    Tieni presente quanto segue:

    • IAP non è compatibile con Cloud CDN.
    • IAP non è supportato con i bilanciatori del carico delle applicazioni esterni regionali e proxy del carico di rete (interni ed esterni).
  • Abilita origine privata dell'autenticazione, che fornisce a un bilanciatore del carico delle applicazioni esterno l'accesso a lungo termine a un'istanza Amazon Simple Storage privata Bucket di servizio (Amazon S3) o altri archivi di oggetti compatibili. Cloud CDN (e quindi l'autenticazione dell'origine privata) Supportata con bilanciatori del carico delle applicazioni esterni regionali e bilanciatori del carico delle applicazioni interni regionali.

Log

Le richieste proxy a un backend esterno vengono registrate in Cloud Logging nello stesso modo in cui vengono registrate le richieste per altri backend.

Per ulteriori informazioni, consulta le seguenti risorse:

Se attivi Cloud CDN per un bilanciatore del carico delle applicazioni esterno che utilizza un backend esterno, vengono registrati anche i hit della cache.

Elaborazione degli header con backend esterni

Bilanciatori del carico diversi possono gestire l'elaborazione delle intestazioni in modi diversi quando le richieste a un backend esterno. Esamina le seguenti informazioni per comprendere in che modo il tipo di bilanciatore del carico potrebbe elaborare le intestazioni HTTP.

Bilanciatori del carico delle applicazioni esterni globali e bilanciatori del carico delle applicazioni classici

Quando un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico esegue il proxy delle richieste a un backend esterno, regola le intestazioni HTTP nei seguenti modi:

  • Alcune intestazioni sono unite. Quando sono presenti più istanze della stessa chiave di intestazione (ad esempio Via), il bilanciatore del carico combina i relativi valori in un unico elenco separato da virgole per una singola chiave di intestazione. Vengono unite solo le intestazioni cuyos valori possono essere rappresentati come elenco separato da virgole. Altro come Set-Cookie, non vengono mai unite.

  • Le intestazioni hanno lettere maiuscole corrette quando il protocollo del servizio di backend è HTTP o HTTPS:

    • La prima lettera della chiave dell'intestazione e ogni lettera che segue un trattino (-) contiene le lettere maiuscole per preservare la compatibilità con i client HTTP/1.1. Per Ad esempio, user-agent viene modificato in User-Agent e content-encoding è cambiato in Content-Encoding.

    • Alcune intestazioni, come Accept-CH (suggerimenti per il cliente), vengono convertite in modo da corrispondere alla rappresentazione standard con lettere miste.

  • Vengono aggiunte alcune intestazioni o vengono aggiunti valori. Bilanciatori del carico delle applicazioni esterni Aggiungere o modificare sempre determinate intestazioni come Via e X-Forwarded-For.

Bilanciatori del carico delle applicazioni esterni regionali e bilanciatori del carico delle applicazioni interni regionali

Non è prevista alcuna elaborazione speciale dell'intestazione per i bilanciatori del carico basati su Envoy NEG internet. Per informazioni su come Envoy elabora generalmente le intestazioni, consulta Intestazione HTTP del linguaggio naturale.

Limitazioni

  • Consulta la sezione relativa ai servizi di backend per informazioni sulle limitazioni associate alla configurazione di NEG di internet come backend.
  • Quando modifichi un bilanciatore del carico per cambiare il backend da un NEG internet a con qualsiasi altro tipo di backend, oppure cambiare il tipo di backend da qualsiasi altro tipo di backend un NEG internet, la tua applicazione ha un tempo di inattività temporaneo di circa 30-90 secondi. Ad esempio, durante questo tempo di riposo, i client che inviano richieste ai bilanciatori del carico delle applicazioni esterni globali vedono errori 502 con il codice failed_to_connect_to_backend. Si tratta di un comportamento previsto.
  • Le seguenti funzionalità di gestione avanzata del traffico non sono supportate con Backend NEG internet globali:
    • Richiedi mirroring
    • Criteri di ripetizione
    • Criteri di traffico (inclusi il criterio di località per il bilanciamento del carico, l'affinità sessione e il rilevamento di outlier)
  • Esamina la sezione Gateway Cloud NAT per conoscere le limitazioni associati a gateway NAT configurati su subnet solo proxy.

Quote e limiti

Per informazioni su quote e limiti, consulta Backend del NEG della quota e gli endpoint per NEG della quota di spazio di archiviazione.

Prezzi

Il traffico in uscita verso gli endpoint NEG internet esterni viene addebitato al traffico in uscita da internet tariffe per il networking del livello Premium. La fonte si basa sulla posizione del client e la destinazione sulla posizione dell'endpoint pubblico.

Se hai configurato un gateway Cloud NAT per mappare la subnet solo proxy del bilanciatore del carico regionale basato su Envoy, ti verranno addebitati gli addebiti di Cloud NAT. I gateway Cloud NAT allocati per i bilanciatori del carico comportano addebiti orari equivalenti a una rete con più di 32 istanze VM. Per maggiori dettagli, consulta Prezzi di Cloud NAT.

Per ulteriori informazioni, consulta Cloud Load Balancing prezzi.

Passaggi successivi