Traffico in entrata per la tua rete mesh
Un mesh di servizi facilita le comunicazioni tra i servizi in esecuzione mesh. Come fai a indirizzare il traffico nella tua rete 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 ottenere il traffico verso il tuo mesh e include quanto segue:
- Considerazioni generali per il tuo gateway.
- Una panoramica delle opzioni disponibili quando selezioni un gateway per la tua rete mesh.
- Suggerimenti dell'architettura che puoi applicare alla topologia gateway.
In questo documento, il gateway si riferisce a una soluzione o a un modello per la gestione traffico destinato a un servizio nel tuo mesh. Il gateway in entrata di Istio è un'implementazione di questo pattern. In questo documento, gateway è un nome generico termine che si riferisce al pattern generale, non all'implementazione di Istio.
Questo documento si applica alle API Cloud Service Mesh. Dopo i passaggi di configurazione preliminari, consulta la pagina che contiene le istruzioni per il deployment con un gateway di ingresso.
Quando progetti il tuo service mesh, tieni conto del traffico proveniente dalle seguenti fonti:
- Traffico che ha origine all'interno del mesh
- Traffico che ha origine al di fuori della tua rete 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 proveniente dall'esterno del tuo mesh deve prima raggiungere il piano dati del servizio mesh.
Nell'esempio seguente di traffico che ha origine all'interno del tuo mesh: Cloud Service Mesh configura i proxy sidecar. Questi proxy collaterali formano al piano dati del tuo mesh di servizi. Se il servizio A vuole comunicare con Nel 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 passa attraverso il piano dati del mesh di servizi.
In questo esempio, il client si trova al di fuori del tuo service mesh. Poiché non partecipino direttamente al mesh, il client non sa a quali endpoint appartengono ai servizi all'interno del mesh. In altre parole, poiché il client non utilizza un proxy configurato in Cloud Service Mesh per inviare richieste in uscita, non sa quali coppie di porta e indirizzo IP utilizzare per inviare traffico al servizio A o al servizio B. Senza queste informazioni, il cliente non può raggiungere i servizi al suo interno della tua rete mesh.
Considerazioni relative al 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 voglio applicare al traffico che raggiunge il mio gateway?
- In che modo il gateway distribuisce il traffico ai servizi nel mio mesh?
Consenti ai client di raggiungere il gateway della tua mesh
I client, che si trovino su internet pubblico, nel tuo ambiente on-premise o in Google Cloud, hanno bisogno di un modo per raggiungere un servizio all'interno del tuo mesh. Raggiungimento un servizio nel mesh si ottiene in genere utilizzando un servizio un indirizzo IP e una porta instradabili che si risolvono in un gateway. Clienti esterni al tuo la rete mesh utilizza questo indirizzo IP e questa 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 per il tuo mesh. Le domande principali da porre quando scegli un Il bilanciatore del carico di Google Cloud che funga da gateway sono i seguenti:
- I miei clienti si trovano sulla rete internet pubblica, in un ambiente on-premise o fanno parte della 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 del client posizione e protocollo di comunicazione, consulta le Sezione Scegli un gateway per la tua rete mesh.
Gestire il traffico al gateway
Poiché il gateway si trova sul perimetro del mesh, tra i client che sono all'esterno della rete mesh e i servizi al loro interno, ovvero il gateway è la posizione naturale in cui applicare i criteri quando il traffico entra nel mesh. Questi criteri includono:
- Gestione del traffico, ad esempio routing, reindirizzamenti e richieste trasformazione
- 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 la tua mesh mette in evidenza le norme pertinenti all'esterno della mesh.
Invia traffico dal gateway a un servizio nel tuo mesh
Dopo che il gateway ha applicato i criteri al traffico in entrata, decide a dove inviare il traffico. Utilizzi la gestione del traffico e il bilanciamento del carico criteri per configurarla. Ad esempio, il gateway potrebbe ispezionare la richiesta per identificare il servizio mesh che deve ricevere il traffico. Dopo il 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 mesh illustra le backend a cui un gateway può inviare traffico.
Scegli un gateway per la tua rete mesh
Google Cloud offre una vasta 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 primo livello e di secondo livello. Questi vengono usati per descrivere l'uso di uno o due gateway per gestire del traffico in entrata verso la tua rete mesh.
Potresti aver bisogno di un solo livello, un singolo bilanciatore del carico che funge da gateway per la 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 nella rete mesh di servizi.
Ad esempio, potresti voler applicare i criteri di sicurezza di Google Cloud Armor al traffico in entrata in Google Cloud e i criteri di gestione avanzata del traffico al traffico in entrata nel mesh. Lo schema di utilizzo di un secondo Nella sezione viene illustrato il gateway configurato da Cloud Service Mesh Gestisci il traffico in entrata utilizzando un gateway di secondo livello sul perimetro della rete 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 con certificati autogestiti |
I backend nella stessa regione Google Cloud del bilanciatore del carico, in esecuzione su:
|
| Application Load Balancer 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 utilizzando certificati autogestiti o da Google Criteri SSL Google Cloud Armor per la prevenzione di attacchi DDoS e web 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. Per questo è necessario l'accesso globale se i client si trovano in una regione diversa da quella del bilanciatore del carico. Client on-premise le cui richieste arrivano in qualsiasi regione Google Cloud, ad esempio utilizzando Cloud VPN o Cloud Interconnect. |
TCP | I backend nella stessa regione Google Cloud del bilanciatore del carico, in esecuzione su VM su Compute Engine. | |
| Bilanciatore del carico di rete passthrough esterno | Client sulla rete internet pubblica | TCP o UDP | Back-end nella stessa regione Google Cloud del bilanciatore del carico, in esecuzione su VM su Compute Engine. | |
| Bilanciatore del carico di rete proxy esterno | Client sulla rete internet pubblica | SSL o TCP | Terminazione TLS utilizzando certificati gestiti da Google o autogestiti (proxy SSL ) Criteri SSL (solo proxy SSL) |
Backend in qualsiasi regione Google Cloud, in esecuzione su:
|
| Proxy perimetrale (su istanze VM o container) configurato da Cloud Service Mesh |
I clienti devono trovarsi in una località in cui si applica una delle seguenti condizioni:
|
HTTP/1.1 HTTP/2 |
Gestione avanzata del traffico (incluso il supporto di regex) |
Backend in qualsiasi regione Google Cloud, in esecuzione su:
|
Per un confronto dettagliato tra funzione, vedi pagina Funzionalità del bilanciatore del carico. Per una panoramica delle funzionalità di Cloud Service Mesh, consulta Funzionalità di Cloud Service Mesh.
Esegui il deployment e la configurazione dei gateway
Un'ultima considerazione da fare nella scelta del gateway è l'esperienza dello sviluppatore e gli strumenti che vuoi utilizzare. Google Cloud offre più approcci per creare e gestire il gateway.
Google Cloud CLI e API Compute Engine
Per configurare i prodotti di bilanciamento del carico gestiti di Google Cloud e Cloud Service Mesh, puoi utilizzare le API Google Cloud CLI e 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
Configurazione di Cloud Service Mesh e del carico gestito di Google Cloud puoi usare la console Google Cloud.
Per configurare il pattern di gateway, è probabile che tu debba consultare sia la pagina Cloud Service Mesh sia la pagina Bilanciamento del carico.
GKE e Ingress multi-cluster
Anche i controller di rete GKE e GKE Enterprise supportano il deployment di Cloud Load Balancing per l'integrazione integrata il networking dei 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 e esterni per l'invio di traffico a un singolo cluster o a più cluster GKE. La risorsa Ingress può essere configurata anche per puntare ai servizi configurati da Cloud Service Mesh di cui viene eseguito il deployment in cluster GKE.
Pattern di architettura del gateway
Questa sezione descrive pattern di alto livello e fornisce diagrammi di 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 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 come segue:
I client inviano 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 Cloud Service Mesh. Questo proxy edge funge da gateway di secondo livello. Questo livello fa quanto segue:
Offre una chiara separazione delle responsabilità in cui, ad esempio, un team è responsabile del traffico in entrata che entra in Google Cloud, mentre un altro team è responsabile del traffico in entrata che entra nel mesh del team.
Ti 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 di ingresso termina quando il traffico raggiunge un servizio in-mesh. Sia il caso comune sia i pattern avanzati sono descritti nelle sezioni seguenti.
Abilita il traffico in entrata da internet
Se i tuoi client si trovano al di fuori di Google Cloud e devono raggiungere Google Cloud tramite internet pubblico, 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 VPN ad alta disponibilità. Il gateway gestisce il traffico in entrata prima di inoltrarlo a un servizio nella tua rete mesh.
Ad esempio, potresti scegliere un bilanciatore del carico delle applicazioni esterno come gateway per utilizza quanto segue:
- Un indirizzo IP anycast globale routabile pubblicamente, che riduce al minimo la latenza e i costi di attraversamento della 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 sull'host e sul percorso.
Per ulteriori informazioni che ti aiutino a scegliere un gateway appropriato, consulta la sezione Scegliere un gateway per la rete mesh.
Abilita il traffico in entrata dai client nella VPC e nelle reti on-premise collegate
Se i tuoi client si trovano all'interno della tua rete VPC on-premise e può raggiungere i servizi Google Cloud utilizzando una come metodo di connettività 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 nella tua rete mesh.
Ad esempio, potresti scegliere un bilanciatore del carico delle applicazioni interno come gateway in modo da poter utilizzare queste funzionalità:
- Un indirizzo IP con indirizzo privato
- Terminazione TLS per proteggere il tuo mesh
- Funzionalità di gestione avanzata del traffico, come la suddivisione del traffico in base al peso
- NEG come backend
Per ulteriori informazioni che ti aiutino a scegliere un gateway appropriato, consulta la sezione Scegliere un gateway per la rete mesh.
Gestire il traffico in entrata utilizzando un gateway di secondo livello all'esterno del mesh
A seconda delle tue esigenze, puoi prendere in considerazione un pattern più avanzato che aggiunga una gateway aggiuntivo.
Questo gateway è un proxy edge configurato con Cloud Service Mesh (o un 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 Compute Engine (un gruppo di istanze gestite) o servizi GKE.
Sebbene questo pattern sia più avanzato, offre vantaggi aggiuntivi:
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 Cloud Service Mesh applica un secondo insieme di Criteri che potrebbero non essere disponibili nel carico gestito da Google Cloud con il bilanciatore del carico di rete passthrough esterno regionale. Questi criteri includono una gestione avanzata del traffico che utilizza espressioni regolari applicate alle intestazioni HTTP e la suddivisione del traffico in base al peso.
Questo pattern può essere impostato in modo da riflettere la struttura della tua organizzazione. Ad esempio:
Un team potrebbe essere responsabile della gestione del traffico in entrata Google Cloud, mentre un altro team è responsabile della gestione del traffico in entrata traffico al suo mesh.
Se più team offrono servizi su un VPC condiviso, con ogni team che possiede il proprio progetto di servizio, i team possono utilizzare questo pattern per gestire e applicare i criteri nei propri mesh. Ogni team può esporre Gateway configurato da Cloud Service Mesh e raggiungibile su un singolo IP indirizzo IP e coppia di porte. Un team può quindi definire e gestire in modo indipendente i criteri applicati al traffico in entrata nel proprio mesh.
Questo pattern può essere implementato utilizzando qualsiasi modello purché sia in grado di inviare traffico ai backend che ospitano i gateway configurati da Cloud Service Mesh.
Utilizza le API di routing dei servizi per il traffico in entrata
Le API di routing dei servizi forniscono la risorsa Gateway per
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 ulteriori informazioni, leggi la panoramica del routing dei servizi e Configurare un gateway di ingresso.
Passaggi successivi
- Per configurare un gateway in entrata, consulta Configurazione di Cloud Service Mesh per un gateway in entrata.
- Per raggruppare le VM e i contenitori che eseguono il codice come endpoint dei servizi, consulta Discovery dei servizi Cloud Service Mesh.
- Per utilizzare Cloud Service Mesh con VPC condiviso, consulta Configurare un service mesh multi-cluster.
- Per scoprire di più su Cloud Service Mesh, consulta la panoramica di Cloud Service Mesh.