Da perimetro al mesh: esponi le applicazioni mesh di servizi tramite il gateway GKE

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 a internet clienti.

Cloud Service Mesh è un mesh di servizi gestiti, basato su Istio, che fornisce una sicurezza avanzata, osservabile e standardizzata per i diverse applicazioni. R mesh di servizi fornisce una piattaforma di comunicazione olistica per i clienti che comunicano nella rete. Tuttavia, rimane una sfida nel modo di entrare in contatto dai client esterni al mesh alle applicazioni ospitate all'interno del mesh.

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

Gateway mesh in entrata

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

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

Per gestire questo traffico esterno, è necessario un bilanciatore del carico esterno la rete mesh. Questa architettura di riferimento utilizza il provisioning di Google Cloud Load Balancing attraverso le risorse del gateway GKE per automatizzare il deployment.

Per Google Cloud, esempio canonico di questa configurazione è un servizio di bilanciamento del carico esterno che esegue il deployment il bilanciatore del carico di rete (L4). Il bilanciatore del carico punta a NodePort di un cluster GKE. Questi NodePort espongono il traffico Istio in entrata , che instradano il traffico a proxy sidecar del mesh downstream.

Architettura

Il seguente diagramma illustra questa topologia. Bilanciamento del carico per il traffico privato interno è simile a questa architettura, con la differenza che il deployment di un bilanciatore del carico di rete passthrough interno.

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

Il diagramma precedente mostra che l'utilizzo del bilanciamento del carico trasparente L4 con un Il gateway mesh in entrata 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 controllo e la distribuzione affidabile del traffico quando il cluster cambia, o interruzioni dei processi.
  • Tutte le regole di routing, la terminazione TLS e i criteri di traffico vengono gestiti in un singola posizione presso il gateway in entrata mesh.

Gateway e servizi GKE

Puoi fornire l'accesso alle applicazioni per i client esterni al cluster in molti modi. Il gateway GKE è un'implementazione API Kubernetes Gateway. Gateway GKE evolve la risorsa Ingress e la migliora.

Quando esegui il deployment delle risorse del gateway GKE Cluster GKE, il controller Gateway controlla l'API Gateway e riconcilia le risorse di Cloud Load Balancing per implementare un comportamento di networking specificato dal gateway GKE Google Cloud.

Quando utilizzi il gateway GKE, il tipo di bilanciatore del carico utilizzato dell'esposizione delle applicazioni ai client dipende in gran parte dai seguenti fattori:

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

Nel gateway GKE, questo comportamento viene controllato specificando l'appropriata GatewayClass.

Anche se il bilanciatore del carico di rete predefinito è il bilanciatore del carico di rete, questa architettura di riferimento è incentrata il bilanciatore del carico delle applicazioni esterno (L7). Il bilanciatore del carico delle applicazioni esterno fornisce l'integrazione 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 carico HTTP e del bilanciamento del carico.

Ingress nel cloud e in entrata nella rete mesh

Deployment del bilanciamento del carico L7 esterno all'esterno del mesh insieme a un mesh in entrata offre vantaggi significativi, soprattutto per il traffico internet. Anche se i gateway in entrata Cloud Service Mesh e Istio forniscono per la gestione del traffico e del routing nella rete mesh, alcune funzioni sono gestite in modo migliore sul perimetro della rete. Sfruttare il networking a livello di internet attraverso Il bilanciatore del carico delle applicazioni esterno di Google Cloud potrebbe fornire vantaggi significativi in termini di prestazioni, affidabilità o sicurezza rispetto il traffico in entrata basato su mesh. Questi vantaggi includono:

Questo livello esterno del bilanciamento del carico L7 è denominato Cloud Ingress. perché è basato su bilanciatori del carico gestiti nel cloud anziché usati dal mesh in entrata. La combinazione di traffico in entrata nel cloud e mesh Il traffico in entrata utilizza funzionalità complementari dell'infrastruttura Google Cloud e la rete mesh. Il seguente diagramma illustra come combinare in entrata (tramite il gateway GKE) e in entrata nella rete mesh come due livelli di bilanciamento del carico per il traffico internet.

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

Nella topologia del diagramma precedente, le origini del livello Cloud Ingress il traffico proveniente dall'esterno dalla rete mesh di servizi e indirizza il traffico al livello in entrata della rete mesh. La rete mesh in entrata indirizza quindi il traffico ai backend dell'applicazione ospitati su un mesh.

Topologia in entrata in cloud e mesh

Questa sezione descrive i ruoli complementari che ogni livello in entrata svolge. quando li usi insieme. Questi ruoli non sono regole concrete, linee guida che utilizzano i vantaggi di ogni livello. Le varianti di questo modello sono a seconda del caso d'uso.

  • In entrata nel cloud: se abbinato al traffico in entrata mesh, il traffico in entrata nel cloud. è la soluzione ideale per la sicurezza perimetrale e il bilanciamento del carico globale. Poiché il livello di traffico in entrata nel cloud è integrato con la protezione DDoS, firewall cloud, di autenticazione e crittografia a livello perimetrale, questo livello eccelle in che eseguono questi servizi al di fuori del mesh. La logica di routing è in genere semplice a questo livello, ma la logica può essere più complessa ambienti multi-cluster e multiregionali. A causa delle critiche una funzione dei bilanciatori del carico per internet, il livello di traffico in entrata nel cloud probabilmente gestite da un team dell'infrastruttura che ha il controllo esclusivo le modalità di esposizione e protezione delle applicazioni su internet. Questo controllo rende questo livello meno flessibile e dinamico rispetto a un livello un'infrastruttura, una considerazione che potrebbe influire su chi e come viene l'accesso amministrativo a questo livello.
  • Ingresso mesh:se accoppiato al traffico in entrata nel cloud, si tratta del livello mesh in entrata. fornisce un routing flessibile in prossimità dell'applicazione. Per questo motivo flessibilità, il traffico mesh in entrata è migliore di quello in entrata nel cloud per logica di routing e visibilità a livello di applicazione. La separazione tra i livelli in entrata consentono inoltre ai proprietari di applicazioni di indirizzare controllare questo livello senza influire sugli altri team. Per contribuire a proteggere Quando esponi le applicazioni mesh di servizi tramite un bilanciatore del carico L4 anziché un bilanciatore del carico L7, devi terminare il protocollo TLS del client allo livello del mesh di servizi in entrata all'interno della rete.

Controllo di integrità

Una complessità dell'utilizzo di due livelli del bilanciamento del carico L7 è il controllo di integrità. Tu configurare ciascun bilanciatore del carico per verificare l'integrità del livello assicurarsi che possa ricevere traffico. La topologia nel seguente diagramma mostra il modo in cui il traffico in entrata nel cloud controlla l'integrità dei proxy in entrata del mesh e della rete, controlla l'integrità dei backend dell'applicazione.

Il traffico in entrata nel cloud controlla l'integrità del traffico in entrata nella rete mesh, mentre il traffico in entrata nella rete mesh controlla l'integrità dei backend dell'applicazione.

La topologia precedente contiene le seguenti considerazioni:

  • In entrata nel cloud: in questa architettura di riferimento, configuri il Google Cloud tramite il gateway per verificare l'integrità proxy in entrata mesh sulle porte esposte per il controllo di integrità. Se viene utilizzato un proxy mesh oppure, se il cluster, il mesh o la regione non sono disponibili, il bilanciatore del carico rileva questa condizione e non invia traffico al mesh proxy.
  • Ingresso mesh: nell'applicazione mesh, vengono eseguiti i controlli di integrità direttamente i backend, in modo da poter eseguire il bilanciamento del carico e il traffico a livello locale.

Sicurezza

La topologia precedente coinvolge anche diversi elementi di sicurezza. Uno dei principali elementi critici sono la configurazione della crittografia e il deployment dei certificati. Gateway GKE si integra con Certificati gestiti da Google. Puoi fare riferimento a Gestione certificati CertificateMap nella definizione di gateway. I client internet eseguono l'autenticazione sulla base di certificati pubblici e si connettono bilanciatore del carico esterno come primo hop nel Virtual Private Cloud (VPC).

L'hop successivo, che è tra Google Front End (GFE) e il mesh in entrata un proxy, è criptati per impostazione predefinita. Viene applicata la crittografia a livello di rete tra i GFE e i relativi backend automaticamente. Tuttavia, se i requisiti di sicurezza impongono che la piattaforma mantenga la proprietà delle chiavi di crittografia, quindi puoi abilitare HTTP/2 con Crittografia TLS tra il gateway del cluster (GFE) e il traffico mesh in entrata (il proxy Envoy). Se abiliti HTTP/2 con crittografia TLS per questo percorso, puoi utilizzare un certificato autofirmato o pubblico per criptare il traffico il GFE non esegue l'autenticazione. Questo livello aggiuntivo di crittografia è dimostrato nella documentazione guida all'implementazione. Per evitare il maltrattamento dei certificati, non utilizzare le informazioni pubbliche per il bilanciatore del carico pubblico. Consigliamo invece di eseguire utilizzi certificati separati nel mesh di servizi.

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

La sicurezza viene implementata utilizzando certificati gestiti al di fuori del mesh e certificati interni al mesh.

Ottimizzazione dei costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Deployment

Per eseguire il deployment di questa architettura, Da perimetrale al mesh: esegui il deployment delle applicazioni mesh di servizi tramite il gateway GKE.

Passaggi successivi