Da dispositivi periferici a mesh multi-cluster: applicazioni distribuite a livello globale esposte tramite GKE Gateway e Cloud Service Mesh

Last reviewed 2024-06-30 UTC

Questa architettura di riferimento descrive i vantaggi dell'esposizione esterna delle applicazioni tramite i gateway Google Kubernetes Engine (GKE) in esecuzione su più cluster GKE all'interno di un mesh di servizi. Questa guida è rivolta agli amministratori della piattaforma.

Puoi aumentare la resilienza e la ridondanza dei tuoi servizi eseguendo il deployment delle applicazioni in modo coerente in più cluster GKE, dove ogni cluster diventa un dominio in errore aggiuntivo. Ad esempio, l'infrastruttura di calcolo di un servizio con un obiettivo del livello del servizio (SLO) del 99,9% quando viene implementata in un singolo cluster GKE raggiunge un SLO del 99,9999% quando viene implementata in due cluster GKE (1 - (0,001)2). Puoi anche offrire agli utenti un'esperienza in cui le richieste in entrata vengono indirizzate automaticamente al gateway di ingresso mesh con la latenza più bassa e disponibile.

Se ti interessano i vantaggi dell'esposizione di applicazioni abilitate al service mesh in esecuzione su un singolo cluster, consulta Da dispositivi periferici a mesh: esposizione delle applicazionmesh di servizish mediante GKE Gateway.

Architettura

Il seguente diagramma dell'architettura mostra il flusso dei dati attraverso l'ingresso cloud e l'ingresso mesh:

Crittografia TLS dal client, da un bilanciatore del carico e dalla mesh.

Il diagramma precedente mostra i seguenti scenari di flusso di dati:

  • Dal client che termina al bilanciatore del carico Google Cloud utilizzando il proprio certificato TLS gestito da Google.
  • Dal bilanciatore del carico al proxy in entrata del mesh utilizzando il proprio certificato TLS autofirmato. Google Cloud
  • Dal proxy del gateway in entrata della mesh ai proxy sidecar del workload utilizzando mTLS abilitato per mesh di servizi.

Questa architettura di riferimento contiene i seguenti due livelli di ingresso:

  • Ingresso cloud:in questa architettura di riferimento, utilizzi l'API Kubernetes Gateway (e il controller GKE Gateway) per programmare il livello di bilanciamento del carico HTTP(S) esterno e multi-cluster. Il bilanciatore del carico controlla i proxy di ingresso mesh in più regioni, inviando le richieste al cluster integro più vicino. Implementa anche un criterio di sicurezza Google Cloud Armor.
  • Ingresso mesh:nella mesh, esegui i controlli di integrità sui backend direttamente per poter eseguire il bilanciamento del carico e la gestione del traffico in locale.

Quando utilizzi insieme i livelli di ingresso, esistono ruoli complementari per ogni livello. Per raggiungere i seguenti obiettivi, Google Cloud ottimizza le funzionalità più appropriate del livello di ingresso cloud e del livello di ingresso mesh:

  • Fornire una bassa latenza.
  • Aumentare la disponibilità.
  • Utilizza le funzionalità di sicurezza del livello di ingresso cloud.
  • Utilizza le funzionalità di sicurezza, autorizzazione e osservabilità del livello di ingresso del mesh.

Ingresso nel cloud

Se abbinato all'ingresso mesh, il livello di ingresso cloud è ideale per la sicurezza perimetrale e il bilanciamento del carico globale. Poiché il livello di ingresso cloud è integrato con i seguenti servizi, è ideale per l'esecuzione di questi servizi all'edge, al di fuori del mesh:

  • protezione dagli attacchi DDoS
  • Firewall cloud
  • Autenticazione e autorizzazione
  • Crittografia

La logica di routing è in genere semplice a livello di ingresso cloud. Tuttavia, può essere più complesso per gli ambienti multicluster e multiregionali.

A causa della funzione critica dei bilanciatori del carico rivolti a internet, il livello di ingresso cloud è probabilmente gestito da un team della piattaforma che ha il controllo esclusivo su come le applicazioni vengono esposte e protette su internet. Questo controllo rende questo livello meno flessibile e dinamico di un'infrastruttura gestita dagli sviluppatori. Tieni in considerazione questi fattori quando determini i diritti di accesso amministrativo a questo livello e come fornisci l'accesso.

Ingress mesh

Se abbinato all'ingresso cloud, il livello di ingresso del mesh fornisce un punto di ingresso per il traffico che entra nel mesh di servizi. Il livello fornisce anche mTLS del backend, norme di autorizzazione e corrispondenza flessibile delle espressioni regolari.

Il deployment del bilanciamento del carico delle applicazioni esterno al di fuori del mesh con un livello di ingresso mesh offre vantaggi significativi, soprattutto per la gestione del traffico internet. Sebbene mesh di servizi e i gateway in entrata Istio forniscano routing e gestione del traffico avanzati nel mesh, alcune funzioni sono gestite meglio all'edge della rete. Sfruttare il networking perimetrale 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.

Prodotti e funzionalità utilizzati

Il seguente elenco riepiloga tutti i prodotti e le funzionalità Google Cloud utilizzati da questa architettura di riferimento:

  • GKE Enterprise: Un servizio Kubernetes gestito che puoi utilizzare per eseguire il deployment e gestire applicazioni containerizzate su larga scala utilizzando l'infrastruttura di Google. Ai fini di questa architettura di riferimento, ogni cluster GKE che gestisce un'applicazione deve trovarsi nello stesso parco risorse.
  • Fleet e gateway multi-cluster: servizi utilizzati per creare applicazioni containerizzate su larga scala utilizzando l'infrastruttura di Google e GKE Enterprise.
  • Google Cloud Armor: Un servizio che ti aiuta a proteggere le tue applicazioni e i tuoi siti web dagli attacchi web e denial of service.
  • Cloud Service Mesh: Un mesh di servizi completamente gestito basato su Envoy e Istio
  • Bilanciatore del carico delle applicazioni: Un bilanciatore del carico L7 basato su proxy che ti consente di eseguire e scalare i servizi.
  • Certificate Manager: Un servizio che consente di acquisire e gestire i certificati TLS da utilizzare con Cloud Load Balancing.

Parchi risorse

Per gestire le implementazioni multi-cluster, GKE Enterprise e Google Cloud utilizzano i parchi risorse per raggruppare e normalizzare in modo logico i cluster Kubernetes.

L'utilizzo di uno o più parchi risorse può aiutarti a migliorare il livello di gestione da singoli cluster a interi gruppi di cluster. Per ridurre l'attrito nella gestione dei cluster, utilizza il principio di uguaglianza dello spazio dei nomi del parco risorse. Per ogni cluster GKE in un fleet, assicurati di configurare tutti i gateway di ingresso mesh allo stesso modo.

Inoltre, implementa in modo coerente i servizi applicativi in modo che il servizio balance-reader nell'account dello spazio dei nomi sia correlato a un servizio identico in ogni cluster GKE del parco risorse. I principi di uguaglianza e fiducia presupposti all'interno di un parco risorse consentono di utilizzare l'intera gamma di funzionalità abilitate per il parco risorse in GKE Enterprise e Google Cloud.

Le regole di routing est-ovest all'interno del mesh di servizi e i criteri di traffico vengono gestiti a livello di ingresso del mesh. Il livello di ingresso mesh viene implementato su ogni cluster GKE nel parco risorse. Configura ogni gateway di ingresso mesh nello stesso modo, rispettando il principio di identità dello spazio dei nomi del parco.

Sebbene esista un singolo cluster di configurazione per GKE Gateway, devi sincronizzare le configurazioni di GKE Gateway in tutti i cluster GKE del parco risorse.

Se devi nominare un nuovo cluster di configurazione, utilizza ConfigSync. ConfigSync contribuisce a garantire che tutte queste configurazioni vengano sincronizzate in tutti i cluster GKE del parco risorse e contribuisce a evitare la riconciliazione con una configurazione non attuale.

Gateway in entrata mesh

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 di ingresso mesh ti consentono di controllare il comportamento di esposizione della rete separatamente dal comportamento di routing dell'applicazione.

I proxy consentono anche di applicare il routing e i criteri al traffico esterno al mesh prima che arrivi a un sidecar dell'applicazione. L'ingresso mesh definisce il trattamento del traffico quando raggiunge un nodo nella mesh, ma i componenti esterni devono definire come il traffico arriva inizialmente alla mesh.

Per gestire il traffico esterno, hai bisogno di un bilanciatore del carico esterno al mesh. Per automatizzare il deployment, questa architettura di riferimento utilizza Cloud Load Balancing, di cui viene eseguito il provisioning tramite le risorse gateway GKE.

Gateway GKE e servizi multi-cluster

Esistono molti modi per fornire l'accesso alle applicazioni ai client esterni al cluster. GKE Gateway è un'implementazione dell'API Kubernetes Gateway. Il gateway GKE fa evolvere e migliora la risorsa Ingress.

Quando esegui il deployment delle risorse GKE Gateway nel tuo cluster GKE, il controller Gateway monitora le risorse API Gateway. Il controller riconcilia le risorse di Cloud Load Balancing per implementare il comportamento di networking specificato dalle risorse 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:

  • Se i servizi di backend si trovano in un singolo cluster GKE o distribuiti su più cluster GKE (nello stesso parco risorse).
  • Lo stato dei clienti (esterni o interni).
  • Le funzionalità richieste del bilanciatore del carico, inclusa la funzionalità di integrazione con i criteri di sicurezza Cloud Armor.
  • I requisiti di spanning del mesh di servizi. Le service mesh possono estendersi a più cluster GKE o possono essere contenute in un singolo cluster.

In Gateway, questo comportamento è controllato specificando l'GatewayClass appropriata. Quando si fa riferimento alle classi gateway, quelle che possono essere utilizzate in scenari multicluster hanno un nome di classe che termina con -mc.

Questa architettura di riferimento illustra come esporre i servizi applicativi esternamente tramite un bilanciatore del carico delle applicazioni esterno. Tuttavia, quando utilizzi Gateway, puoi anche creare un bilanciatore del carico delle applicazioni interno regionale multicluster.

Per eseguire il deployment dei servizi applicativi in scenari multi-cluster, puoi definire i componenti del bilanciatore del caricoGoogle Cloud in due modi:

Per ulteriori informazioni su questi due approcci al deployment dei servizi applicativi, consulta Scegliere l'API di bilanciamento del carico multicluster per GKE.

Ingress multi-cluster si basa sulla creazione di risorse MultiClusterService. Multi-cluster Gateway si basa sulla creazione di risorse ServiceExport e sul riferimento a risorse ServiceImport.

Quando utilizzi un gateway multi-cluster, puoi attivare le funzionalità aggiuntive del bilanciatore del carico sottostante creando policy. Google Cloud La guida al deployment associata a questa architettura di riferimento mostra come configurare una policy di sicurezza Google Cloud Armor per proteggere i servizi di backend dagli attacchi cross-site scripting.

Queste risorse dei criteri hanno come target i servizi di backend nel parco risorse che sono esposti in più cluster. Negli scenari multi-cluster, tutte queste norme devono fare riferimento alla risorsa ServiceImport e al gruppo API.

Controllo di integrità

Una delle complessità dell'utilizzo di due livelli di bilanciamento del carico L7 è il controllo di integrità. Devi configurare ogni bilanciatore del carico per controllare l'integrità del livello successivo. GKE Gateway controlla l'integrità dei proxy in entrata del mesh e il mesh, a sua volta, controlla l'integrità dei backend dell'applicazione.

  • Ingresso cloud: in questa architettura di riferimento, configuri il bilanciatore del caricoGoogle Cloud tramite GKE Gateway per controllare l'integrità dei proxy di ingresso mesh sulle porte di controllo di integrità esposte. Se un proxy mesh non è attivo o se il cluster, la mesh o la regione non sono disponibili, il Google Cloud bilanciatore del carico rileva questa condizione e non invia traffico al proxy mesh. In questo caso, il traffico verrà indirizzato a un proxy mesh alternativo in un cluster o una regione GKE diversi.
  • Ingresso mesh: nell'applicazione mesh, esegui controlli di integrità sui backend direttamente in modo da poter eseguire il bilanciamento del carico e la gestione del traffico localmente.

Considerazioni sulla progettazione

Questa sezione fornisce indicazioni per aiutarti a utilizzare questa architettura di riferimento per sviluppare un'architettura che soddisfi i tuoi requisiti specifici di sicurezza e conformità, affidabilità e costi.

Sicurezza, privacy e conformità

Il diagramma dell'architettura in questo documento contiene diversi elementi di sicurezza. Gli elementi più importanti sono la configurazione della crittografia e il deployment dei certificati. GKE Gateway si integra con Certificate Manager per questi scopi di sicurezza.

I client internet si autenticano in base ai certificati pubblici e si connettono al bilanciatore del carico esterno come primo hop in Virtual Private Cloud (VPC). Puoi fare riferimento a un Certificate Manager CertificateMap nella definizione del gateway. L'hop successivo si trova tra Google Front End (GFE) e il proxy di ingresso mesh. Questo hop è criptato per impostazione predefinita.

La crittografia a livello di rete tra i GFE e i relativi backend viene applicata automaticamente. Se i tuoi requisiti di sicurezza prevedono che il proprietario della piattaforma mantenga la proprietà delle chiavi di crittografia, puoi attivare HTTP/2 con crittografia TLS tra il gateway del cluster (GFE) e l'ingresso mesh (l'istanza proxy Envoy).

Quando abiliti HTTP/2 con la crittografia TLS tra il gateway del cluster e l'ingresso mesh, puoi utilizzare un certificato autofirmato o pubblico per criptare il traffico. Puoi utilizzare un certificato autofirmato o pubblico perché GFE non esegue l'autenticazione in base a questo certificato. Questo livello aggiuntivo di crittografia è illustrato nella guida all'implementazione associata a questa architettura di riferimento.

Per evitare la gestione errata dei certificati, non riutilizzare i certificati pubblici. Utilizza certificati separati per ogni bilanciatore del carico nel service mesh.

Per facilitare la creazione di voci DNS esterne e certificati TLS, la guida al deployment per questa architettura di riferimento utilizza Cloud Endpoints. L'utilizzo di Cloud Endpoints consente di creare un sottodominio cloud.goog disponibile esternamente. Negli scenari a livello aziendale, utilizza un nome di dominio più appropriato e crea un record A che rimandi all'indirizzo IP del bilanciatore del carico delle applicazioni globale nel tuo provider di servizi DNS.

Se la mesh di servizi che utilizzi richiede TLS, tutto il traffico tra i proxy sidecar e tutto il traffico in entrata nella mesh viene criptato. Il diagramma dell'architettura mostra la crittografia HTTPS dal client al bilanciatore del carico, dal bilanciatore del carico al proxy di ingresso mesh e dal proxy di ingresso al proxy sidecar. Google Cloud

Affidabilità e resilienza

Un vantaggio fondamentale del pattern edge-to-mesh multicluster e multiregionale è che può utilizzare tutte le funzionalità delmesh di servizih per il bilanciamento del carico est-ovest, come il traffico tra i servizi applicativi.

Questa architettura di riferimento utilizza un gateway GKE multi-cluster per instradare il traffico in entrata di cloud-ingress a un cluster GKE. Il sistema seleziona un cluster GKE in base alla sua vicinanza all'utente (in base alla latenza), alla sua disponibilità e al suo stato. Quando il traffico raggiunge il gateway di ingresso Istio (l'ingresso del mesh), viene indirizzato ai backend appropriati tramite il mesh di servizi.

Un approccio alternativo per la gestione del traffico est-ovest consiste nell'utilizzare servizi multicluster per tutti i servizi applicativi di cui è stato eseguito il deployment nei cluster GKE. Quando utilizzi i servizi multi-cluster nei cluster GKE di un parco risorse, gli endpoint di servizio vengono raccolti in un ClusterSet. Se un servizio deve chiamare un altro servizio, può scegliere qualsiasi endpoint integro per il secondo servizio. Poiché gli endpoint vengono scelti a rotazione, l'endpoint selezionato potrebbe trovarsi in una zona o in una regione diversa.

Un vantaggio fondamentale dell'utilizzo di mesh di servizi per il traffico est-ovest anziché di servizi multicluster è che mesh di servizi può utilizzare il bilanciamento del carico locale. Il bilanciamento del carico locale non è una funzionalità dei servizi multi-cluster, ma puoi configurarla tramite un DestinationRule.

Una volta configurata, una chiamata da un servizio a un altro tenta prima di raggiungere un endpoint di servizio nella stessa zona, poi tenta nella stessa regione del servizio chiamante. Infine, la chiamata ha come target un endpoint in un'altra regione solo se un endpoint di servizio nella stessa zona o nella stessa regione non è disponibile.

Ottimizzazione dei costi

Quando si adotta questa architettura multi-cluster in un'azienda, Cloud Service Mesh e il gateway multi-cluster sono inclusi in Google Kubernetes Engine (GKE) Enterprise. Inoltre, GKE Enterprise include molte funzionalità che ti consentono di gestire e controllare cluster GKE, applicazioni e altri processi su larga scala.

Deployment

Per eseguire il deployment di questa architettura, consulta Da dispositivi periferici a mesh multicluster: esegui il deployment di applicazioni distribuite a livello globale tramite GKE Gateway e Cloud Service Mesh.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: