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 all'esterno 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 su 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 di servizio (SLO) del 99,9% se viene eseguita il deployment in un singolo cluster GKE raggiunge un SLO del 99,9999% se viene eseguita il deployment in due cluster GKE (1 - (0,001)2). Puoi anche offrire agli utenti un'esperienza in cui le richieste in arrivo vengono indirizzate automaticamente al gateway di ingresso mesh meno latente e disponibile.

Se ti interessano i vantaggi dell'esposizione di applicazioni compatibili con il mesh di servizi in esecuzione su un singolo cluster, consulta Da dispositivi periferici a mesh: esposizione delle applicazioni di mesh di servizi mediante GKE Gateway.

Architettura

Il seguente diagramma di architettura mostra come i dati fluiscono attraverso l'ingresso cloud e l'ingresso mesh:

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

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

  • 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 multi-cluster. Il bilanciatore del carico controlla i proxy di ingresso del mesh in più regioni, inviando le richieste al cluster integro più vicino. Implementa inoltre un criterio di sicurezza di Google Cloud Armor.
  • Ingresso nel mesh:nel mesh, esegui i controlli di integrità direttamente sui backend per poter eseguire il bilanciamento del carico e la gestione del traffico localmente.

Quando utilizzi insieme i livelli di ingresso, esistono ruoli complementari per ciascun 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:

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

Ingresso cloud

Se abbinato all'ingresso mesh, il livello di ingresso cloud è ideale per la sicurezza di confine e il bilanciamento del carico globale. Poiché il livello di ingresso cloud è integrato con i seguenti servizi, è ideale per eseguire questi servizi all'edge, all'esterno del 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ù complessa per gli ambienti con più cluster e più regioni.

A causa della funzione critica dei bilanciatori del carico rivolti a internet, il livello di ingresso del cloud è probabilmente gestito da un team della piattaforma che ha il controllo esclusivo sulla 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 mesh di servizi. Il livello fornisce inoltre crittografia mTLS di backend, criteri di autorizzazione e corrispondenza regex flessibile.

Il deployment del bilanciamento del carico delle applicazioni esterno al di fuori del mesh con un livello di ingresso del mesh offre vantaggi significativi, in particolare per la gestione del traffico internet. Sebbene mesh di servizi 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 l'Application Load Balancer esterno di Google Cloud potrebbe offrire vantaggi significativi 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.
  • Fleet e gateway multi-cluster: servizi utilizzati per creare applicazioni containerizzate su larga scala per le aziende 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 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 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 le difficoltà di gestione dei cluster, utilizza il principio di identità dello spazio dei nomi del parco risorse. Per ogni cluster GKE in un fleet, assicurati di configurare tutti i gateway di ingresso del mesh nello stesso modo.

Inoltre, esegui il deployment dei servizi di applicazione in modo coerente in modo che il servizio balance-reader nell'account dello spazio dei nomi si riferisca a un servizio identico in ogni cluster GKE nel parco. I principi di identità e fiducia che vengono assunti all'interno di un parco risorse ti 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 nel livello di ingresso del mesh. Il livello di ingresso del mesh viene implementato su ogni cluster GKE nel parco risorse. Configura ogni gateway di ingresso del mesh nello stesso modo, rispettando il principio di identità dello spazio dei nomi del parco risorse.

Sebbene esista un unico cluster di configurazione per GKE Gateway, devi sincronizzare le configurazioni di GKE Gateway su 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 siano sincronizzate su tutti i cluster GKE del parco risorse e aiuta a evitare la riconciliazione con una configurazione non aggiornata.

Gateway di ingresso del mesh

Istio 0.8 ha introdotto il gateway di ingresso della rete 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 alla rete separatamente dal comportamento di routing delle applicazioni.

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 utilizza Cloud Load Balancing, il cui provisioning viene eseguito tramite le risorse gateway GKE.

Servizi GKE Gateway e multi-cluster

Esistono molti modi per fornire l'accesso alle applicazioni ai client esterni al cluster. GKE Gateway è un'implementazione dell'API Kubernetes Gateway. GKE Gateway 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 Cloud Load Balancing per implementare il comportamento di rete 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 sono distribuiti su più cluster GKE (nello stesso parco risorse).
  • Lo stato dei client (esterni o interni).
  • Le funzionalità richieste del bilanciatore del carico, inclusa la possibilità di integrarsi con i criteri di sicurezza di Google Cloud Armor.
  • I requisiti di copertura del mesh di servizi. 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 esternamente 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.

Ingress multi-cluster si basa sulla creazione di risorse MultiClusterService. 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 di criteri hanno come target i servizi di backend nel parco risorse esposti su più cluster. In scenari multi-cluster, tutti questi criteri devono fare riferimento al gruppo di risorse e API ServiceImport.

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. GKE Gateway controlla l'integrità dei proxy di ingresso 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 carico Google Cloud tramite GKE Gateway per verificare 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 sono disponibili, il bilanciatore del carico di 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 del mesh: nell'applicazione mesh, esegui i controlli di integrità direttamente sui backend in modo da poter eseguire il bilanciamento del carico e la gestione del traffico localmente.

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 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). Puoi fare riferimento a un gestore dei certificati CertificateMap nella definizione del gateway. L'hop successivo si trova tra Google Front End (GFE) e il proxy di ingresso del 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 del mesh (l'istanza del proxy envoy).

Quando attivi HTTP/2 con crittografia TLS tra il gateway del cluster e l'ingresso del 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. 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 servizio mesh.

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

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

Affidabilità e resilienza

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

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 selezione un cluster GKE in base alla sua vicinanza all'utente (in base alla latenza), nonché 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 gestire il traffico est-ovest è tramite i servizi multi-cluster per tutti i servizi di applicazioni di cui è stato eseguito il deployment nei cluster GKE. Quando utilizzi servizi multi-cluster in cluster GKE in un parco risorse, gli endpoint dei servizi vengono raccolti in un ClusterSet. Se un servizio deve chiamare un altro servizio, può avere come target qualsiasi endpoint funzionante per il secondo servizio. Poiché gli endpoint vengono scelti su base alternata, l'endpoint selezionato potrebbe trovarsi in una zona o in una regione diversa.

Un vantaggio chiave dell'utilizzo di mesh di servizi per il traffico est-ovest anziché di servizi multi-cluster è che mesh di servizi 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.

Una volta configurata, una chiamata da un servizio a un altro tenta prima di raggiungere un endpoint del servizio nella stessa zona, quindi 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 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: