Traffico in entrata per il tuo mesh
Un mesh di servizi facilita le comunicazioni tra i servizi in esecuzione nel mesh. In che modo conduci il traffico nel tuo mesh? Puoi utilizzare un gateway per indirizzare il traffico dall'esterno del mesh al tuo mesh attraverso un punto di ingresso.
Questo documento descrive come utilizzare Cloud Load Balancing come gateway per ricevere il traffico nel tuo mesh e include quanto segue:
- Considerazioni di alto livello per il gateway.
- Una panoramica delle opzioni quando selezioni un gateway per il tuo mesh.
- Suggerimenti sull'architettura che puoi applicare alla topologia dei gateway.
Questo documento riguarda le API di routing del servizio Traffic Director. Dopo aver completato i passaggi preparatori per la configurazione, consulta Configurazione di Traffic Director per un gateway in entrata, contenente le istruzioni per il deployment con un gateway in entrata.
Quando progetti il tuo mesh di servizi, considera il traffico proveniente dalle seguenti origini:
- Traffico che ha origine all'interno del tuo mesh
- Traffico che ha origine al di fuori del tuo mesh
Il traffico che ha origine all'interno del tuo mesh viaggia sul piano dati del mesh di servizi per raggiungere un backend o un endpoint associato al servizio di destinazione. Tuttavia, il traffico che ha origine al di fuori del tuo mesh deve prima raggiungere il piano dati del mesh di servizi.
Nel seguente esempio di traffico che ha origine all'interno del tuo mesh, Traffic Director configura i proxy del file collaterale. Questi proxy collaterali formano il piano dati del tuo mesh di servizi. Se il Servizio A vuole comunicare con il Servizio B, si verifica quanto segue:
- Il servizio A invia una richiesta al servizio B per nome.
- Questa richiesta viene intercettata e reindirizzata al proxy sidecar del servizio A.
- Il proxy sidecar invia quindi la richiesta a un endpoint associato al servizio B.
Nell'esempio seguente, il traffico ha origine al di fuori del tuo mesh di servizi e non viaggia lungo il piano dati del mesh di servizi.
In questo esempio, il client è esterno al tuo mesh di servizi. Poiché non partecipa direttamente al mesh, il client non sa quali endpoint appartengono ai servizi all'interno del mesh. In altre parole, poiché il client non utilizza un proxy configurato da Traffic Director per inviare le richieste in uscita, non sa quali coppie indirizzo IP-porta utilizzare per inviare il traffico al servizio A o al servizio B. Senza queste informazioni, il client non può raggiungere i servizi all'interno del tuo mesh.
Considerazioni sul gateway
Questa sezione fornisce una panoramica dei problemi da considerare quando selezioni un gateway, tra cui:
- In che modo i clienti possono raggiungere il mio gateway?
- Quali criteri devo applicare al traffico che raggiunge il gateway?
- In che modo il gateway distribuisce il traffico ai servizi nel mio mesh?
Consenti ai client di raggiungere il punto di accesso al tuo mesh
I client, che si trovino sulla rete internet pubblica, nel tuo ambiente on-premise o all'interno di Google Cloud, hanno bisogno di un modo per raggiungere un servizio all'interno del tuo mesh. Il raggiungimento di un servizio nella tua rete mesh si ottiene in genere utilizzando un indirizzo IP e una porta instradabili pubblicamente o privata che si risolvono in un gateway. I client esterni alla rete mesh utilizzano l'indirizzo IP e la porta per inviare richieste ai servizi nel tuo mesh attraverso il gateway.
Cloud Load Balancing offre varie opzioni di bilanciamento del carico che puoi utilizzare come gateway al tuo mesh. Le principali domande da porsi quando scegli un bilanciatore del carico Google Cloud che funga da gateway sono le seguenti:
- I miei client si trovano sulla rete internet pubblica, in un ambiente on-premise o nella mia rete Virtual Private Cloud (VPC)?
- Quali protocolli di comunicazione utilizzano i miei clienti?
Per una panoramica delle opzioni di Cloud Load Balancing, a seconda della posizione del client e del protocollo di comunicazione, consulta la sezione Scegliere un gateway per il mesh.
Gestire il traffico nel gateway
Poiché il gateway si trova sul perimetro del mesh, tra i client esterni al mesh e i servizi interni al mesh, è un luogo naturale in cui applicare i criteri quando il traffico entra nel mesh. Queste norme includono:
- Gestione del traffico, ad esempio routing, reindirizzamenti e trasformazione delle richieste
- Sicurezza, ad esempio terminazione TLS e protezione DDoS (Distributed Denial-of-Service) di Google Cloud Armor
- Memorizzazione nella cache di Cloud CDN
La sezione Scegli un gateway per il tuo mesh evidenzia i criteri pertinenti ai margini del mesh.
Invia il traffico dal gateway a un servizio nel tuo mesh
Dopo che il gateway ha applicato i criteri al traffico in entrata, decide dove inviarlo. Per configurarlo, devi utilizzare i criteri di gestione del traffico e di bilanciamento del carico. Il gateway potrebbe, ad esempio, esaminare l'intestazione della richiesta per identificare il servizio mesh che deve ricevere il traffico. Dopo che il gateway identifica il servizio, distribuisce il traffico a un backend specifico in base a un criterio di bilanciamento del carico.
La sezione Scegli un gateway per il tuo mesh descrive i backend a cui un gateway può inviare traffico.
Scegli un gateway per il tuo mesh
Google Cloud offre un'ampia gamma di bilanciatori del carico che possono fungere da gateway per il tuo mesh. Questa sezione illustra la selezione di un gateway, confrontando le seguenti opzioni insieme alle dimensioni pertinenti al pattern del gateway:
- Bilanciatore del carico delle applicazioni interno
- Bilanciatore del carico delle applicazioni esterno
- Bilanciatore del carico di rete passthrough interno
- Bilanciatore del carico di rete passthrough esterno
- Bilanciatore del carico di rete proxy esterno
In questa sezione, facciamo riferimento ai gateway di first-level e di first-level. Questi termini vengono utilizzati per descrivere l'utilizzo di uno o due gateway per gestire il traffico in entrata verso il tuo mesh.
Potresti aver bisogno di un solo livello, ovvero un singolo bilanciatore del carico che funge da gateway per il mesh. A volte, però, ha senso avere più gateway. In queste configurazioni, un gateway gestisce il traffico in entrata in Google Cloud e un gateway di secondo livello separato gestisce il traffico quando entra nel mesh di servizi.
Ad esempio, potresti applicare i criteri di sicurezza di Google Cloud Armor al traffico in ingresso a Google Cloud e i criteri di gestione avanzata del traffico al traffico che entra nel mesh. Il pattern per l'utilizzo di un secondo gateway configurato da Traffic Director è discusso nella sezione Gestire il traffico in entrata utilizzando un gateway di secondo livello sul perimetro del mesh.
La tabella seguente mette a confronto le funzionalità disponibili, a seconda dell'opzione di gateway selezionata.
| Gateway | Posizione client | Protocolli | Criteri | Backend/endpoint |
|---|---|---|---|---|
| Bilanciatore del carico delle applicazioni interno | Client basati su Google Cloud nella stessa regione del bilanciatore del carico. Client on-premise le cui richieste arrivano nella stessa regione Google Cloud del bilanciatore del carico, ad esempio utilizzando Cloud VPN o Cloud Interconnect. |
HTTP/1.1 HTTP/2 HTTPS |
Gestione avanzata del traffico Terminazione TLS tramite certificati autogestiti |
Backend nella stessa regione Google Cloud del bilanciatore del carico, in esecuzione su:
|
| Bilanciatore del carico delle applicazioni esterno | Client sulla rete internet pubblica | HTTP/1.1 HTTP/2 HTTPS |
Gestione del traffico Cloud CDN (inclusi i backend dei bucket Cloud Storage) Terminazione TLS tramite certificati autogestiti o Google Criteri SSL Google Cloud Armor per la prevenzione degli attacchi web e DDoS Supporto di Identity-Aware Proxy (IAP) per l'autenticazione degli utenti |
Backend in qualsiasi regione Google Cloud in esecuzione su:
|
| Bilanciatore del carico di rete passthrough interno | Client basati su Google Cloud in qualsiasi regione. Ciò richiede l'accesso globale se i client si trovano in una regione diversa dal bilanciatore del carico. Client on-premise le cui richieste arrivano in qualsiasi regione Google Cloud, ad esempio utilizzando Cloud VPN o Cloud Interconnect. |
TCP | Backend nella stessa regione Google Cloud del bilanciatore del carico, in esecuzione su VM in Compute Engine. | |
| Bilanciatore del carico di rete passthrough esterno | Client sulla rete internet pubblica | TCP o UDP | Backend nella stessa regione Google Cloud del bilanciatore del carico, in esecuzione su VM in Compute Engine. | |
| Bilanciatore del carico di rete proxy esterno | Client sulla rete internet pubblica | SSL o TCP | Terminazione TLS tramite certificati Google o autogestiti (solo proxy SSL) Criteri SSL (solo proxy SSL) |
Backend in qualsiasi regione Google Cloud in esecuzione su:
|
| Proxy perimetrale (su istanze di VM o container) configurato da Traffic Director |
I clienti devono trovarsi in una località in cui si applica una delle seguenti condizioni:
|
HTTP/1.1 HTTP/2 |
Gestione avanzata del traffico (inclusa l'assistenza regex) |
Backend in qualsiasi regione Google Cloud in esecuzione su:
|
Per un confronto dettagliato tra le singole funzionalità, consulta la pagina Funzionalità del bilanciatore del carico. Per una panoramica dettagliata delle funzionalità di Traffic Director, consulta la pagina delle funzionalità di Traffic Director.
Deployment e configurazione dei gateway
Un'ultima considerazione per la scelta del gateway sono l'esperienza degli sviluppatori e gli strumenti che vuoi utilizzare. Google Cloud offre diversi approcci per la creazione e la gestione del gateway.
API Google Cloud CLI e Compute Engine
Per configurare i prodotti gestiti di bilanciamento del carico di Google Cloud e Traffic Director, puoi utilizzare Google Cloud CLI e le API Compute Engine. gcloud CLI e le API forniscono meccanismi per eseguire il deployment e configurare le risorse Google Cloud in modo imperativo. Per automatizzare le attività ripetitive, puoi creare script.
Console Google Cloud
Per configurare Traffic Director e i bilanciatori del carico gestiti di Google Cloud, puoi utilizzare la console Google Cloud.
Per configurare il pattern del gateway, è probabile che siano necessarie sia la pagina Traffic Director che la pagina Bilanciamento del carico.
Ingress GKE e multi-cluster
I controller di rete GKE e GKE Enterprise supportano anche il deployment di Cloud Load Balancing per l'integrazione integrata con il networking di container. Forniscono un'interfaccia dichiarativa in stile Kubernetes per il deployment e la configurazione dei gateway. I controller GKE Ingress e Ingress multi-cluster gestiscono i bilanciatori del carico interni ed esterni per l'invio del traffico a un singolo cluster o tra più cluster GKE. La risorsa Ingress può anche essere configurata in modo che punti ai servizi configurati da Traffic Director di cui è stato eseguito il deployment nei cluster GKE.
Pattern di architettura del gateway
Questa sezione descrive i pattern di alto livello e fornisce diagrammi dell'architettura per il tuo gateway.
Il pattern più comune prevede l'utilizzo di un bilanciatore del carico gestito da Google Cloud come gateway:
I client inviano il traffico a un bilanciatore del carico gestito da Google Cloud che funge da gateway.
- Il gateway applica i criteri.
Il gateway invia il traffico a un servizio nel tuo mesh.
Un pattern più avanzato coinvolge i gateway a due livelli. I gateway funzionano nel seguente modo:
I client inviano il traffico a un bilanciatore del carico gestito da Google Cloud che funge da gateway di primo livello.
- Il gateway applica i criteri.
Il gateway invia il traffico a un proxy perimetrale (o a un pool di proxy perimetrali) configurato da Traffic Director. Questo proxy perimetrale agisce come gateway di secondo livello. Questo livello svolge le seguenti operazioni:
Fornisce una chiara separazione dei problemi in cui, ad esempio, un team è responsabile del traffico in entrata in entrata in Google Cloud e un altro team è responsabile del traffico in entrata nel mesh di quel team.
Consente di applicare criteri che potrebbero non essere supportati nel bilanciatore del carico gestito da Google Cloud.
Il gateway di secondo livello invia il traffico a un servizio nel tuo mesh.
Il pattern in entrata termina dopo che il traffico raggiunge un servizio in-mesh. Nelle sezioni seguenti sono descritti sia il caso comune che i pattern avanzati.
Attiva il traffico in entrata da internet
Se i tuoi client sono esterni a Google Cloud e devono raggiungere Google Cloud tramite la rete internet pubblica, puoi utilizzare uno dei seguenti bilanciatori del carico come gateway:
- Bilanciatore del carico delle applicazioni esterno
- Bilanciatore del carico di rete passthrough esterno
- Bilanciatore del carico di rete proxy esterno
In questo pattern, il bilanciatore del carico gestito da Google Cloud funge da gateway. Il gateway gestisce il traffico in entrata prima di inoltrarlo a un servizio nel tuo mesh.
Ad esempio, potresti scegliere un bilanciatore del carico delle applicazioni esterno come gateway per utilizzare quanto segue:
- Un indirizzo IP Anycast globale instradabile pubblicamente, che riduce al minimo la latenza e i costi di attraversamento rete.
- Google Cloud Armor e terminazione TLS per proteggere il traffico verso il tuo mesh.
- Cloud CDN per pubblicare contenuti web e video.
- Funzionalità di gestione del traffico come il routing basato su host e su percorso.
Per ulteriori informazioni su come scegliere un gateway appropriato, consulta la sezione Scegliere un gateway per il mesh.
Abilita il traffico in entrata dai client in VPC e nelle reti on-premise connesse
Se i client si trovano all'interno della tua rete VPC o sono on-premise e possono raggiungere i servizi Google Cloud utilizzando un metodo di connettività privata (come Cloud VPN o Cloud Interconnect), puoi utilizzare uno dei seguenti bilanciatori del carico come gateway:
- Bilanciatore del carico delle applicazioni interno
- Bilanciatore del carico di rete passthrough interno
In questo pattern, il bilanciatore del carico gestito da Google Cloud funge da gateway. Il gateway gestisce il traffico in entrata prima di inoltrarlo a un servizio nel tuo mesh.
Ad esempio, potresti scegliere un bilanciatore del carico delle applicazioni interno come gateway, in modo da poter utilizzare le seguenti funzionalità:
- Un indirizzo IP indirizzabile privatamente
- Terminazione TLS per proteggere il tuo mesh
- Funzionalità avanzate di gestione del traffico, come la suddivisione del traffico in base al peso
- NEG come backend
Per ulteriori informazioni su come scegliere un gateway appropriato, consulta la sezione Scegliere un gateway per il mesh.
Gestisci il traffico in entrata utilizzando un gateway di secondo livello sul perimetro del mesh
A seconda delle tue esigenze, puoi prendere in considerazione un pattern più avanzato che aggiunge un gateway aggiuntivo.
Questo gateway è un proxy perimetrale configurato da Traffic Director (o pool di proxy) che si trova dietro il bilanciatore del carico gestito da Google Cloud. Puoi ospitare questo gateway di secondo livello nel tuo progetto utilizzando un pool di VM di Compute Engine (un gruppo di istanze gestite) o servizi GKE.
Sebbene questo pattern sia più avanzato, offre ulteriori vantaggi:
Il bilanciatore del carico gestito da Google Cloud applica un insieme iniziale di criteri, ad esempio la protezione di Google Cloud Armor se utilizzi un bilanciatore del carico delle applicazioni esterno.
Il proxy perimetrale configurato da Traffic Director applica un secondo insieme di criteri che potrebbero non essere disponibili nel bilanciatore del carico gestito da Google Cloud. Questi criteri includono la gestione avanzata del traffico che utilizza espressioni regolari applicate alle intestazioni HTTP e alla suddivisione del traffico in base al peso.
Questo modello può essere configurato in modo da riflettere la struttura organizzativa. Ad esempio:
Un team potrebbe essere responsabile della gestione del traffico in entrata verso Google Cloud, mentre un altro potrebbe essere responsabile della gestione del traffico in entrata verso il proprio mesh.
Se più team offrono servizi su un VPC condiviso e ogni team possiede il proprio progetto di servizio, i team possono utilizzare questo pattern per gestire e applicare criteri nei propri mesh. Ogni team può esporre un gateway configurato da Traffic Director raggiungibile su un singolo indirizzo IP e coppia di porte. Un team può quindi definire e gestire in modo indipendente i criteri applicati al traffico in entrata nel mesh del team.
Questo pattern può essere implementato utilizzando qualsiasi bilanciatore del carico gestito da Google Cloud, a condizione che possa inviare traffico ai backend che ospitano i gateway configurati da Traffic Director.
Utilizza le API di routing dei servizi per il traffico in entrata
Le API di routing dei servizi forniscono la risorsa Gateway per la configurazione della gestione del traffico e della sicurezza per i proxy Envoy che fungono da gateway in entrata, consentendo ai client esterni di connettersi al mesh di servizi (nord-sud).
Per saperne di più, leggi la panoramica del routing dei servizi e Configurare un gateway in entrata.
Passaggi successivi
- Per raggruppare le VM e i container che eseguono il codice come endpoint dei tuoi servizi, consulta Rilevamento dei servizi Traffic Director.
- Per utilizzare Traffic Director con un VPC condiviso, consulta Configurare un mesh di servizi multi-cluster.
- Per scoprire di più su Traffic Director, consulta la panoramica di Traffic Director.