Da mesh perimetrale a multi-cluster: applicazioni distribuite a livello globale esposte tramite il gateway GKE 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, 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 in entrata mesh ai proxy sidecar dei carichi di lavoro utilizzando il protocollo mTLS abilitato per 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 li utilizzi insieme, ci sono ruoli complementari per per ogni livello. Per raggiungere i seguenti obiettivi, Google Cloud ottimizza le funzionalità più appropriate il livello in entrata nel cloud e il livello in entrata mesh:

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

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 traffico in entrata nel 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 rende questo livello meno flessibile e dinamico rispetto a un dell'infrastruttura. Prendi in considerazione questi fattori quando determini l'accesso amministrativo diritti su questo livello e come fornisci tale accesso.

Ingresso mesh

Se accoppiato al cloud in entrata, il livello mesh fornisce un punto di ingresso. che il traffico entri nel mesh di servizi. 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 mesh di servizi e i gateway in entrata Istio forniscano 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 prestazioni vantaggi legati all'affidabilità o alla sicurezza rispetto al traffico in entrata basato su mesh.

Prodotti e funzionalità utilizzati

L'elenco seguente riassume tutti i prodotti e utilizzate da questa architettura di riferimento:

  • GKE Enterprise Un servizio Kubernetes gestito che puoi utilizzare per il deployment e il funzionamento delle applicazioni containerizzate su larga scala utilizzando l'infrastruttura di Google. Per scopo di questa architettura di riferimento, ogni cluster GKE 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.
  • Gestore certificati: Un servizio che consente di acquisire e gestire i certificati TLS da utilizzare con e 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-reader 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 sono gestite a livello di traffico mesh. Il livello di traffico mesh in entrata viene implementato 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 ad assicurare che tutte queste configurazioni siano sincronizzate tra tutti GKE nel parco risorse e aiuta a evitare la riconciliazione con un configurazione.

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 controllo del comportamento dell'esposizione della rete separatamente dal routing delle applicazioni comportamento degli utenti.

I proxy consentono anche di applicare routing e criteri al traffico esterno mesh prima che arrivi a un file collaterale dell'applicazione. Il traffico mesh in entrata definisce il gruppo sperimentale di traffico quando raggiunge un nodo nel mesh, ma i componenti esterni devono definiscono in che modo il traffico arriva per la prima volta al mesh.

Per gestire il traffico esterno, è necessario un bilanciatore del carico esterno 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.

Gateway GKE e servizi multi-cluster

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

Quando esegui il deployment delle risorse del gateway GKE Cluster GKE, il controller Gateway controlla le risorse dell'API Gateway. Il controller riconcilia le risorse di Cloud Load Balancing per implementare il comportamento di rete specificato dalle risorse del 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 distribuiti in 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 copertura del mesh di servizi. I mesh di servizi possono estendersi in più cluster GKE o possono essere contenuti in un unico cluster.

In Gateway, questo comportamento è controllato specificando l'appropriata GatewayClass. Quando fai riferimento alle classi Gateway, le classi che possono essere utilizzate gli scenari multi-cluster hanno un nome di classe 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 Puoi anche creare un bilanciatore del carico delle applicazioni interno a livello di regione multi-cluster.

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

Per ulteriori informazioni su questi due approcci al deployment vedi i servizi, vedi Scegli l'API di bilanciamento del carico multi-cluster per GKE.

L'Ingress multi-cluster si basa sulla creazione MultiClusterService Google Cloud. Il gateway multi-cluster si basa sulla creazione ServiceExport e fare riferimento ServiceImport Google Cloud.

Quando utilizzi un gateway multi-cluster, puoi abilitare l'abilitazione del bilanciatore del carico di Google Cloud sottostante creando Norme. La guida al deployment associata a questa architettura di riferimento mostra come configurare un criterio di sicurezza di Google Cloud Armor per proteggere i servizi di backend 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à

Una complessità dell'utilizzo di due livelli del bilanciamento del carico L7 è il controllo di integrità. Tu e configurare ciascun 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.

  • In entrata nel cloud: in questa architettura di riferimento, configuri il Bilanciatore del carico Google Cloud tramite il gateway GKE per controllare l'integrità dei proxy in entrata della rete mesh sulla loro integrità esposta e controlla le porte. 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 verrebbe generato instradato a un proxy mesh alternativo in un'altra regione o cluster GKE.
  • 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.

Note sul layout

Questa sezione fornisce indicazioni per aiutarti a utilizzare questa architettura di riferimento per: 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 presentato in questo documento contiene diversi elementi di sicurezza. Gli elementi più critici sono la configurazione della crittografia e il deployment certificati. Il gateway GKE si integra con Gestione certificati per motivi di sicurezza.

I client internet eseguono l'autenticazione su certificati pubblici e si connettono 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.

Viene applicata la crittografia a livello di rete tra i GFE e i relativi backend automaticamente. Se i tuoi requisiti di sicurezza stabiliscono che il proprietario della piattaforma mantengono la proprietà delle chiavi di crittografia, puoi abilitare HTTP/2 con TLS crittografia tra il gateway del cluster (GFE) e il mesh in entrata (l'envoy un'istanza proxy).

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 al deployment. associati 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 nel tuo provider di servizi DNS.

Se il mesh di servizi che stai utilizzando richiede TLS, tutto il traffico tra file collaterali e tutto il traffico verso il mesh in entrata è 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 cluster GKE multi-cluster Gateway per instradare il traffico in entrata nel cloud in entrata a un cluster GKE. Il sistema seleziona un cluster GKE in base alla sua vicinanza all'utente (in base alla latenza), nonché la relativa disponibilità e integrità. Quando il traffico raggiunge il gateway in entrata Istio (il mesh in entrata), viene indirizzato ai backend appropriati attraverso 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 fondamentale dell'utilizzo di mesh di servizi per il traffico da est a ovest anziché multi-cluster è che il mesh di servizi può utilizzare il bilanciamento del carico per località. Il bilanciamento del carico per le località non è una funzionalità dei servizi multi-cluster, puoi configurarlo tramite 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 non è disponibile un endpoint di servizio nella stessa zona o nella stessa regione.

Ottimizzazione dei costi

Quando adotti questa architettura multi-cluster in modo più ampio in un'intera azienda, Cloud Service Mesh e Gateway multi-cluster sono inclusi in Versione Google Kubernetes Engine (GKE) Enterprise. Inoltre, GKE Enterprise include molte funzionalità che abilitano che ti permette di gestire e gestire i cluster GKE, le applicazioni e altri processi su larga scala.

Deployment

Per eseguire il deployment di questa architettura, Dal mesh perimetrale al mesh multi-cluster: esegui il deployment di applicazioni distribuite a livello globale tramite il gateway GKE e Cloud Service Mesh.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: