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 ai client internet.

Cloud 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 per quanto riguarda la connessione dei client al di fuori del mesh con le applicazioni ospitate nel mesh.

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

Gateway mesh in entrata

Istio 0.8 ha introdotto il gateway in entrata 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 in entrata mesh consentono di 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 mesh-esterno prima che arrivi a un sidecar dell'applicazione. Il traffico mesh in entrata definisce il trattamento del traffico quando raggiunge un nodo nel mesh, ma i componenti esterni devono definire il modo in cui il traffico arriva per la prima volta alla rete.

Per gestire questo traffico esterno, è necessario un bilanciatore del carico esterno al mesh. Questa architettura di riferimento usa le risorse del gateway GKE per il provisioning di Google Cloud Load Balancing.

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 a NodePort di un cluster GKE. Questi NodePort espongono i pod gateway in entrata Istio, che instradano 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, con la differenza che viene eseguito il deployment di un bilanciatore del carico di rete passthrough interno.

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

Il diagramma precedente mostra che l'utilizzo del bilanciamento del carico trasparente L4 con un gateway di traffico in entrata 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, un controllo di integrità e una distribuzione affidabile del traffico 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 mesh in entrata.

Gateway e servizi GKE

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

Quando esegui il deployment delle risorse del gateway GKE nel 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 utilizzato 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, compresa la possibilità di integrazione con i criteri di sicurezza di Google Cloud Armor.
  • I requisiti di copertura del mesh di servizi. I mesh di servizi possono abbracciare più cluster GKE o essere contenuti in un singolo cluster.

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

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

Ingress nel cloud e in entrata nella rete mesh

Il deployment del bilanciamento del carico L7 esterno al di fuori della rete mesh insieme a un livello mesh in entrata offre vantaggi significativi, soprattutto per il traffico internet. Anche se i gateway Cloud Service Mesh e Istio in entrata forniscono routing avanzato e la gestione del traffico nel mesh, alcune funzioni sono gestite meglio sul perimetro della rete. Sfruttare il networking perimetrale di internet tramite il bilanciatore del carico delle applicazioni esterno di Google Cloud potrebbe offrire vantaggi significativi in termini di prestazioni, affidabilità o sicurezza rispetto al traffico in entrata basato su mesh. Questi vantaggi includono:

Questo livello esterno del bilanciamento del carico L7 è denominato cloud in entrata perché è basato su bilanciatori del carico gestiti nel cloud anziché sui proxy self-hosted utilizzati dal traffico in entrata del mesh. La combinazione di traffico in entrata nel cloud e traffico in entrata nel 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 il traffico mesh in entrata in modo da fungere da 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, il livello Cloud Ingress genera il traffico dall'esterno del mesh di servizi e lo indirizza al livello mesh in entrata. Il livello mesh in entrata indirizza quindi il traffico ai backend delle applicazioni ospitati sulla rete mesh.

Topologia in entrata in cloud e mesh

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

  • Traffico in entrata nel cloud: se abbinato al traffico mesh in entrata, il livello Cloud Ingress è ideale per la sicurezza perimetrale e il bilanciamento del carico globale. Poiché il livello Cloud Ingress è integrato con protezione DDoS, firewall cloud, prodotti di autenticazione e crittografia a livello perimetrale, questo livello eccelle nell'esecuzione di questi servizi al di fuori della rete mesh. La logica di routing in genere è semplice 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 del 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. Inoltre, questo controllo rende questo livello meno flessibile e dinamico rispetto a un'infrastruttura gestita dagli sviluppatori, una considerazione che potrebbe influire su chi e come fornisci l'accesso amministrativo a questo livello.
  • Ingresso mesh: se abbinato al traffico in entrata nel cloud, il livello mesh Ingress fornisce un routing flessibile in prossimità dell'applicazione. A causa di questa flessibilità, il traffico mesh in entrata è migliore di quello in entrata nel cloud per una logica di routing complessa e una visibilità a livello di applicazione. La separazione tra i livelli in entrata consente inoltre ai proprietari delle applicazioni di controllare direttamente questo livello più facilmente senza influire sugli altri team. 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 al 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à. Devi configurare ciascun 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 verifica l'integrità dei proxy in entrata del mesh e, in cambio, il mesh 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 bilanciatore del carico Google Cloud tramite il gateway per verificare l'integrità dei proxy in entrata mesh sulle porte esposte per il controllo di integrità. 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, i controlli di integrità vengono eseguiti direttamente sui backend in modo da poter eseguire il bilanciamento del carico e la gestione del traffico in locale.

Sicurezza

La topologia precedente coinvolge anche diversi elementi di sicurezza. Uno degli elementi più cruciali è la configurazione della crittografia e il deployment dei certificati. Il gateway GKE si integra con i certificati gestiti da Google. Puoi fare riferimento a Gestore certificati CertificateMap nella definizione di gateway. I client internet eseguono l'autenticazione sulla base di 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 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 crittografia TLS tra il gateway del cluster (GFE) e il traffico mesh in entrata (l'istanza proxy Envoy). Quando abiliti HTTP/2 con la crittografia TLS per questo percorso, puoi utilizzare un certificato autofirmato o pubblico per criptare il traffico, perché il GFE non esegue l'autenticazione in base a questo percorso. Questo livello aggiuntivo di crittografia è dimostrato 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 richiede TLS, tutto il traffico viene criptato tra i proxy sidecar e il mesh di servizi 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 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, consulta Da perimetrale al mesh: deployment delle applicazioni mesh di servizi tramite il gateway GKE.

Passaggi successivi