Da perimetro a mesh: espone le applicazioni mesh di servizi tramite il gateway GKE

Last reviewed 2023-10-24 UTC

Questa architettura di riferimento mostra come combinare Anthos Service Mesh con Cloud Load Balancing per esporre le applicazioni in un mesh di servizi ai client internet.

Anthos Service Mesh è un mesh di servizi gestiti, basato su Istio, che fornisce un livello di comunicazione standardizzato, osservabile e con sicurezza avanzata per le applicazioni. Un mesh di servizi fornisce una piattaforma di comunicazione olistica per i clienti che comunicano nel mesh. Tuttavia, rimane una sfida nel connettere i client all'esterno del mesh con le applicazioni ospitate all'interno del mesh.

Puoi esporre un'applicazione ai client in molti modi, a seconda di dove si trova il client. Questa architettura di riferimento è pensata per i professionisti avanzati che eseguono Anthos Service Mesh, ma funziona anche per Istio su Google Kubernetes Engine (GKE).

Gateway in entrata mesh

Istio 0.8 ha introdotto il gateway in entrata del mesh. Il gateway fornisce un set dedicato di proxy le cui porte sono esposte al traffico proveniente dall'esterno del mesh di servizi. Questi proxy in entrata mesh consentono di controllare il comportamento di esposizione della rete separatamente dal comportamento di routing delle applicazioni.

I proxy consentono inoltre di applicare routing e criteri al traffico mesh-esterno prima che arrivi a un file collaterale dell'applicazione. Il traffico in entrata in mesh definisce il trattamento del traffico quando raggiunge un nodo nel mesh, ma i componenti esterni devono definire in che modo il traffico arriva prima nel mesh.

Per gestire questo traffico esterno, hai bisogno di un bilanciatore del carico esterno al mesh. Questa architettura di riferimento utilizza Google Cloud Load Balancing di cui è stato eseguito il provisioning tramite le risorse GKE Gateway per automatizzare il deployment.

Per Google Cloud, l'esempio canonico di questa configurazione è un servizio di bilanciamento del carico esterno che esegue il deployment di un bilanciatore del carico di rete pubblico (L4). Quel bilanciatore del carico punta alle NodePort di un cluster GKE. Queste NodePort espongono i pod gateway in entrata Istio, che instradano il traffico ai proxy sidecar mesh downstream.

Architettura

Il seguente diagramma illustra questa topologia. Il bilanciamento del carico per il traffico privato interno è simile a questa architettura, tranne per il fatto che esegui il deployment di un bilanciatore del carico di rete passthrough interno.

Un bilanciatore del carico esterno instrada i client esterni al mesh attraverso i proxy del gateway in entrata.

Il diagramma precedente mostra che l'utilizzo del bilanciamento del carico trasparente L4 con un gateway in entrata mesh offre i seguenti vantaggi:

  • Questa configurazione semplifica il deployment del bilanciatore del carico.
  • Il bilanciatore del carico fornisce un indirizzo IP virtuale (VIP), un controllo di integrità e una distribuzione affidabile del traffico stabile in caso di modifiche del cluster, interruzioni dei nodi o interruzioni del processo.
  • Tutte le regole di routing, la terminazione TLS e i criteri di traffico vengono gestiti in un'unica posizione presso il gateway in entrata mesh.

Gateway e servizi GKE

Puoi fornire l'accesso alle applicazioni per i client che si trovano all'esterno del cluster in molti modi. Il gateway GKE è un'implementazione dell'API Kubernetes Gateway. Il gateway GKE evolve la risorsa Ingress e la migliora.

Durante il deployment delle risorse del gateway GKE nel tuo cluster GKE, il controller gateway controlla le risorse dell'API Gateway e riconcilia le risorse di Cloud Load Balancing per implementare il comportamento di rete specificato dalle risorse del gateway GKE.

Quando utilizzi il gateway GKE, il tipo di bilanciatore del carico per esporre le applicazioni ai client dipende in gran parte dai seguenti fattori:

  • Lo stato dei clienti (esterno o interno).
  • Le funzionalità richieste del bilanciatore del carico, inclusa la capacità di integrazione con i criteri di sicurezza di Google Cloud Armor.
  • Tutti i requisiti del mesh di servizi. I mesh di servizi possono estendersi su più cluster GKE o essere contenuti in un unico cluster.

Nel gateway GKE, questo comportamento è controllato specificando il valore GatewayClass appropriato.

Sebbene il bilanciatore del carico predefinito per Anthos Service Mesh sia il bilanciatore del carico di rete, questa architettura di riferimento è incentrata sul bilanciatore del carico delle applicazioni esterno (L7). L'Application Load Balancer esterno offre l'integrazione con servizi perimetrali come Identity-Aware Proxy e Google Cloud Armor, reindirizzamenti e riscritture di URL, nonché una rete di proxy perimetrali distribuita a livello globale. La prossima sezione descrive l'architettura e i vantaggi dell'utilizzo di due livelli di bilanciamento del carico HTTP.

Traffico in entrata nel cloud e mesh

Il deployment del bilanciamento del carico L7 esterno all'esterno del mesh insieme a un livello in entrata mesh offre vantaggi significativi, soprattutto per il traffico internet. Anche se i gateway Anthos Service Mesh e Istio in entrata forniscono il routing avanzato e la gestione del traffico nel mesh, alcune funzioni sono gestite meglio sul perimetro della rete. Il vantaggio delle reti Internet-edge attraverso l'Application Load Balancer esterno di Google Cloud potrebbe offrire notevoli prestazioni, affidabilità o vantaggi relativi alla sicurezza rispetto al traffico in entrata basato su mesh. Questi vantaggi includono:

Questo livello esterno del bilanciamento del carico L7 è denominato in entrata nel cloud perché è basato su bilanciatori del carico gestiti su cloud anziché sui proxy self-hosted utilizzati dal traffico mesh in entrata. La combinazione di traffico in entrata nel cloud e in entrata tramite mesh utilizza funzionalità complementari dell'infrastruttura di Google Cloud e del mesh. Il seguente diagramma illustra come combinare il traffico in entrata nel cloud (tramite il gateway GKE) e in entrata in modalità mesh in modo da fungere da due livelli di bilanciamento del carico per il traffico internet.

Cloud Ingress funge da gateway per il traffico esterno verso il mesh attraverso la rete VPC.

Nella topologia del diagramma precedente, il livello cloud in entrata prende il traffico dall'esterno del mesh di servizi e lo indirizza al livello in entrata del mesh. Quindi, il livello mesh in entrata indirizza il traffico ai backend delle applicazioni ospitati dal mesh.

Topologia in entrata cloud e mesh

Questa sezione descrive i ruoli complementari di ogni livello in entrata quando li utilizzi insieme. Questi ruoli non sono regole concrete, ma linee guida che sfruttano i vantaggi di ogni livello. È probabile che vi siano variazioni di questo pattern, a seconda del caso d'uso.

  • In entrata nel cloud: se abbinato al traffico mesh in entrata, il livello in entrata nel cloud è ideale per la sicurezza perimetrale e il bilanciamento del carico globale. Poiché il livello cloud in entrata è integrato con i prodotti di protezione DDoS, firewall cloud, autenticazione e crittografia a livello perimetrale, questo livello è ideale nell'esecuzione di questi servizi al di fuori del mesh. La logica di routing è in genere semplificata a questo livello, ma può essere più complessa per ambienti multi-cluster e multiregionali. A causa della funzione critica dei bilanciatori del carico rivolti a internet, il livello di traffico in entrata nel cloud è probabilmente gestito da un team dell'infrastruttura che ha il controllo esclusivo su come le applicazioni sono esposte e protette su internet. Questo controllo rende inoltre questo livello meno flessibile e dinamico di un'infrastruttura guidata dagli sviluppatori, una considerazione che potrebbe influire su chi e come fornisci l'accesso amministrativo a questo livello.
  • In entrata mesh: se abbinato a traffico in entrata nel cloud, il livello in entrata della rete mesh offre un routing flessibile vicino all'applicazione. Grazie a questa flessibilità, il traffico mesh in entrata è migliore di quello in entrata nel cloud per la logica di routing complessa e la visibilità a livello di applicazione. Inoltre, la separazione tra i livelli in entrata semplifica il controllo diretto di questo livello per i proprietari delle applicazioni senza influire sugli altri team. Per proteggere le applicazioni Quando esponi applicazioni mesh di servizi tramite un bilanciatore del carico L4 anziché un bilanciatore del carico L7, devi terminare la connessione TLS del client al livello mesh in entrata all'interno del mesh.

Controllo di integrità

Una delle complessità nell'utilizzo di due livelli del bilanciamento del carico L7 è il controllo di integrità. Devi configurare ogni bilanciatore del carico per verificare l'integrità del livello successivo e assicurarti che possa ricevere traffico. La topologia nel seguente diagramma mostra in che modo il traffico in entrata nel cloud controlla l'integrità dei proxy in entrata del mesh e, di conseguenza, il mesh controlla l'integrità dei backend delle applicazioni.

Cloud Ingress controlla l'integrità del traffico mesh in entrata, mentre il mesh in entrata controlla l'integrità dei backend delle applicazioni.

La topologia precedente presenta le seguenti considerazioni:

  • In entrata nel cloud: in questa architettura di riferimento, configurerai il bilanciatore del carico di Google Cloud tramite il gateway per verificare l'integrità dei proxy in entrata mesh sulle rispettive porte per il controllo di integrità esposte. Se un proxy mesh non è attivo o se il cluster, il mesh o la regione non sono disponibili, il bilanciatore del carico di Google Cloud rileva questa condizione e non invia traffico al proxy mesh.
  • Ingresso mesh: nell'applicazione mesh, esegui controlli di integrità direttamente sui backend in modo da poter eseguire il bilanciamento del carico e la gestione del traffico localmente.

Sicurezza

La topologia precedente prevede anche diversi elementi di sicurezza. Uno degli elementi più critici è la modalità di configurazione della crittografia e di deployment dei certificati. Il gateway GKE si integra con i certificati gestiti da Google. Puoi fare riferimento a un Gestore certificati CertificateMap nella definizione del gateway. I client internet eseguono l'autenticazione in base ai certificati pubblici e si connettono al bilanciatore del carico esterno come primo hop nel Virtual Private Cloud (VPC).

L'hop successivo, tra il Google Front End (GFE) e il proxy in entrata della rete mesh, è criptato per impostazione predefinita. La crittografia a livello di rete tra i GFE e i relativi backend viene applicata automaticamente. Tuttavia, se i tuoi requisiti di sicurezza richiedono che il proprietario della piattaforma mantenga la proprietà delle chiavi di crittografia, puoi abilitare HTTP/2 con la crittografia TLS tra il gateway del cluster (GFE) e il traffico mesh in entrata (l'istanza proxy di proxy). Quando abiliti HTTP/2 con crittografia TLS per questo percorso, puoi utilizzare un certificato autofirmato o pubblico per criptare il traffico perché il GFE non esegue l'autenticazione. Questo livello aggiuntivo di crittografia è mostrato nella guida al deployment associata. Per evitare il maltrattamento dei certificati, non utilizzare altrove il certificato pubblico per il bilanciatore del carico pubblico. Ti consigliamo invece di utilizzare certificati separati nel mesh di servizi.

Se il mesh di servizi impone TLS, tutto il traffico viene criptato tra i proxy collaterali e il traffico mesh in entrata. Il seguente diagramma illustra la crittografia HTTPS dal client al bilanciatore del carico Google Cloud, dal bilanciatore del carico al proxy in entrata del mesh e dal proxy in entrata al proxy sidecar.

La sicurezza viene implementata utilizzando certificati gestiti all'esterno del mesh e certificati interni all'interno del mesh.

Ottimizzazione dei costi

In questo documento utilizzerai i seguenti componenti fatturabili di Google Cloud:

Deployment

Per eseguire il deployment di questa architettura, vedi Da perimetro a mesh: deployment di applicazioni mesh di servizi tramite il gateway GKE.

Passaggi successivi