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 è destinata agli amministratori delle piattaforme.
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 computing di un servizio con un obiettivo del livello di servizio (SLO) del 99,9% quando viene eseguito il deployment in un singolo cluster GKE raggiunge un SLO del 99,9999% quando viene eseguito il deployment su due cluster GKE (1 - (0,001)2). Puoi anche fornire agli utenti un'esperienza in cui le richieste in entrata vengono indirizzate automaticamente al gateway in entrata del mesh con la latenza più bassa e disponibile.
Se ti interessano i vantaggi dell'esposizione delle applicazioni abilitate per 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 dell'architettura mostra il flusso dei dati attraverso il traffico in entrata nel cloud e nel mesh:
Il diagramma precedente mostra i seguenti scenari di flusso di dati:
- Dal client che termina al Google Cloud bilanciatore del carico utilizzando il proprio certificato TLS gestito da Google.
- Dal Google Cloud bilanciatore del carico al proxy in entrata del mesh utilizzando il proprio certificato TLS autofirmato.
- Dal proxy del gateway in entrata 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 traffico in entrata:
- Traffico in entrata nel cloud: in questa architettura di riferimento, utilizzi l' API Gateway di Kubernetes (e il controller Gateway GKE) per programmare il livello di bilanciamento del carico HTTP(S) esterno e multi-cluster. Il bilanciatore del carico controlla i proxy in entrata del mesh in più regioni, inviando le richieste al cluster integro più vicino. Implementa anche una policy di sicurezza di Google Cloud Armor.
- Traffico in entrata nel mesh:nel mesh, esegui i controlli di integrità sui backend direttamente in modo da poter eseguire il bilanciamento del carico e la gestione del traffico localmente.
Quando utilizzi i livelli di traffico in entrata insieme, ogni livello ha ruoli complementari. Per raggiungere i seguenti obiettivi, Google Cloud ottimizza le funzionalità più appropriate del livello di traffico in entrata nel cloud e del livello di traffico in entrata nel mesh:
- Fornisci una bassa latenza.
- Aumenta la disponibilità.
- Utilizza le funzionalità di sicurezza del livello di traffico in entrata nel cloud.
- Utilizza le funzionalità di sicurezza, autorizzazione e osservabilità del livello di traffico in entrata nel mesh.
Traffico in entrata nel cloud
Se abbinato al traffico in entrata nel mesh, il livello di traffico in entrata nel cloud è ideale per la sicurezza perimetrale e il bilanciamento del carico globale. Poiché il livello di traffico in entrata nel cloud è integrato con i seguenti servizi, è ideale per l'esecuzione di questi servizi al perimetro, 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 traffico in entrata nel cloud. Tuttavia, può essere più complessa per gli ambienti multi-cluster e multi-regionali.
A causa della funzione critica dei bilanciatori del carico con accesso a internet, è probabile che il livello di traffico in entrata nel cloud sia 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 basata sugli sviluppatori. Tieni conto di questi fattori quando determini i diritti di accesso amministrativo a questo livello e come fornisci questo accesso.
Traffico in entrata nel mesh
Se abbinato al traffico in entrata nel cloud, il livello di traffico in entrata nel mesh fornisce un punto di ingresso per il traffico nel mesh di servizi. Il livello fornisce anche mTLS del backend, policy di autorizzazione e corrispondenza di espressioni regolari flessibili.
L'esecuzione del deployment del bilanciamento del carico delle applicazioni esterno al di fuori del mesh con un livello di traffico in entrata nel mesh offre vantaggi significativi, soprattutto per la gestione del traffico internet. Sebbene i mesh di servizi e i gateway in entrata di Istio forniscano routing e gestione del traffico avanzati nel mesh, alcune funzioni sono più adatte al perimetro della rete. Sfruttare il networking perimetrale di internet tramite Google Cloud's bilanciatore del carico delle applicazioni esterno di potrebbe offrire vantaggi significativi in termini di prestazioni, affidabilità o sicurezza rispetto al traffico in entrata basato su mesh.
Prodotti e funzionalità utilizzati
Il seguente elenco riassume tutti i Google Cloud prodotti e le funzionalità utilizzati da questa architettura di riferimento:
- GKE: un servizio Kubernetes gestito che consente di eseguire il deployment e gestire applicazioni containerizzate su larga scala utilizzando l'infrastruttura di Google. Ai fini di questa architettura di riferimento, tutti i cluster GKE che gestiscono un'applicazione devono trovarsi nello stesso parco risorse.
- Parchi risorse e gateway multi-cluster: servizi utilizzati per creare applicazioni containerizzate su scala aziendale utilizzando l'infrastruttura di Google e GKE.
- Google Cloud Armor: Un servizio che ti aiuta a proteggere le applicazioni e i siti web da attacchi Denial of Service e web.
- Cloud Service Mesh: un mesh di servizi completamente gestito basato su Envoy e Istio
- Bilanciatore del carico delle applicazioni: Un bilanciatore del carico di livello 7 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 e Google Cloud utilizza i parchi risorse per raggruppare e normalizzare logicamente 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 uguaglianza dello spazio dei nomi del parco risorse. Per ogni cluster GKE in un parco risorse, assicurati di configurare tutti i gateway in entrata del mesh nello stesso modo.
Inoltre, esegui il deployment dei servizi applicativi in modo coerente in modo che il lettore del saldo del servizio nell'account dello spazio dei nomi sia correlato a un servizio identico in ogni cluster GKE del parco risorse. I principi di uguaglianza e attendibilità che si presuppongono all'interno di un parco risorse ti consentono di utilizzare l'intera gamma di funzionalità abilitate per il parco risorse in GKE e Google Cloud.
Le regole di routing est-ovest all'interno del mesh di servizi e le policy di traffico vengono gestite a livello di traffico in entrata nel mesh. Il livello di traffico in entrata nel mesh viene eseguito il deployment su ogni cluster GKE del parco risorse. Configura ogni gateway in entrata del mesh nello stesso modo, rispettando il principio di uguaglianza dello spazio dei nomi del parco risorse.
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 ti aiuta a garantire che tutte queste configurazioni siano sincronizzate in tutti i cluster GKE del parco risorse e a evitare la riconciliazione con una configurazione non corrente.
Gateway in entrata del mesh
Istio 0.8 ha introdotto il gateway in entrata del 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 del mesh ti consentono di controllare il comportamento di esposizione della rete separatamente dal comportamento di routing delle applicazioni.
I proxy ti consentono anche di applicare routing e policy 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 nel mesh, ma i componenti esterni devono definire come il traffico arriva per la prima volta al 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 GKE Gateway.
GKE Gateway e servizi multi-cluster
Esistono molti modi per fornire l'accesso alle applicazioni ai client esterni al cluster. GKE Gateway è un'implementazione dell' API Gateway di Kubernetes. GKE Gateway evolve e migliora la risorsa Ingress.
Quando esegui il deployment delle risorse GKE Gateway nel cluster GKE, il controller Gateway osserva le risorse dell'API Gateway. Il controller riconcilia le risorse 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 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 funzionalità di integrazione con le policy di sicurezza di Cloud Armor.
- I requisiti di spanning del mesh di servizi. I mesh di servizi possono estendersi su più cluster GKE o essere contenuti 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 di classe che termina con -mc.
Questa architettura di riferimento descrive 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 multi-cluster.
Per eseguire il deployment dei servizi applicativi in scenari multi-cluster, puoi definire i Google Cloud componenti del bilanciatore del carico in due modi:
Per saperne di più su questi due approcci al deployment dei servizi applicativi, consulta Scegli l'API di bilanciamento del carico multi-cluster per GKE.
Ingress multi-cluster si basa sulla creazione di
MultiClusterService
risorse. Il gateway multi-cluster si basa sulla creazione di
ServiceExport
risorse e sul riferimento a
ServiceImport
risorse.
Quando utilizzi un gateway multi-cluster, puoi abilitare 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 di Google Cloud Armor per proteggere i servizi di backend da script cross-site.
Queste risorse di policy hanno come target i servizi di backend nel parco risorse esposti su più cluster. Negli scenari multi-cluster, tutte queste policy
devono fare riferimento alla
ServiceImport risorsa e al gruppo API.
Controllo di integrità
Una delle complessità dell'utilizzo di due livelli di bilanciamento del carico di livello 7 è 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.
- Traffico in entrata nel cloud: in questa architettura di riferimento, configuri il Google Cloud bilanciatore del carico tramite GKE Gateway per controllare l'integrità dei proxy in entrata del mesh sulle porte di controllo di integrità esposte. Se un proxy del mesh non è attivo o se il cluster, il mesh o la regione non sono disponibili, il Google Cloud bilanciatore del carico rileva questa condizione e non invia traffico al proxy del mesh. In questo caso, il traffico verrebbe indirizzato a un proxy del mesh alternativo in un cluster GKE o in una regione diversa.
- Traffico in entrata nel mesh: nell'applicazione mesh, esegui i controlli di integrità sui backend direttamente 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 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 con i 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 è tra Google Front End (GFE) e il proxy in entrata 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 requisiti di sicurezza impongono che il proprietario della piattaforma mantenga la proprietà delle chiavi di crittografia, puoi abilitare HTTP/2 con la crittografia TLS tra il gateway del cluster (il GFE) e l'ingresso del mesh (l'istanza del proxy Envoy).
Quando abiliti HTTP/2 con la crittografia TLS tra il gateway del cluster e il traffico in entrata del mesh, puoi utilizzare un certificato autofirmato o pubblico per criptare il 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 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 mesh di servizi.
Per creare voci DNS esterne e certificati TLS, la guida al deployment
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 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 il mesh di servizi che utilizzi richiede TLS, tutto il traffico tra i proxy sidecar e tutto il traffico in entrata nel mesh viene criptato. Il diagramma dell'architettura mostra la crittografia HTTPS dal client al Google Cloud bilanciatore del carico, dal bilanciatore del carico al proxy in entrata del mesh e dal proxy in entrata al proxy sidecar.
Affidabilità e resilienza
Un vantaggio fondamentale del pattern multi-cluster e multi-regionale da edge a mesh è che può utilizzare tutte le funzionalità del mesh di servizi 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 indirizzare il traffico in entrata nel cloud 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 alla sua integrità. Quando il traffico raggiunge il gateway in entrata di Istio (il traffico in entrata nel mesh), viene indirizzato ai backend appropriati tramite il mesh di servizi.
Un approccio alternativo per la gestione del traffico est-ovest è tramite i servizi multi-cluster per tutti i servizi applicativi di cui è stato eseguito il deployment nei cluster GKE. Quando utilizzi i servizi multi-cluster nei cluster GKE in un
parco risorse, gli endpoint di servizio vengono raccolti in un
ClusterSet.
Se un servizio deve chiamare un altro servizio, può scegliere come target 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 del mesh di servizi per il traffico est-ovest anziché dei servizi multi-cluster è che il mesh di servizi può utilizzare il bilanciamento del carico di località.
Il bilanciamento del carico di 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 di servizio nella stessa zona, quindi 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.
Deployment
Per eseguire il deployment di questa architettura, consulta Da edge a mesh multi-cluster: esecuzione del deployment di applicazioni distribuite a livello globale tramite GKE Gateway e Cloud Service Mesh.
Passaggi successivi
- Scopri di più sulle funzionalità offerte da GKE Gateway che puoi utilizzare con il mesh di servizi.
- Scopri di più su i diversi tipi di Cloud Load Balancing disponibili per GKE.
- Scopri di più sulle funzionalità offerte da Cloud Service Mesh.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.
Collaboratori
Autori:
- Alex Mattson | Application Specialist Engineer
- Mark Chilvers | Application Specialist Engineer
Altri collaboratori:
- Abdelfettah Sghiouar | Cloud Developer Advocate
- Arunkumar Jayaraman | Principal Engineer
- Greg Bray | Customer Engineer
- Megan Yahya | Product Manager
- Paul Revello | Cloud Solutions Architect
- Valavan Rajakumar | Key Enterprise Architect
- Maridi (Raju) Makaraju | Supportability Tech Lead