Traffico in entrata per il tuo mesh

Un mesh di servizi facilita le comunicazioni tra i servizi in esecuzione nella mesh. Come puoi inserire il traffico nella tua rete mesh? Puoi utilizzare un gateway per indirizzare il traffico dall'esterno del mesh al mesh attraverso un punto di ingresso.

Questo documento descrive come utilizzare Cloud Load Balancing come gateway per ricevere traffico nel tuo mesh e include quanto segue:

  • Considerazioni generali per il tuo gateway.
  • Una panoramica delle opzioni disponibili per la selezione di un gateway per il mesh.
  • Suggerimenti dell'architettura che puoi applicare alla topologia gateway.

In questo documento, il gateway fa riferimento a una soluzione o un pattern per la gestione del traffico destinato a un servizio nel mesh. Il gateway Ingress di Istio è un'implementazione di questo pattern. In questo documento, gateway è un termine generico che si riferisce al pattern generale, non all'implementazione di Istio.

Questo documento riguarda le API Cloud Service Mesh. Dopo la procedura di configurazione preliminare, consulta la pagina che contiene le istruzioni per il deployment con un gateway in entrata.

Quando progetti il tuo mesh di servizi, considera il traffico proveniente dalle seguenti sorgenti:

  • Traffico che ha origine all'interno della rete mesh
  • Traffico che ha origine al di fuori della tua rete mesh

Il traffico che ha origine all'interno del 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.

Nell'esempio seguente di traffico che ha origine all'interno del mesh, Cloud Service Mesh configura i proxy sidecar. Questi proxy collaterali formano il piano dati del mesh di servizi. Se il servizio A vuole comunicare con il servizio B, si verifica quanto segue:

  1. Il servizio A invia una richiesta al servizio B per nome.
  2. Questa richiesta viene intercettata e reindirizzata al proxy sidecar del servizio A.
  3. Il proxy sidecar invia quindi la richiesta a un endpoint associato al servizio B.
Il piano dati del mesh gestisce il traffico interno al mesh di servizi.
Il piano dati del mesh gestisce il traffico interno al mesh di servizi (fai clic per ingrandire)


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.

Il piano dati del mesh di servizi non gestisce il traffico esterno al mesh di servizi.
Il piano dati del mesh di servizi non gestisce il traffico esterno al mesh di servizi (fai clic per ingrandire)

In questo esempio, il client è esterno al 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 Cloud Service Mesh per inviare richieste in uscita, non sa quali coppie indirizzo-porta IP utilizzare per inviare traffico al servizio A o al servizio B. Senza queste informazioni, il client non può raggiungere i servizi all'interno del tuo 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 del tuo mesh

I client, sia 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 della tua rete mesh. Per raggiungere un servizio nel mesh, in genere si utilizza un indirizzo IP e una porta instradabili pubblicamente o privatamente che si connettono a un gateway. I client esterni alla tua rete mesh utilizzano 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 la tua rete mesh. Le domande principali da porsi quando si sceglie un bilanciatore del carico Google Cloud che funga da gateway sono:

  • I miei client sono 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, in base alla località del client e al protocollo di comunicazione, consulta la sezione Scegli un gateway per il mesh.

Gestisci il traffico al gateway

Poiché il gateway si trova sul perimetro del mesh, tra i client all'esterno del mesh e i servizi al suo interno, è il luogo naturale in cui applicare i criteri quando il traffico entra nel mesh. Queste norme includono quanto segue:

  • Gestione del traffico, ad esempio routing, reindirizzamenti e trasformazione delle richieste
  • Sicurezza, ad esempio terminazione TLS e protezione DDoS di Google Cloud Armor
  • Memorizzazione nella cache di Cloud CDN

La sezione Scegli un gateway per il tuo mesh evidenzia i criteri pertinenti sul perimetro del mesh.

Invia 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 la configurazione, puoi usare i criteri di gestione del traffico e bilanciamento del carico. Ad esempio, il gateway potrebbe esaminare l'intestazione della richiesta per identificare il servizio mesh che deve ricevere il traffico. Dopo aver identificato il servizio, il gateway distribuisce il traffico a un backend specifico in base a un criterio di bilanciamento del carico.

La sezione Scegli un gateway per il mesh delinea i backend a cui un gateway può inviare il traffico.

Scegli un gateway per la tua rete 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:

In questa sezione facciamo riferimento ai gateway di first-level e di first-level. Questi termini vengono utilizzati per descrivere l'uso di uno o due gateway per gestire il traffico in entrata verso il mesh.

Potrebbe essere necessario un solo livello, un singolo bilanciatore del carico che funga 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 nella rete mesh di servizio.

Ad esempio, potresti voler applicare i criteri di sicurezza di Google Cloud Armor al traffico che entra in Google Cloud e i criteri di gestione avanzata del traffico per il traffico che entra nel mesh. Il pattern di utilizzo di un secondo gateway configurato da Cloud Service Mesh è 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 del 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 mediante certificati autogestiti

Backend nella stessa regione Google Cloud del bilanciatore del carico, in esecuzione su:

  • Backend di istanze di macchine virtuali (VM) su Compute Engine
  • Istanze di container su Google Kubernetes Engine (GKE) e Kubernetes
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 utilizzando certificati autogestiti o da Google

Criteri SSL

Google Cloud Armor per la prevenzione degli attacchi DDoS e web

Supporto di Identity-Aware Proxy (IAP) per l'autenticazione utente

Backend in qualsiasi regione Google Cloud, in esecuzione su:

  • VM su Compute Engine
  • Istanze di container su GKE e Kubernetes
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 rispetto al 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 su 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 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 (solo proxy SSL)

Criteri SSL (solo proxy SSL)

Backend in qualsiasi regione Google Cloud, in esecuzione su:

  • VM su Compute Engine
  • Istanze di container su GKE e Kubernetes
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:
  • Può inviare una richiesta a un bilanciatore del carico gestito da Google Cloud, che quindi invia la richiesta al proxy perimetrale. Per maggiori dettagli, consulta Gestire il traffico in entrata utilizzando un gateway di secondo livello sul perimetro del mesh.
  • Può inviare una richiesta tramite un proxy, ad esempio un proxy sidecar, configurato da Cloud Service Mesh.
  • Possono inviare una richiesta direttamente all'indirizzo IP e alla porta di un'istanza VM o di container su cui è in esecuzione il proxy perimetrale.

HTTP/1.1

HTTP/2

Gestione avanzata del traffico (inclusa l'assistenza regex)

Backend in qualsiasi regione Google Cloud, in esecuzione su:

  • VM su Compute Engine
  • Istanze di container su GKE e Kubernetes

Per un confronto dettagliato tra funzionalità, consulta la pagina Funzionalità del bilanciatore del carico. Per una panoramica dettagliata delle funzionalità di Cloud Service Mesh, consulta la pagina Funzionalità di Cloud Service Mesh.

Esegui il deployment e la configurazione dei gateway

Un'ultima considerazione nella scelta del gateway è l'esperienza e gli strumenti che gli sviluppatori vogliono utilizzare. Google Cloud offre diversi approcci per la creazione e la gestione del gateway.

API di Google Cloud CLI e Compute Engine

Per configurare i prodotti per il bilanciamento del carico gestito di Google Cloud e Cloud Service Mesh, 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 Cloud Service Mesh e i bilanciatori del carico gestiti di Google Cloud, puoi utilizzare la console Google Cloud.

Per configurare il pattern gateway, probabilmente hai bisogno sia della pagina Cloud Service Mesh che della pagina Bilanciamento del carico.

GKE e Ingress multi-cluster

I controller di rete GKE e GKE Enterprise supportano anche il deployment di Cloud Load Balancing per l'integrazione incorporata 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ò essere configurata anche in modo da puntare ai servizi configurati da Cloud Service Mesh di cui viene eseguito il deployment nei cluster GKE.

Pattern di architettura del gateway

Questa sezione descrive i pattern di alto livello e fornisce diagrammi di architettura per il gateway.

Il pattern più comune prevede l'utilizzo di un bilanciatore del carico gestito da Google Cloud come gateway:

  1. I client inviano il traffico a un bilanciatore del carico gestito da Google Cloud che agirà come gateway.

    • Il gateway applica i criteri.
  2. 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:

  1. 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.
  2. Il gateway invia il traffico a un proxy perimetrale (o un pool di proxy perimetrali) configurato da Cloud Service Mesh. Questo proxy perimetrale agisce come gateway di secondo livello. Questo livello fa quanto segue:

    • Fornisce una chiara separazione dei problemi 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.

    • Consente di applicare criteri che potrebbero non essere supportati nel bilanciatore del carico gestito da Google Cloud.

  3. 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 che seguono vengono descritti sia il caso comune sia i pattern avanzati.

Abilita il traffico in entrata da internet

Se i tuoi client si trovano al di fuori di Google Cloud e devono connettersi a Google Cloud tramite la rete internet pubblica, puoi utilizzare uno dei seguenti bilanciatori del carico come gateway:

Traffico in entrata dai client sulla rete internet pubblica ai servizi in-mesh utilizzando un bilanciatore del carico.
Traffico in entrata dai client sulla rete internet pubblica ai servizi in-mesh utilizzando un bilanciatore del carico (fai clic per ingrandire)

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, puoi 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 della rete.
  • Google Cloud Armor e terminazione TLS per proteggere il traffico verso la tua rete mesh.
  • Cloud CDN per la pubblicazione di contenuti web e video.
  • Funzionalità di gestione del traffico come il routing basato su host e basato su percorso.

Per ulteriori informazioni che ti aiutino a scegliere un gateway appropriato, consulta la sezione Scegliere un gateway per il mesh.

Abilita il traffico in entrata dai client nel VPC e dalle reti on-premise connesse

Se i tuoi client si trovano all'interno della tua rete VPC o se sono on-premise e possono raggiungere i servizi Google Cloud utilizzando un metodo di connettività privata (ad esempio Cloud VPN o Cloud Interconnect), puoi utilizzare uno dei seguenti bilanciatori del carico come gateway:

Traffico in entrata dai client su una rete VPC ai servizi in-mesh utilizzando un bilanciatore del carico.
Traffico in entrata dai client su una rete VPC ai servizi in-mesh utilizzando un bilanciatore del carico (fai clic per ingrandire)

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 queste funzionalità:

  • Un indirizzo IP con indirizzo privato
  • Terminazione TLS per proteggere la rete mesh
  • Funzionalità avanzate di gestione del traffico, come la suddivisione del traffico basata sul peso
  • NEG come backend

Per ulteriori informazioni che ti aiutino a 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 della rete mesh

A seconda delle tue esigenze, puoi prendere in considerazione un pattern più avanzato che aggiunga un gateway aggiuntivo.

Traffico in entrata da client esterni a servizi in-mesh utilizzando un bilanciatore del carico e un proxy perimetrale.
Traffico in entrata da client esterni a servizi in-mesh utilizzando un bilanciatore del carico e un proxy perimetrale (fai clic per ingrandire)

Questo gateway è un proxy perimetrale configurato da 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 di Compute Engine (un gruppo di istanze gestite) o servizi GKE.

Questo pattern è più avanzato, ma 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 Cloud Service Mesh applica un secondo insieme di criteri che potrebbe non essere disponibile 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 la suddivisione del traffico basata sui pesi.

Questo pattern può essere impostato in modo da riflettere la struttura della tua organizzazione. Ad esempio:

  1. Un team potrebbe essere responsabile della gestione del traffico in entrata in Google Cloud, mentre un altro potrebbe essere responsabile della gestione del traffico in entrata verso il suo mesh.

  2. Se più team offrono servizi su un VPC condiviso e ogni team è proprietario del 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 Cloud Service Mesh raggiungibile da un singolo indirizzo IP e una singola coppia di porte. Un team può quindi definire e gestire in modo indipendente i criteri applicati al traffico in entrata nella rete mesh del team.

Questo pattern può essere implementato utilizzando qualsiasi bilanciatore del carico gestito da Google Cloud, purché possa inviare il 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 configurare la gestione del traffico e la 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