Da dispositivi periferici a mesh: esposizione delle applicazioni di mesh di servizi tramite GKE Gateway

Last reviewed 2023-10-24 UTC

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

Cloud Service Mesh è un mesh di servizi gestito, basato su Istio, che fornisce un livello di comunicazione standardizzato, osservabile e con ottimizzazione della sicurezza per le applicazioni. Un mesh di servizi fornisce una piattaforma di comunicazione olistica per i client che comunicano all'interno del mesh. Tuttavia, rimane un problema relativo a come collegare i client esterni al mesh alle applicazioni ospitate al suo interno.

Puoi esporre un'applicazione ai client in molti modi, a seconda della posizione del client. Questa architettura di riferimento è destinata agli esperti avanzati che eseguono Cloud Service Mesh, ma funziona anche per Istio su Google Kubernetes Engine (GKE).

Gateway di ingresso mesh

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

I proxy ti consentono inoltre di applicare il routing e i criteri al traffico esterno al mesh prima che arrivi in un sidecar dell'applicazione. L'ingresso nel mesh definisce il trattamento del traffico quando raggiunge un nodo del mesh, ma i componenti esterni devono definire in che modo il traffico arriva per la prima volta al mesh.

Per gestire questo traffico esterno, devi avere un bilanciatore del carico esterno al mesh. Questa architettura di riferimento utilizza Cloud Load Balancing di Google Cloud provisionato 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). Il bilanciatore del carico punta ai NodePort di un cluster GKE. Questi NodePort espongono i pod gateway di ingresso Istio, che indirizzano il traffico ai proxy sidecar del 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 viene implementato un bilanciatore del carico di rete passthrough interno.

Un bilanciatore del carico esterno instrada i client esterni al mesh tramite i proxy del gateway di ingresso.

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

  • La configurazione semplifica il deployment del bilanciatore del carico.
  • Il bilanciatore del carico fornisce un indirizzo IP virtuale (VIP) stabile, il monitoraggio dello stato di salute e una distribuzione del traffico affidabile in caso di modifiche al cluster, interruzioni dei nodi o interruzioni dei processi.
  • Tutte le regole di routing, la terminazione TLS e i criteri di traffico vengono gestiti in un'unica posizione nel gateway di ingresso del mesh.

Gateway e servizi GKE

Puoi fornire l'accesso alle applicazioni per i client esterni al cluster in diversi modi. GKE Gateway è un'implementazione dell'API Kubernetes Gateway. GKE Gateway fa evolvere la risorsa Ingress e la migliora.

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

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

  • Lo stato dei client (esterni o interni).
  • Le funzionalità richieste del bilanciatore del carico, inclusa la possibilità di integrarsi con i criteri di sicurezza di Google Cloud Armor.
  • I requisiti di copertura del mesh di servizi. Le mesh di servizi possono essere distribuite su più cluster GKE o essere contenute in un singolo cluster.

In GKE Gateway, questo comportamento è controllato specificando GatewayClass appropriato.

Sebbene il bilanciatore del carico predefinito per Cloud Service Mesh sia il bilanciatore del carico di rete, questa architettura di riferimento si concentra sul bilanciatore del carico delle applicazioni (L7) esterno. Il bilanciatore del carico delle applicazioni esterno fornisce 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 sezione successiva descrive l'architettura e i vantaggi dell'utilizzo di due livelli di bilanciamento del carico HTTP.

Ingresso cloud e ingresso mesh

Il deployment del bilanciamento del carico L7 esterno al di fuori del mesh insieme a un livello di ingresso del mesh offre vantaggi significativi, in particolare per il traffico internet. Anche se Cloud Service Mesh e Istio ingress gateway forniscono routing e gestione del traffico avanzati nel mesh, alcune funzioni sono meglio servite all'edge della rete. Sfruttare la rete di confine di internet tramite il bilanciatore del carico delle applicazioni esterno diGoogle Cloudpotrebbe offrire vantaggi significativi in termini di prestazioni, affidabilità o sicurezza rispetto all'ingresso basato su mesh. Questi vantaggi includono:

Questo livello esterno di bilanciamento del carico L7 è denominato ingresso cloud perché si basa su bilanciatori del carico gestiti dal cloud anziché su proxy auto-hosted utilizzati dall'ingresso mesh. La combinazione di ingressi cloud e mesh utilizza funzionalità complementari dell' Google Cloud infrastruttura e del mesh. Il seguente diagramma illustra come combinare l'ingresso cloud (tramite il gateway GKE) e l'ingresso mesh per fungere da due livelli di bilanciamento del carico per il traffico internet.

L'ingresso cloud funge da gateway per il traffico esterno al mesh tramite la rete VPC.

Nella topologia del diagramma precedente, il livello di ingresso cloud genera il traffico dall'esterno del mesh di servizi e lo indirizza al livello di ingresso del mesh. Il livello di ingresso del mesh indirizza quindi il traffico ai backend delle applicazioni ospitate nel mesh.

Topologia di ingresso cloud e mesh

Questa sezione descrive i ruoli complementari svolti da ciascun livello di ingresso quando li utilizzi insieme. Questi ruoli non sono regole concrete, ma linee guida che sfruttano i vantaggi di ogni livello. È probabile che esistano varianti di questo pattern, a seconda del caso d'uso.

  • Ingresso cloud: se abbinato all'ingresso mesh, il livello di ingresso cloud è ideale per la sicurezza di confine e il bilanciamento del carico globale. Poiché il livello di ingresso cloud è integrato con protezione DDoS, firewall cloud, autenticazione e prodotti di crittografia all'edge, questo livello è eccellente per l'esecuzione di questi servizi al di fuori del mesh. La logica di routing è in genere semplice a questo livello, ma può essere più complessa per gli ambienti multicluster e multiregione. A causa della funzione critica dei bilanciatori del carico rivolti a internet, è probabile che il livello di ingresso del cloud sia gestito da un team di infrastruttura che ha il controllo esclusivo su come le applicazioni vengono esposte e protette su internet. Questo controllo inoltre rende questo livello meno flessibile e dinamico di un'infrastruttura guidata dagli sviluppatori, un aspetto che potrebbe influire su chi e come fornisci accesso amministrativo a questo livello.
  • Ingresso mesh:se accoppiato all'ingresso cloud, il livello di ingresso mesh fornisce un routing flessibile vicino all'applicazione. Grazie a questa flexibilità, l'ingresso mesh è migliore dell'ingresso cloud per la logica di routing complessa e la visibilità a livello di applicazione. La separazione tra i livelli di ingresso consente inoltre ai proprietari di applicazioni di controllare direttamente questo livello senza influire su altri team. Per contribuire a proteggere le applicazioni, quando esponi le applicazioni del mesh di servizi tramite un bilanciatore del carico L4 anziché un bilanciatore del carico L7, devi terminare il TLS client a livello di livello di ingresso del mesh all'interno del mesh.

Controllo di integrità

Un aspetto complesso dell'utilizzo di due livelli di bilanciamento del carico L7 è il controllo di integrità. Devi configurare ogni bilanciatore del carico per verificare l'integrità del livello successivo per assicurarti che possa ricevere traffico. La topologia nel seguente diagramma mostra come l'ingresso cloud controlla l'integrità dei proxy di ingresso del mesh e il mesh, a sua volta, controlla l'integrità dei backend dell'applicazione.

L'ingresso cloud controlla l'integrità dell'ingresso del mesh, che a sua volta controlla l'integrità dei backend dell'applicazione.

La topologia precedente presenta le seguenti considerazioni:

  • Ingresso cloud: in questa architettura di riferimento, configuri il bilanciatore del caricoGoogle Cloud tramite il gateway per controllare l'integrità dei proxy di ingresso mesh sulle porte di controllo di integrità esposte. Se un proxy mesh è inattivo o se il cluster, il mesh o la regione non è disponibile, il bilanciatore del carico Google Cloud rileva questa condizione e non invia traffico al proxy mesh.
  • Ingresso del mesh: nell'applicazione mesh, esegui i 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 del deployment dei certificati. GKE Gateway si integra con i certificati gestiti da Google. Puoi fare riferimento a un gestore dei certificati CertificateMap nella definizione del gateway. I client internet si autenticano in base ai certificati pubblici e si connettono al bilanciatore del carico esterno come primo hop nel Virtual Private Cloud (VPC).

L'hop successivo, che si trova tra Google Front End (GFE) e il proxy di ingresso 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 prevedono che il proprietario della piattaforma debba mantenere la proprietà delle chiavi di crittografia, puoi attivare HTTP/2 con crittografia TLS tra il gateway del cluster (GFE) e l'ingresso del mesh (l'istanza del proxy Envoy). Quando attivi HTTP/2 con crittografia TLS per questo percorso, puoi utilizzare un certificato pubblico o autofirmato per criptare il traffico perché il GFE non esegue l'autenticazione. Questo ulteriore livello di crittografia è illustrato nella guida all'implementazione associata. Per contribuire a evitare la gestione errata dei certificati, non utilizzare il certificato pubblico per il bilanciatore del carico pubblico altrove. Ti consigliamo invece di utilizzare certificati separati nel mesh di servizi.

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

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, consulta Da dispositivi periferici a mesh: esegui il deployment delle applicazioni di mesh di servizi tramite GKE Gateway.

Passaggi successivi