Traffic Director con gruppi di endpoint di rete con connettività ibrida

Traffic Director supporta ambienti che vanno oltre Google Cloud, tra cui data center on-premise e altri cloud pubblici raggiungibili tramite la connettività ibrida.

Puoi configurare Traffic Director in modo che il tuo mesh di servizi possa inviare traffico a endpoint esterni a Google Cloud. Questi endpoint includono quanto segue:

  • Bilanciatori del carico on-premise.
  • Applicazioni server su un'istanza di macchina virtuale (VM) in un altro cloud.
  • Qualsiasi altra destinazione che puoi raggiungere con la connettività ibrida e che può essere raggiunta con un indirizzo IP e una porta.

Aggiungi l'indirizzo IP e la porta di ogni endpoint a un gruppo di endpoint di rete (NEG) con connettività ibrida. I NEG di connettività ibrida sono di tipo NON_GCP_PRIVATE_IP_PORT.

Il supporto di Traffic Director per i servizi on-premise e multi-cloud ti consente di:

  • Instrada il traffico a livello globale, inclusi gli endpoint dei servizi on-premise e multi-cloud.
  • Sfrutta i vantaggi di Traffic Director e del mesh di servizi, tra cui funzionalità come Service Discovery e la gestione avanzata del traffico, ai servizi in esecuzione sulla tua infrastruttura esistente al di fuori di Google Cloud.
  • Combina le funzionalità di Traffic Director con Cloud Load Balancing per portare i servizi di networking di Google Cloud in più ambienti.

I NEG di connettività ibrida (NON_GCP_PRIVATE_IP_PORT NEG) non sono supportati con i client gRPC senza proxy.

Casi d'uso

Traffic Director può configurare il networking tra servizi basati su VM e su container in più ambienti, tra cui:

  • Google Cloud
  • Data center on-premise
  • Altri cloud pubblici

Instrada il traffico mesh verso una località on-premise o un altro cloud

Il caso d'uso più semplice per questa funzionalità è il routing del traffico. La tua applicazione esegue un proxy Envoy Traffic Director . Traffic Director comunica al client i tuoi servizi e gli endpoint di ogni servizio.

Routing del traffico mesh a una località on-premise o a un altro cloud.
Routing del traffico mesh a una località on-premise o a un altro cloud (fai clic per ingrandire)

Nel diagramma precedente, quando l'applicazione invia una richiesta al servizio on-prem, il client Traffic Director controlla la richiesta in uscita e aggiorna la sua destinazione. La destinazione viene impostata su un endpoint associato al servizio on-prem (in questo caso, 10.2.0.1). La richiesta si sposta quindi su Cloud VPN o Cloud Interconnect verso la destinazione prevista.

Se devi aggiungere altri endpoint, aggiorna Traffic Director per aggiungerli al servizio. Non è necessario modificare il codice dell'applicazione.

Esegui la migrazione di un servizio on-premise esistente a Google Cloud

L'invio del traffico a un endpoint non Google Cloud ti consente di instradare il traffico ad altri ambienti. Puoi combinare questa funzionalità con la gestione avanzata del traffico per migrare i servizi tra gli ambienti.

Migrazione da una località on-premise a Google Cloud.
Migrazione da una località on-premise a Google Cloud (fai clic per ingrandire)

Il diagramma precedente estende il pattern precedente. Invece di configurare Traffic Director per l'invio di tutto il traffico al servizio on-prem, puoi configurare Traffic Director in modo che utilizzi la suddivisione del traffico in base al peso per suddividere il traffico tra due servizi.

La suddivisione del traffico ti consente di iniziare inviando lo 0% del traffico al servizio cloud e il 100% al servizio on-prem. Puoi quindi aumentare gradualmente la percentuale di traffico inviata al servizio cloud. Alla fine, invierai il 100% del traffico al servizio cloud e potrai ritirare il servizio on-prem.

Servizi perimetrali della rete Google Cloud per deployment on-premise e multi-cloud

Infine, puoi combinare questa funzionalità con le soluzioni di rete esistenti di Google Cloud. Google Cloud offre una vasta gamma di servizi di rete, come il bilanciamento del carico esterno globale con Google Cloud Armor per la protezione da denial of service (DDoS) distribuito, che puoi utilizzare con Traffic Director per aggiungere nuove funzionalità ai tuoi servizi on-premise o multi-cloud. Soprattutto, non è necessario esporre questi servizi on-premise o multi-cloud alla rete internet pubblica.

Deployment che coprono più ambienti.
Deployment che coprono più ambienti (fai clic per ingrandire)

Nel diagramma precedente, il traffico dai client sulla rete internet pubblica entra nella rete di Google Cloud da un bilanciatore del carico Google Cloud, come il nostro Application Load Balancer esterno globale. Quando il traffico raggiunge il bilanciatore del carico, puoi applicare servizi perimetrali di rete come la protezione DDoS di Google Cloud Armor o l'autenticazione utente di Identity-Aware Proxy (IAP). Per ulteriori informazioni, consulta Servizi perimetrali di rete per deployment multi-ambiente.

Dopo aver applicato questi servizi, il traffico si interrompe in Google Cloud, dove un'applicazione o un proxy autonomo (configurato da Traffic Director) inoltra il traffico attraverso Cloud VPN o Cloud Interconnect al tuo servizio on-premise.

Risorse e architettura di Google Cloud

Questa sezione fornisce informazioni di base sulle risorse Google Cloud che puoi utilizzare per fornire un mesh di servizi gestito da Traffic Director per ambienti on-premise e multi-cloud.

Il seguente diagramma illustra le risorse Google Cloud che consentono il supporto di servizi on-premise e multi-cloud per Traffic Director. La risorsa chiave è il NEG e i relativi endpoint di rete. Le altre risorse sono quelle configurate come parte di una configurazione standard di Traffic Director. Per semplicità, il diagramma non mostra opzioni come più servizi di backend globali.

Risorse di Compute Engine per servizi on-premise e multi-cloud.
Risorse Compute Engine per servizi on-premise e multi-cloud (fai clic per ingrandire)

Quando configuri Traffic Director, utilizzi la risorsa API globale dei servizi di backend per creare i servizi. Un servizio è un costrutto logico che combina quanto segue:

  1. Criteri da applicare quando un client tenta di inviare traffico al servizio.
  2. Uno o più backend o endpoint che gestiscono il traffico destinato al servizio.

I servizi on-premise e multi-cloud sono come qualsiasi altro servizio configurato da Traffic Director. La differenza principale è che si utilizza un NEG di connettività ibrida per configurare gli endpoint di questi servizi. Per questi NEG, il tipo di endpoint di rete è impostato su NON_GCP_PRIVATE_IP_PORT. Gli endpoint che aggiungi ai NEG di connettività ibrida devono essere combinazioni IP:port valide che i client possono raggiungere, ad esempio tramite connettività ibrida come Cloud VPN o Cloud Interconnect.

Ogni NEG ha un tipo di endpoint di rete e può contenere solo endpoint di rete dello stesso tipo. Questo tipo determina quanto segue:

  • La destinazione a cui i tuoi servizi possono inviare traffico.
  • Comportamento del controllo di integrità.

Quando crei il NEG, configuralo come segue in modo da poter inviare il traffico a una destinazione on-premise o multi-cloud.

  • Imposta il tipo di endpoint di rete su NON_GCP_PRIVATE_IP_PORT. che rappresenta un indirizzo IP raggiungibile. Se questo indirizzo IP è on-premise o presso un altro cloud provider, deve essere raggiungibile da Google Cloud utilizzando la connettività ibrida, come quella fornita da Cloud VPN o Cloud Interconnect.
  • Specifica una zona Google Cloud che riduce al minimo la distanza geografica tra Google Cloud e il tuo ambiente on-premise o multi-cloud. Ad esempio, se ospiti un servizio in un ambiente on-premise a Francoforte, in Germania, puoi specificare la zona Google Cloud europe-west3-a quando crei il NEG.

Il comportamento del controllo di integrità per gli endpoint di rete di questo tipo è diverso da quello di altri tipi di endpoint di rete. Mentre altri tipi di endpoint di rete utilizzano il sistema di controllo di integrità centralizzato di Google Cloud, gli endpoint di rete NON_GCP_PRIVATE_IP_PORT utilizzano il meccanismo di controllo di integrità distribuito di Envoy. Per maggiori dettagli, consulta la sezione Limitazioni e altre considerazioni.

Considerazioni sulla connettività e sul networking

I tuoi client Traffic Director, ad esempio i proxy Envoy, devono essere in grado di connettersi a Traffic Director all'indirizzo trafficdirector.googleapis.com:443. Se perdi la connettività al piano di controllo Traffic Director, si verifica quanto segue:

  • I client Traffic Director esistenti non possono ricevere aggiornamenti della configurazione da Traffic Director. Continuano a operare in base alla configurazione attuale.
  • I nuovi client Traffic Director non possono connettersi a Traffic Director. Non possono utilizzare il mesh di servizi fino a quando la connettività non viene ristabilita.

Se vuoi inviare traffico tra Google Cloud e ambienti on-premise o multi-cloud, gli ambienti devono essere connessi tramite connettività ibrida. Consigliamo una connessione ad alta disponibilità abilitata da Cloud VPN o Cloud Interconnect.

Gli indirizzi IP e gli intervalli di indirizzi IP di subnet on-premise, di altri cloud e Google Cloud non devono sovrapporsi.

Limitazioni e altre considerazioni

Di seguito sono riportate le limitazioni relative all'utilizzo dei NEG di connettività ibrida.

Configurazione di proxyBind

Puoi impostare il valore di proxyBind solo quando crei un targetHttpProxy. Non puoi aggiornare un targetHttpProxy esistente.

Connettività e interruzione della connettività

Per maggiori dettagli sui requisiti e sulle limitazioni di connettività, consulta la sezione Considerazioni sulla connettività e sul networking.

Tipi di backend misti

Un servizio di backend può avere backend VM o NEG. Se un servizio di backend ha backend NEG, tutti i NEG devono contenere lo stesso tipo di endpoint di rete. Non puoi avere un servizio di backend con più NEG, ciascuno con tipi di endpoint diversi.

Una mappa URL può avere regole host che si risolvono in servizi di backend diversi. Potresti avere un servizio di backend con solo NEG di connettività ibrida (con endpoint on-premise) e un servizio di backend con NEG autonomi (con endpoint GKE). La mappa URL può contenere regole, ad esempio la suddivisione del traffico in base ai pesi, che suddividono il traffico tra ciascuno di questi servizi di backend.

Utilizzo di un NEG con endpoint di tipo NON_GCP_PRIVATE_IP_PORT con i backend Google Cloud

È possibile creare un servizio di backend con un NEG di connettività ibrida che punta ai backend in Google Cloud. Tuttavia, sconsigliamo di utilizzare questo pattern perché i NEG di connettività ibrida non traggono vantaggio dal controllo di integrità centralizzato. Per una spiegazione del controllo di integrità centralizzato e del controllo di integrità distribuito, consulta la sezione Controllo di integrità.

Registrazione degli endpoint

Se vuoi aggiungere un endpoint a un NEG, devi aggiornare il NEG. Questa operazione può essere eseguita manualmente o automatizzata utilizzando le API REST di Google Cloud NEG o Google Cloud CLI.

Quando viene avviata una nuova istanza di un servizio, puoi utilizzare le API Google Cloud per registrare l'istanza con il NEG configurato. Quando si utilizzano gruppi di istanze gestite di Compute Engine (MIG) o GKE (in Google Cloud), il controller MIG o NEG gestisce automaticamente rispettivamente la registrazione degli endpoint.

Controllo di integrità

Quando utilizzi NEG di connettività ibrida, il comportamento del controllo di integrità differisce dal comportamento di controllo di integrità centralizzato standard nei seguenti modi:

  • Per gli endpoint di rete di tipo NON_GCP_PRIVATE_IP_PORT, Traffic Director configura i client per l'utilizzo del piano dati per la gestione del controllo di integrità. Per evitare di inviare richieste a backend in stato non integro, le istanze di Envoy effettueranno controlli di integrità propri e usano i propri meccanismi.
  • Poiché il tuo piano dati gestisce i controlli di integrità, non puoi utilizzare la console Google Cloud, l'API o Google Cloud CLI per recuperare lo stato dei controlli di integrità.

In pratica, l'uso di NON_GCP_PRIVATE_IP_PORT significa quanto segue:

  • Poiché i client Traffic Director gestiscono ognuno il controllo di integrità in modo distribuito, potresti notare un aumento del traffico di rete a causa del controllo di integrità. L'aumento dipende dal numero di client Traffic Director e dal numero di endpoint necessari a ciascun client per il controllo di integrità. Ad esempio:
    • Quando aggiungi un altro endpoint a un NEG di connettività ibrida, i client Traffic Director esistenti potrebbero iniziare a eseguire il controllo di integrità degli endpoint nei NEG di connettività ibrida.
    • Quando aggiungi un'altra istanza al tuo mesh di servizi (ad esempio, un'istanza VM che esegue il codice dell'applicazione e un client Traffic Director), la nuova istanza potrebbe iniziare a eseguire il controllo di integrità degli endpoint nei NEG di connettività ibrida.
    • Il traffico di rete a causa dei controlli di integrità aumenta con una frequenza quadratica (O(n^2)).

Rete VPC

Un mesh di servizi è identificato in modo univoco dal nome di rete Virtual Private Cloud (VPC). I client Traffic Director ricevono la configurazione da Traffic Director in base alla rete VPC specificata nella configurazione del bootstrap. Di conseguenza, anche se la rete mesh si trova completamente all'esterno di un data center Google Cloud, devi fornire un nome di rete VPC valido nella configurazione di bootstrap.

Account di servizio

All'interno di Google Cloud, il bootstrap predefinito di Envoy è configurato in modo da leggere i dati degli account di servizio da uno o entrambi gli ambienti di deployment di Compute Engine e GKE. Quando viene eseguito al di fuori di Google Cloud, devi specificare esplicitamente un account di servizio, il nome della rete e il numero di progetto nel bootstrap di Envoy. Questo account di servizio deve avere autorizzazioni sufficienti per connettersi all'API Traffic Director.

Passaggi successivi