Panoramica dei gruppi di endpoint di rete con connettività ibrida

Cloud Load Balancing supporta il bilanciamento del carico del traffico verso endpoint che vanno oltre Google Cloud, come i data center on-premise e altri cloud pubblici che puoi raggiungere utilizzando la connettività ibrida.

Una strategia ibrida è una soluzione pragmatica per adattarsi alle mutate esigenze del mercato e modernizzare gradualmente le applicazioni. Potrebbe trattarsi di un deployment ibrido temporaneo per consentire la migrazione a una soluzione moderna basata su cloud o di un elemento permanente dell'infrastruttura IT della tua organizzazione.

La configurazione del bilanciamento del carico ibrida ti consente inoltre di usufruire dei vantaggi delle funzionalità di rete di Cloud Load Balancing per i servizi in esecuzione sulla tua infrastruttura esistente al di fuori di Google Cloud.

Il bilanciamento del carico ibrido è supportato sui seguenti bilanciatori del carico Google Cloud:

I servizi on-premise e di altri cloud vengono trattati come qualsiasi altro backend di Cloud Load Balancing. La differenza principale è che utilizzi un NEG di connettività ibrida per configurare gli endpoint di questi backend. Gli endpoint devono essere combinazioni IP:port valide che il bilanciatore del carico può raggiungere utilizzando prodotti di connettività ibrida come Cloud VPN o Cloud Interconnect.

Caso d'uso: instradamento del traffico verso una posizione on-premise o un altro cloud

Il caso d'uso più semplice per l'utilizzo di NEG ibride è il routing del traffico da un bilanciatore del carico Google Cloud a una posizione on-premise o a un altro ambiente cloud. I client possono generare traffico dall'internet pubblico, da Google Cloud o da un client on-premise.

Client pubblici

Puoi utilizzare un bilanciatore del carico delle applicazioni esterno con un backend NEG ibrido per instradare il traffico dai client esterni a un backend on-premise o in un'altra rete cloud. Puoi anche attivare le seguenti funzionalità di networking a valore aggiunto per i tuoi servizi on-premise o in altre reti cloud:

  • Con il bilanciatore del carico delle applicazioni esterno globale e il bilanciatore del carico delle applicazioni classico, puoi:

    • Utilizza l'infrastruttura perimetrale globale di Google per terminare le connessioni degli utenti più vicino all'utente, riducendo così la latenza.
    • Proteggi il tuo servizio con Google Cloud Armor, un prodotto di sicurezza WAF/di difesa DDoS di primo livello disponibile per tutti i servizi a cui si accede tramite un bilanciatore del carico delle applicazioni esterno.
    • Consenti al tuo servizio di ottimizzare la distribuzione utilizzando Cloud CDN. Con Cloud CDN, puoi memorizzare nella cache i contenuti vicino ai tuoi utenti. Cloud CDN offre funzionalità come l'annullamento della convalida della cache e gli URL firmati di Cloud CDN.
    • Utilizza certificati SSL gestiti da Google. Puoi riutilizzare i certificati e le chiavi private che utilizzi già per altri prodotti Google Cloud. In questo modo, non è necessario gestire certificati separati.

    Il seguente diagramma mostra un deployment ibrido con un bilanciatore del carico delle applicazioni esterno.

    Connettività ibrida con un bilanciatore del carico delle applicazioni esterno globale.
    Connettività ibrida con un bilanciatore del carico delle applicazioni esterno globale (fai clic per ingrandire).

    In questo diagramma, il traffico proveniente dai client su internet pubblico entra nella tua rete privata on-premise o cloud tramite un bilanciatore del carico Google Cloud, ad esempio l'Application Load Balancer esterno. Quando il traffico raggiunge il bilanciatore del carico, puoi applicare servizi di rete di confine come la protezione DDoS di Google Cloud Armor o l'autenticazione utente di Identity-Aware Proxy (IAP).

  • Con il bilanciatore del carico delle applicazioni esterno regionale, puoi instradare il traffico esterno agli endpoint che si trovano nella stessa regione Google Cloud delle risorse del bilanciatore del carico. Utilizza questo bilanciatore del carico se devi pubblicare contenuti da una sola geolocalizzazione (ad esempio per soddisfare le normative di conformità) o se preferisci il livello di servizio di rete standard.

Il modo in cui la richiesta viene instradata (a un backend Google Cloud o a un endpoint on-premise/cloud) dipende dalla configurazione della mappa URL. A seconda della mappa URL, il bilanciatore del carico seleziona un servizio di backend per la richiesta. Se il servizio di backend selezionato è stato configurato con un NEG di connettività ibrida (utilizzato solo per gli endpoint non Google Cloud), il bilanciatore del carico inoltra il traffico tramite Cloud VPN o Cloud Interconnect alla destinazione esterna prevista.

Clienti interni (all'interno di Google Cloud o on-premise)

Puoi anche configurare un deployment ibrido per i clienti interni a Google Cloud. In questo caso, il traffico client proviene dalla rete VPC di Google Cloud, dalla rete on-premise o da un altro cloud e viene indirizzato agli endpoint on-premise o in altre reti cloud.

Il bilanciatore del carico delle applicazioni interno regionale è un bilanciatore del carico a livello di area geografica, il che significa che può indirizzare il traffico solo agli endpoint all'interno della stessa regione Google Cloud delle risorse del bilanciatore del carico. Il bilanciatore del carico delle applicazioni interno tra regioni è un bilanciatore del carico multiregione che può bilanciare il carico del traffico verso i servizi di backend distribuiti a livello mondiale.

Il seguente diagramma mostra un deployment ibrido con un bilanciatore del carico delle applicazioni interno regionale.

Connettività ibrida con bilanciatori del carico delle applicazioni interni regionali.
Connettività ibrida con bilanciatori del carico delle applicazioni interni regionali (fai clic per ingrandire).

Caso d'uso: migrazione al cloud

La migrazione di un servizio esistente al cloud ti consente di liberare la capacità on-premise e ridurre il costo e l'onere della manutenzione dell'infrastruttura on-premise. Puoi configurare temporaneamente un deployment ibrido che ti consenta di instradare il traffico sia al tuo attuale servizio on-premise sia a un endpoint del servizio Google Cloud corrispondente.

Il seguente diagramma mostra questa configurazione con un bilanciatore del carico delle applicazioni interno.

Esegui la migrazione a Google Cloud.
Esegui la migrazione a Google Cloud (fai clic per ingrandire).

Se utilizzi un bilanciatore del carico delle applicazioni interno per gestire i client interni, puoi configurare il bilanciatore del carico di Google Cloud in modo da utilizzare la suddivisione del traffico in base al peso per suddividere il traffico tra i due servizi. La suddivisione del traffico ti consente di iniziare inviando lo 0% del traffico al servizio Google Cloud e il 100% al servizio on-premise. Puoi quindi aumentare gradualmente la proporzione di traffico inviato al servizio Google Cloud. Alla fine, invii il 100% del traffico al servizio Google Cloud e puoi ritirare il servizio on-premise.

Architettura ibrida

Questa sezione descrive l'architettura e le risorse di bilanciamento del carico necessarie per configurare un deployment di bilanciamento del carico ibrido.

I servizi on-premise e di altri cloud sono come qualsiasi altro backend di Cloud Load Balancing. La differenza principale è che utilizzi un NEG di connettività ibrida per configurare gli endpoint di questi backend. Gli endpoint devono essere combinazioni IP:port valide che i clienti possono raggiungere tramite connettività ibrida, ad esempio Cloud VPN o Cloud Interconnect.

I seguenti diagrammi mostrano le risorse Google Cloud necessarie per attivare il bilanciamento del carico ibrido per i bilanciatori del carico delle applicazioni esterni e i bilanciatori del carico delle applicazioni interni a livello di regione.

HTTP(S) esterno globale

Risorse di bilanciatori del carico delle applicazioni esterni globali per la connettività ibrida.
Risorse del bilanciatore del carico delle applicazioni esterno globale per la connettività ibrida (fai clic per ingrandire).

HTTP(S) esterno regionale

Risorse del bilanciatore del carico delle applicazioni esterno regionale per la connettività ibrida.
Risorse per bilanciatori del carico delle applicazioni esterni regionali per la connettività ibrida (fai clic per ingrandire).

HTTP(S) interno regionale

Risorse del bilanciatore del carico delle applicazioni interno regionale per la connettività ibrida.
Risorse per bilanciatori del carico delle applicazioni interni regionali per la connettività ibrida (fai clic per ingrandire).

Proxy interno regionale

Risorse di bilanciatori del carico di rete proxy interno regionali per la connettività ibrida.
Risorse per bilanciatori del carico di rete proxy interni regionali per la connettività ibrida (fai clic per ingrandire).

A livello di regione e a livello globale

Il routing di Cloud Load Balancing dipende dall'ambito del bilanciatore del carico configurato:

Bilanciatore del carico delle applicazioni esterno e bilanciatore del carico di rete proxy esterno. Questi bilanciatori del carico possono essere configurati per il routing globale o regionale, a seconda del livello di rete utilizzato. Crea il backend NEG ibrida del bilanciatore del carico nella stessa rete e nella stessa regione in cui è stata configurata la connettività ibrida. Anche gli endpoint non Google Cloud devono essere configurati di conseguenza per sfruttare il bilanciamento del carico in base alla vicinanza.

Bilanciatore del carico delle applicazioni interno tra regioni e bilanciatore del carico di rete proxy interno tra regioni. Si tratta di un bilanciatore del carico multiregione che può bilanciare il carico del traffico verso i servizi di backend distribuiti a livello globale. Crea il backend NEG ibrido del bilanciatore del carico nella stessa rete e nella stessa regione in cui è stata configurata la connettività ibrida. Anche gli endpoint non Google Cloud devono essere configurati di conseguenza per sfruttare il bilanciamento del carico in base alla vicinanza.

Bilanciatore del carico delle applicazioni interno regionale e bilanciatore del carico di rete proxy interno regionale. Si tratta di bilanciatori del carico regionali. In altre parole, possono instradare il traffico solo agli endpoint all'interno della stessa regione del bilanciatore del carico. I componenti del bilanciatore del carico devono essere configurati nella stessa regione in cui è stata configurata la connettività ibrida. Per impostazione predefinita, anche i client che accedono al bilanciatore del carico devono trovarsi nella stessa regione. Tuttavia, se attivi l'accesso globale, i client di qualsiasi regione possono accedere al bilanciatore del carico.

Ad esempio, se il gateway Cloud VPN o l'collegamento VLAN Cloud Interconnect è configurato in REGION_A, le risorse richieste dal bilanciatore del carico (ad esempio un servizio di backend, un NEG ibrido o regola di forwarding) devono essere create nella regione REGION_A. Per impostazione predefinita, i client che accedono al bilanciatore del carico devono trovarsi anche nella regione REGION_A. Tuttavia, se attivi l'accesso globale, i client di qualsiasi regione possono accedere al bilanciatore del carico.

Requisiti per la connettività di rete

Prima di configurare un deployment di bilanciamento del carico ibrida, devi aver configurato le seguenti risorse:

  • Rete VPC Google Cloud. Una rete VPC configurata in Google Cloud. Si tratta della rete VPC utilizzata per configurare Cloud Interconnect/Cloud VPN e router Cloud. Si tratta anche della stessa rete in cui creerai le risorse di bilanciamento del carico (regola di forwarding, proxy di destinazione, servizio di backend e così via). Gli indirizzi IP e gli intervalli di indirizzi IP delle subnet on-premise, di altri cloud e di Google Cloud non devono sovrapporsi. Quando gli indirizzi IP si sovrappongono, le route di subnet hanno la priorità sulla connettività remota.

  • Connettività ibrida. Gli ambienti Google Cloud e on-premise o di altri cloud devono essere connessi tramite connettività ibrida, utilizzando i collegamenti VLAN di Cloud Interconnect o i tunnel Cloud VPN con router Cloud. Ti consigliamo di utilizzare una connessione ad alta disponibilità. Un router Cloud abilitato al routing dinamico globale viene a conoscenza dell'endpoint specifico tramite BGP e lo programma nella rete VPC di Google Cloud. Il routing dinamico regionale non è supportato. Inoltre, le route statiche non sono supportate.

    Cloud Interconnect/Cloud VPN e router Cloud devono essere configurati nella stessa rete VPC che intendi utilizzare per il deployment del bilanciamento del carico ibrida. Il router Cloud deve inoltre annunciare le seguenti route al tuo ambiente on-premise:

    • Intervalli utilizzati dai controlli di integrità di Google: 35.191.0.0/16 e 130.211.0.0/22. Questo è necessario per i bilanciatori del carico delle applicazioni esterni globali, per i bilanciatori del carico delle applicazioni classici, per i bilanciatori del carico di rete con proxy esterno globali e per i bilanciatori del carico di rete con proxy classici.

    • L'intervallo della subnet solo proxy della regione: per i bilanciatori del carico basati su Envoy: bilanciatori del carico delle applicazioni esterni regionali, bilanciatori del carico delle applicazioni interni regionali, bilanciatori del carico delle applicazioni interni tra regioni, bilanciatori del carico di rete proxy esterni regionali, bilanciatori del carico di rete proxy interni tra regioni e bilanciatori del carico di rete proxy interni regionali.

      La subnet solo proxy della regione pubblicitaria è necessaria anche per il funzionamento dei controlli di integrità di Envoy distribuiti. Il controllo di integrità di Envoy distribuito è il meccanismo di controllo di integrità predefinito per i NEG connettività ibrida a livello di zona (ovvero gli endpoint NON_GCP_PRIVATE_IP_PORT) dietro i bilanciatori del carico basati su Envoy.

  • Endpoint di rete (IP:Port) on-premise o in altri cloud. Uno o più IP:Port endpoint di rete configurati nei tuoi ambienti on-premise o in altri ambienti cloud, instradabili utilizzando Cloud Interconnect o Cloud VPN. Se esistono più percorsi per l'endpoint IP, il routing seguirà il comportamento descritto nella panoramica dei percorsi VPC e nella panoramica di Cloud Router.

  • Regole firewall on-premise o su un altro cloud. Le seguenti regole del firewall devono essere create nel tuo ambiente on-premise o in un altro ambiente cloud:

    • Le regole firewall in entrata consentono il traffico dai probe di controllo di integrità di Google ai tuoi endpoint. Gli intervalli consentiti sono: 35.191.0.0/16 e 130.211.0.0/22. Tieni presente che questi intervalli devono essere annunciati anche dal router Cloud alla tua rete on-premise. Per maggiori dettagli, vedi Intervalli IP di ispezione e regole firewall.
    • Le regole firewall di autorizzazione in entrata consentono al traffico sottoposto a bilanciamento del carico di raggiungere gli endpoint.
    • Per i bilanciatori del carico basati su Envoy, ovvero bilanciatori del carico delle applicazioni esterni regionali,bilanciatori del carico delle applicazioni interni regionali, bilanciatori del carico delle applicazioni interni tra regioni,bilanciatori del carico di rete proxy esterni regionali, bilanciatori del carico di rete proxy interni tra regioni e bilanciatori del carico di rete proxy interni regionali, devi anche creare una regola firewall per consentire il traffico dalla subnet solo proxy della regione per raggiungere gli endpoint on-premise o in altri ambienti cloud.

Componenti del bilanciatore del carico

A seconda del tipo di bilanciatore del carico, puoi configurare un'implementazione del bilanciamento del carico ibrido utilizzando i livelli di servizio di rete Standard o Premium.

Un bilanciatore del carico ibrido richiede una configurazione speciale solo per il servizio di backend. La configurazione del frontend è la stessa di qualsiasi altro bilanciatore del carico. I bilanciatori del carico basati su Envoy, ovvero bilanciatori del carico delle applicazioni esterni regionali, bilanciatori del carico delle applicazioni interni regionali, bilanciatori del carico delle applicazioni interni tra regioni,bilanciatori del carico di rete proxy esterni regionali, bilanciatori del carico di rete proxy interni tra regioni, e bilanciatori del carico di rete proxy interni regionali, richiedono un'ulteriore subnet solo per proxy per eseguire i proxy Envoy per tuo conto.

Configurazione frontend

Per il bilanciamento del carico ibrido non è richiesta alcuna configurazione frontend speciale. 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.

Le mappe URL vengono utilizzate dai bilanciatori del carico HTTP(S) 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 delle panoramiche specifiche dei bilanciatori del carico:

Servizio di backend

I servizi di backend forniscono informazioni di configurazione 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 deployment di bilanciamento del carico ibrido, configura il bilanciatore del carico con backend sia all'interno che all'esterno di Google Cloud.

  • Backend non Google Cloud (on-premise o altro cloud)

    Qualsiasi destinazione che puoi raggiungere utilizzando i prodotti di connettività ibrida di Google (Cloud VPN o Cloud Interconnect) e che può essere raggiunta con una combinazione IP:Port valida può essere configurata come endpoint per il bilanciatore del carico.

    Configura i backend non Google Cloud nel seguente modo:

    1. Aggiungi ogni combinazione IP:Port di endpoint di rete non Google Cloud a un gruppo di endpoint di rete con connettività ibrida (NEG). Assicurati che questo indirizzo IP e questa porta siano raggiungibili da Google Cloud utilizzando la connettività ibrida (tramite Cloud VPN o Cloud Interconnect). Per i gruppi di endpoint di rete con connettività ibrida, imposta il tipo di endpoint di rete su NON_GCP_PRIVATE_IP_PORT.
    2. Durante la creazione del NEG, specifica una zona di Google Cloud che minimizza la distanza geografica tra Google Cloud e il tuo ambiente on-premise o un altro ambiente cloud. Ad esempio, se ospiti un servizio in un ambiente on-premise a Francoforte, in Germania, puoi specificare la zona europe-west3-a Google Cloud quando crei il NEG.

    3. Aggiungi questo NEG di connettività ibrida come backend per il servizio di backend.

      Un NEG di connettività ibrida deve includere solo endpoint non Google Cloud. Il traffico potrebbe essere perso se un NEG ibrido include endpoint per le risorse all'interno di una rete VPC di Google Cloud, ad esempio gli indirizzi IP regola di forwarding per i bilanciatori del carico di rete passthrough interni. Configura gli endpoint Google Cloud come indicato nella sezione successiva.

  • Backend di Google Cloud

    Configura gli endpoint Google Cloud come segue:

    1. Crea un servizio di backend separato per i backend Google Cloud.
    2. Configura più backend (GCE_VM_IP_PORT NEG zonali o gruppi di istanze) all'interno della stessa regione in cui hai configurato la connettività ibrida.

Altri aspetti da considerare:

  • Ogni NEG di connettività ibrida può contenere solo endpoint di rete dello stesso tipo (NON_GCP_PRIVATE_IP_PORT).

  • Puoi utilizzare un singolo servizio di backend per fare riferimento sia ai backend basati su Google Cloud (utilizzando NEG zonali con endpoint GCE_VM_IP_PORT) sia ai backend on-premise o di altri cloud (utilizzando NEG di connettività ibrida con endpoint NON_GCP_PRIVATE_IP_PORT). Non è consentita alcuna altra combinazione di tipi di backend misti. Cloud Service Mesh non supporta tipi di backend misti in un singolo servizio di backend.

  • Lo schema di bilanciamento del carico del servizio di backend deve essere uno dei seguenti:

    • EXTERNAL_MANAGED per bilanciatori del carico delle applicazioni esterni globali, bilanciatori del carico delle applicazioni esterni a livello di regione, bilanciatori del carico di rete proxy esterni globali e bilanciatori del carico di rete proxy esterni a livello di regione

    • EXTERNAL per bilanciatori del carico delle applicazioni e bilanciatori del carico di rete proxy classici

    • INTERNAL_MANAGED per i bilanciatori del carico delle applicazioni interni e i bilanciatori del carico di rete proxy interni

    INTERNAL_SELF_MANAGED è supportato per i deployment multi-ambiente di Cloud Service Mesh con NEG di connettività ibrida.

  • Il protocollo del servizio di backend deve essere HTTP, HTTPS o HTTP2 per i bilanciatori del carico delle applicazioni e TCP o SSL per i bilanciatori del carico di rete proxy. Per l'elenco dei protocolli dei servizio di backend supportati da ciascun bilanciatore del carico, consulta Protocolli dal bilanciatore del carico al backend.

  • La modalità di bilanciamento per il backend NEG ibrido deve essere RATE per i bilanciatori del carico delle applicazioni e CONNECTION per i bilanciatori del carico di rete proxy. Per informazioni dettagliate sulle modalità di bilanciamento, consulta la Panoramica dei servizi di backend.

  • Per aggiungere altri endpoint di rete, aggiorna i backend associati al servizio di backend.

  • Se utilizzi controlli di integrità Envoy distribuiti con backend NEG di connettività ibrida (supportati solo per i bilanciatori del carico basati su Envoy), assicurati di configurare endpoint di rete univoci per tutti i NEG collegati allo stesso servizio di backend. L'aggiunta dello stesso endpoint di rete a più NEG comporta un comportamento indefinito.

Controlli di integrità centralizzati

I controlli di integrità centralizzati, quando si utilizzano NEG ibride, sono obbligatori per i bilanciatori del carico delle applicazioni esterni globali, i bilanciatori del carico delle applicazioni classici, i bilanciatori del carico di rete con proxy esterno globali e i bilanciatori del carico di rete con proxy classici. Altri bilanciatori del carico basati su Envoy utilizzano i controlli di integrità di Envoy distribuiti come descritto nella sezione seguente.

Per gli endpoint NON_GCP_PRIVATE_IP_PORT esterni a Google Cloud, crea regole firewall sulle reti on-premise e su altre reti cloud. Contatta l'amministratore di rete per questo. Il router Cloud utilizzato per la connettività ibrida deve annunciare anche gli intervalli utilizzati dai probe di controllo dell'integrità di Google. Gli intervalli da pubblicizzare sono 35.191.0.0/16 e 130.211.0.0/22.

Per altri tipi di backend in Google Cloud, crea regole firewall su Google Cloud come dimostrato in questo esempio.

Documentazione correlata:

Controlli di integrità di Envoy distribuiti

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

  • Bilanciatore del carico delle applicazioni esterno globale, bilanciatore del carico delle applicazioni classico, bilanciatore del carico di rete proxy esterno globale e bilanciatore del carico di rete proxy classico. Questi bilanciatori del carico non supportano i controlli di integrità di Envoy distribuiti. Utilizzano il meccanismo di controllo di integrità centralizzato di Google, come descritto nella sezione Controlli di integrità centralizzati.

  • 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, bilanciatore del carico di rete proxy interno tra regioni e bilanciatore del carico delle applicazioni interno tra regioni. Questi bilanciatori del carico utilizzano i controlli di integrità di Envoy distribuiti per verificare l'integrità dei NEG ibridi. I probe del controllo di integrità provengono dal software proxy Envoy stesso. Ogni servizio di backend deve essere associato a un controllo di integrità che ne verifichi l'integrità. I probe del controllo di integrità provengono dai proxy Envoy nella subnet solo proxy della regione. Affinché i probe del controllo di integrità funzionino correttamente, devi creare regole firewall nell'ambiente esterno che consentano al traffico dalla subnet solo proxy di raggiungere i tuoi backend esterni.

    Per gli endpoint NON_GCP_PRIVATE_IP_PORT esterni a Google Cloud, devi creare queste regole firewall sulle reti on-premise e su altre reti cloud. Contatta l'amministratore di rete per questo. Il router Cloud che utilizzi per la connettività ibrida deve annunciare anche l'intervallo di subnet solo proxy della regione.

I controlli di integrità di Envoy distribuiti vengono creati utilizzando le stesse procedure della console Google Cloud, dell'interfaccia alla gcloud CLI e dell'API dei controlli di integrità centralizzati. Non sono necessarie altre configurazioni.

Aspetti da considerare:

  • I controlli di integrità gRPC non sono supportati.
  • I controlli di integrità con il protocollo PROXY versione 1 abilitato non sono supportati.
  • Se utilizzi NEG misti in cui un singolo servizio di backend ha una combinazione di NEG zonali (endpoint GCE_VM_IP_PORT all'interno di Google Cloud) e NEG ibride (endpoint NON_GCP_PRIVATE_IP_PORT esterni a Google Cloud), devi configurare regole firewall per consentire il traffico dagli intervalli di indirizzi IP delle sonde di controllo di integrità di Google (130.211.0.0/22 e 35.191.0.0/16) agli endpoint NEG zonali su Google Cloud. Questo perché i NEG zonali utilizzano il sistema centralizzato di controllo di integrità di Google.

  • Poiché il piano dati di Envoy gestisce i controlli di integrità, non puoi utilizzare la console Google Cloud, l'API o l'gcloud CLI per controllare lo 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 della 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 risolvere ulteriormente i problemi di connettività dai proxy Envoy agli endpoint NEG, devi anche controllare i rispettivi log del bilanciatore del carico.

Documentazione correlata:

Limitazioni

  • Il router Cloud utilizzato per la connettività ibrida deve essere abilitato con il routing dinamico globale. Il routing dinamico regionale e le route statiche non sono supportati.
  • Per i bilanciatori del carico regionali basati su Envoy, ovvero bilanciatori del carico delle applicazioni esterni regionali, bilanciatori del carico di rete proxy esterni regionali, bilanciatori del carico di rete proxy interni regionali e bilanciatori del carico delle applicazioni interni regionali, la connettività ibrida deve essere configurata nella stessa regione del bilanciatore del carico. Se sono configurati in regioni diverse, i backend potrebbero essere considerati integri, ma le richieste dei client non verranno inoltrate ai backend.

  • Le considerazioni relative alle connessioni criptate dal bilanciatore del carico ai backend documentate qui si applicano anche agli endpoint di backend non Google Cloud configurati nel NEG di connettività ibrida.

    Assicurati di controllare anche le impostazioni di sicurezza della configurazione della connettività ibrida. Al momento, le connessioni VPN ad alta disponibilità sono criptate per impostazione predefinita (IPsec). Le connessioni Cloud Interconnect non sono criptate per impostazione predefinita. Per maggiori dettagli, consulta il white paper sulla crittografia dei dati in transito.

Logging

Le richieste proxy a un endpoint in un NEG ibrido vengono registrate in Cloud Logging nello stesso modo in cui vengono registrate le richieste per altri backend. Se attivi Cloud CDN per il bilanciatore del carico delle applicazioni esterno globale, vengono registrati anche i hit della cache.

Per ulteriori informazioni, vedi:

Quota

Puoi configurare tutti i NEG ibridi con endpoint di rete consentiti dalla quota del gruppo di endpoint di rete esistente. Per ulteriori informazioni, consulta Backend NEG e Endpoint per NEG.

Passaggi successivi