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 delle applicazioni esternamente tramite gateway Google Kubernetes Engine (GKE) in esecuzione su di cluster GKE all'interno di un mesh di servizi. Questa guida è destinata a Google Workspace for Education.

Puoi aumentare la resilienza e la ridondanza dei tuoi servizi eseguendo il deployment in modo coerente su più cluster GKE, dove ogni cluster diventa un altro dominio in errore. Ad esempio, l'infrastruttura di computing di un servizio con un servizio dell'obiettivo di livello (SLO) del 99,9% quando viene eseguito il deployment in un singolo cluster GKE raggiunge uno SLO del 99,9999% quando viene eseguito il deployment tra due cluster GKE (1 - (0,001)2). Puoi anche offrire agli utenti un'esperienza in cui le richieste in entrata vengono indirizzate automaticamente alle richieste meno latenti e disponibili gateway in entrata mesh.

Se vuoi conoscere i vantaggi dell'esposizione per le applicazioni abilitate per mesh di servizi eseguite su un singolo cluster, vedi Da perimetrale al mesh: esponi le applicazioni mesh di servizi attraverso il gateway GKE.

Architettura

Il seguente diagramma dell'architettura mostra come fluiscono i dati attraverso il traffico in entrata nel cloud e in entrata mesh:

Crittografia TLS dal client, da un bilanciatore del carico e dalla rete 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 Google Cloud al proxy in entrata mesh utilizzando il proprio certificato TLS autofirmato.
  • Dal proxy gateway di ingresso del mesh ai proxy sidecar del carico di lavoro utilizzando mTLS abilitato per il mesh di servizi.

Questa architettura di riferimento contiene i seguenti due livelli in entrata:

  • In entrata nel cloud: in questa architettura di riferimento viene utilizzato API Kubernetes Gateway (e Controller gateway GKE) per programmare il livello di bilanciamento del carico HTTP(S) multi-cluster esterno. La il bilanciatore del carico controlla i proxy in entrata della rete mesh regioni, inviando richieste al cluster integro più vicino. Inoltre, implementa un Google Cloud Armor criteri di sicurezza.
  • Ingresso mesh:nel mesh vengono eseguiti controlli di integrità sui backend. per poter eseguire il bilanciamento del carico e la gestione del traffico a livello locale.

Quando utilizzi insieme i livelli in entrata, esistono ruoli complementari per 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 del mesh:

  • Offri una bassa latenza.
  • Aumenta la disponibilità.
  • Utilizza le funzionalità di sicurezza del livello Cloud Ingress.
  • Utilizza le funzionalità di sicurezza, autorizzazione e osservabilità del livello di ingresso del mesh.

Ingress nel cloud

Se abbinato al traffico mesh in entrata, il traffico in entrata nel cloud è la soluzione ideale per la sicurezza perimetrale e il bilanciamento del carico globale. Poiché il livello Cloud Ingress è integrato con i seguenti servizi ed eccelle in che eseguono questi servizi a livello perimetrale, fuori dal mesh:

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

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

Data la funzione fondamentale dei bilanciatori del carico per internet, Cloud Ingress è probabilmente gestito da un team della piattaforma che ha controllo delle modalità di esposizione e protezione delle applicazioni su internet. Questo controllo rende questo livello meno flessibile e dinamico rispetto a un'infrastruttura basata sugli sviluppatori. Prendi in considerazione questi fattori quando determini i diritti di accesso amministrativo a questo livello e la modalità di assegnazione di questo accesso.

Ingresso mesh

Se accoppiato all'ingresso cloud, il livello di ingresso del mesh fornisce un punto di contatto per il traffico che deve entrare nel service mesh. Il livello fornisce anche mTLS backend, criteri di autorizzazione e corrispondenza flessibile con espressioni regolari.

Deployment del bilanciamento del carico di applicazioni esterne al di fuori del mesh con una rete mesh Il livello in entrata offre vantaggi significativi, soprattutto per il traffico internet gestione dei dispositivi. Sebbene il service mesh e i gateway di ingresso Istio forniscano 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 di Google Cloud potrebbe offrire significativi vantaggi in termini di prestazioni, affidabilità o sicurezza rispetto all'ingresso basato su mesh.

Prodotti e funzionalità utilizzati

Il seguente elenco riassume tutti i prodotti e le funzionalità di 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.
  • Parchi risorse e Gateway multi-cluster: Servizi utilizzati per creare applicazioni containerizzate a livello aziendale la scalabilità usando 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 da denial of service e attacchi web.
  • Cloud Service Mesh: Un mesh di servizi completamente gestiti 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 ti consente di acquisire e gestire i certificati TLS da utilizzare con Cloud Load Balancing.

Parchi risorse

Per gestire i deployment multi-cluster, GKE Enterprise e Google Cloud usano i parchi risorse per raggruppare e normalizzare logicamente cluster.

L'utilizzo di uno o più parchi risorse può aiutarti a migliorare la gestione a interi gruppi di cluster. Per ridurre le difficoltà di gestione, usano il principio dell'identicità dello spazio dei nomi del parco risorse. Per ogni cluster GKE assicurati di configurare tutti i gateway in entrata mesh allo stesso modo.

Inoltre, esegui regolarmente il deployment dei servizi delle applicazioni saldo-lettore nell'account dello spazio dei nomi è correlato a un servizio identico in ogni cluster GKE nel parco risorse. I principi di uguaglianza e fiducia che si presume che all'interno di un parco risorse siano disponibili 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 nel livello di ingresso del mesh. Il livello di ingresso del mesh viene dispiegato su ogni cluster GKE nel parco risorse. Configura ogni gateway mesh in entrata nello stesso aderendo al principio dell'identicità dello spazio dei nomi del parco risorse.

Sebbene esista un unico cluster di configurazione Gateway GKE devi sincronizzare le configurazioni del gateway GKE in tutti i cluster GKE del parco risorse.

Se devi nominare un nuovo cluster di configurazione, usa ConfigSync. ConfigSync contribuisce a garantire che tutte queste configurazioni siano sincronizzate su tutti i cluster GKE del parco risorse e aiuta a evitare la riconciliazione con una configurazione non aggiornata.

Gateway mesh in entrata

Istio 0.8 ha introdotto il gateway di ingresso della rete mesh. 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 controllo del comportamento dell'esposizione della rete separatamente dal routing delle applicazioni comportamento degli utenti.

I proxy ti consentono inoltre di applicare il routing e i criteri al traffico esterno al mesh prima che arrivi a un sidecar dell'applicazione. L'ingresso del 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 il traffico esterno, devi avere un bilanciatore del carico esterno al mesh. Per automatizzare il deployment, questa architettura di riferimento usa Cloud Load Balancing, di cui viene eseguito il provisioning tramite GKE delle risorse del gateway.

Servizi GKE Gateway e multi-cluster

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

Quando esegui il deployment delle risorse GKE Gateway nel tuo cluster GKE, il controller Gateway monitora le risorse dell'API Gateway. Il controller riconcilia le risorse di bilanciamento del carico Cloud per implementare il comportamento di rete specificato dalle risorse gateway.

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:

  • Se i servizi di backend si trovano in un singolo cluster GKE o sono distribuiti su più cluster GKE (nello stesso parco risorse).
  • 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 estensione del service mesh. Le mesh di servizi possono essere distribuite su più cluster GKE o essere contenute in un singolo cluster.

In Gateway, questo comportamento è controllato specificando la GatewayClass appropriata. Quando si fa riferimento alle classi Gateway, quelle che possono essere utilizzate in scenari multi-cluster hanno un nome che termina con -mc.

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

Per eseguire il deployment di servizi di applicazioni in scenari multi-cluster, puoi definire i componenti del bilanciatore del carico Google Cloud nei seguenti due modi:

Per ulteriori informazioni su questi due approcci per il deployment dei servizi di applicazioni, consulta Scegliere l'API di bilanciamento del carico multi-cluster per GKE.

L'Ingress multi-cluster si basa sulla creazione MultiClusterService Google Cloud. La risorsa Gateway multi-cluster si basa sulla creazione di risorse ServiceExport e sul riferimento alle risorse ServiceImport.

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

Queste risorse dei criteri hanno come target i servizi di backend nel parco risorse che sono esposti in più cluster. In scenari multi-cluster, tutti questi criteri deve fare riferimento ServiceImport gruppo di risorse e API.

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. La Il gateway GKE controlla l'integrità del traffico mesh in entrata e il mesh controlla in cambio l'integrità dell'applicazione di backend.

  • Ingresso cloud: in questa architettura di riferimento, configuri il bilanciatore del carico Google Cloud tramite GKE Gateway per controllare l'integrità dei proxy di ingresso del mesh sulle relative porte di controllo dell'integrità esposte. Se un proxy mesh non è attivo 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. In questo caso, il traffico verrà indirizzato a un proxy mesh alternativo in un cluster o una regione GKE diversa.
  • Ingresso mesh: nell'applicazione mesh, vengono eseguiti i controlli di integrità direttamente i backend in modo da eseguire il bilanciamento del carico e il traffico a livello locale.

Note sul layout

Questa sezione fornisce indicazioni per aiutarti a utilizzare questa architettura di riferimento per sviluppare un'architettura che soddisfi i tuoi requisiti specifici in termini di sicurezza, 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 il modo in cui configuri la crittografia e implementi i certificati. GKE Gateway si integra con Certificate Manager per queste finalità di sicurezza.

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). Tu può fare riferimento a un gestore dei certificati CertificateMap nella definizione di gateway. L'hop successivo è tra Google Front End (GFE) e il proxy in entrata della rete mesh. Questo hop è criptati 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 del mesh (l'istanza del proxy envoy).

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

Per evitare il maltrattamento dei certificati, non riutilizzare i certificati pubblici certificati. Utilizza certificati separati per ogni bilanciatore del carico nel servizio mesh.

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

Se il service mesh che utilizzi richiede TLS, tutto il traffico tra i proxy sidecar e tutto il traffico all'ingresso del mesh viene criptato. L'architettura che mostra la crittografia HTTPS dal client al carico di Google Cloud dal bilanciatore del carico al proxy in entrata della rete mesh e dal traffico in entrata proxy al proxy sidecar.

Affidabilità e resilienza

Un vantaggio chiave del pattern edge-to-mesh multi-cluster e multiregionale è che può utilizzare tutte le funzionalità del mesh di servizi per il carico est-ovest come il traffico tra i servizi delle applicazioni.

Questa architettura di riferimento utilizza un gateway GKE multi-cluster per instradare il traffico in entrata del cloud a un cluster GKE. Il sistema seleziona un cluster GKE in base alla sua vicinanza all'utente (in base alla latenza), nonché la sua disponibilità e l'integrità. 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 da est a ovest è attraverso servizi multi-cluster per tutti i servizi per applicazioni di cui è stato eseguito il deployment in cluster GKE. Quando utilizzi servizi multi-cluster nei cluster GKE in una di un parco risorse, gli endpoint di servizio sono raccolti ClusterSet Se un servizio deve chiamare un altro servizio, può scegliere come target qualsiasi per il secondo servizio. Poiché gli endpoint vengono scelti su un l'endpoint selezionato potrebbe trovarsi in una zona o una regione diversa.

Un vantaggio chiave dell'utilizzo di service mesh per il traffico est-ovest anziché di servizi multi-cluster è che service mesh può utilizzare il bilanciamento del carico a livello di località. Il bilanciamento del carico per le località non è una funzionalità dei servizi multi-cluster, ma puoi configurarlo tramite un DestinationRule.

Dopo la configurazione, una chiamata da un servizio all'altro prova prima a raggiungere un di servizio nella stessa zona, quindi prova nella stessa regione di chiamata. 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 viene adottata questa architettura multi-cluster in un'azienda, Cloud Service Mesh e il gateway multi-cluster sono inclusi nella versione Enterprise di Google Kubernetes Engine (GKE). Inoltre, GKE Enterprise include molte funzionalità che ti consentono di gestire e governare cluster, applicazioni e altri processi GKE su larga scala.

Deployment

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

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: