Sebbene sia generalmente una best practice utilizzare il minor numero possibile di cluster, le organizzazioni scelgono di eseguire il deployment di più cluster per raggiungere i propri obiettivi tecnici e aziendali per una serie di motivi. Come minimo, la maggior parte delle organizzazioni separa i propri servizi non di produzione dai servizi di produzione posizionandoli in cluster diversi. In scenari più complessi, le organizzazioni potrebbero scegliere più cluster per separare i servizi tra livelli, impostazioni internazionali, team o provider di infrastruttura.
La maggior parte dei motivi per l'adozione di più cluster rientra in tre categorie di requisiti:
- Isolamento: separazione del piano di controllo dal piano dati dei servizi, principalmente per migliorare l'affidabilità o far fronte alle esigenze di sicurezza
- Località: posiziona i servizi in località specifiche per soddisfare le esigenze di disponibilità, latenza e località
- Scalabilità: soprattutto nel contesto dei cluster Kubernetes, tramite la scalabilità dei servizi oltre i limiti pratici imposti da un singolo cluster
Li analizzeremo in dettaglio nelle sezioni seguenti.
In molti casi, le organizzazioni devono bilanciare diversi di questi requisiti contemporaneamente. Se pensi alla tua organizzazione, ricorda che il nostro consiglio generale è quello di utilizzare il minor numero possibile di cluster. Determina quali esigenze multi-cluster hanno la priorità più alta per la tua organizzazione e che non possono essere compromesse, quindi apporta i compromessi appropriati per creare un'architettura multi-cluster.
Se la tua organizzazione prende in considerazione un cluster per modello di servizio o una modalità cluster per team, dovresti prendere in considerazione il carico di gestione imposto agli operatori di un sistema di questo tipo. I parchi risorse e i componenti e le funzionalità di Google Cloud che li supportano si adoperano per semplificare il più possibile la gestione di più cluster, ma c'è sempre una certa complessità di gestione aggiuntiva con più cluster.
Isolamento
In questo contesto, per isolamento si intende la separazione del piano di controllo e/o del piano dati, entrambi raggiungibili eseguendo più cluster. Tuttavia, a seconda dell'implementazione, questa separazione probabilmente si estende anche all'isolamento del piano dati. L'isolamento di solito si verifica quando si considera quanto segue:
Ambiente
Molto spesso le organizzazioni eseguono i propri servizi di sviluppo, gestione temporanea/test e produzione su cluster separati, spesso in esecuzione su reti e progetti cloud diversi. Questa separazione viene effettuata per evitare interruzioni accidentali dei servizi di produzione e per impedire l'accesso a dati sensibili durante lo sviluppo o i test.Livelli di carico di lavoro
Spesso le organizzazioni con molte applicazioni complesse pianificano i propri servizi, scegliendo di eseguire i servizi più critici su cluster separati da quelli meno critici. In un ambiente di questo tipo, questi servizi più critici e i relativi cluster vengono trattati con particolare attenzione ad accesso, sicurezza, upgrade, criteri e altro ancora. Un esempio di questa suddivisione in livelli è la separazione dei servizi stateless e stateful posizionandoli in cluster separati.Impatto ridotto dagli errori
Quando le organizzazioni vogliono limitare l'impatto di un errore di un operatore, di un guasto del cluster o del relativo errore dell'infrastruttura, possono suddividere i propri servizi su più cluster.Upgrade
Quando le organizzazioni sono preoccupate di potenziali problemi con l'upgrade in loco (ovvero errori dell'automazione dell'upgrade, instabilità dell'applicazione o possibilità di eseguire il rollback), possono scegliere di eseguire il deployment di una copia dei propri servizi in un nuovo cluster. Questo tipo di upgrade richiede la pianificazione o l'automazione, per garantire la gestione del traffico e la replica dello stato durante il processo di upgrade.Separazione sicurezza/normative
Le organizzazioni possono scegliere di isolare i servizi per molti motivi, ad esempio mantenere i carichi di lavoro soggetti a requisiti normativi separati da quelli meno sensibili oppure eseguire servizi di terze parti (meno attendibili) su un'infrastruttura separata dai servizi proprietari (cluster).Separazione dei tenant
La separazione dei tenant in più cluster spesso viene eseguita per diversi motivi, tra cui l'isolamento della sicurezza, delle prestazioni, della contabilizzazione dei costi e persino della proprietà.
Località
Latenza
Alcuni servizi hanno requisiti di latenza che devono essere soddisfatti localizzando fisicamente il carico di lavoro in una località (o area geografica) specifica. Questa esigenza può verificarsi se i servizi upstream o gli utenti finali sono sensibili alla latenza, ma può anche verificarsi facilmente se il carico di lavoro stesso è sensibile alla latenza del servizio downstream.Disponibilità
L'esecuzione dello stesso servizio su più zone di disponibilità in un singolo provider cloud (o su più provider) può fornire una disponibilità complessiva più elevata.Giurisdizione
La residenza dei dati e altri requisiti di elaborazione giurisdizionale possono richiedere il computing e l'archiviazione all'interno di una regione specifica, il che richiede il deployment dell'infrastruttura in più data center o cloud provider.Gravità dei dati
Un grande corpus di dati, o anche alcune istanze di database, può essere difficile, impossibile o persino sconsigliato consolidarlo in un unico cloud provider o in una singola regione. A seconda dei requisiti di elaborazione e distribuzione, potrebbe essere necessario eseguire il deployment di un'applicazione in prossimità dei suoi dati.Infrastruttura/servizi legacy
Così come può essere difficile il trasferimento dei dati nel cloud, anche alcune infrastrutture legacy sono difficili da spostare. Sebbene questi servizi legacy siano immobili, il deployment di cluster aggiuntivi per lo sviluppo di nuovi servizi consente alle organizzazioni di aumentare la velocità di sviluppo.Scelta dello sviluppatore
Le organizzazioni spesso traggono vantaggio dalla possibilità di offrire agli sviluppatori la possibilità di scegliere i servizi gestiti nel cloud di cui usufruiscono. In generale, la scelta consente ai team di spostarsi più rapidamente con gli strumenti più adatti alle loro esigenze, a scapito della necessità di gestire le risorse aggiuntive allocate in ciascun provider.Esigenze di calcolo locali/perimetrali
Infine, poiché le organizzazioni vogliono adottare pratiche di modernizzazione delle applicazioni in ambienti di lavoro più tradizionali, come magazzini, fabbriche, negozi al dettaglio e così via, è necessario gestire molti più carichi di lavoro su molti più elementi dell'infrastruttura.
Scalabilità
Poiché GKE può scalare i cluster fino a più di 5000 nodi, questi limiti raramente diventano un motivo per gestire più cluster. Prima che un cluster raggiunga i limiti di scalabilità, spesso le organizzazioni decidono di distribuire i servizi su più cluster. Per i cluster che raggiungono i limiti di scalabilità, l'esecuzione di un'applicazione su più cluster può risolvere alcuni problemi, ma con la complessità aggiuntiva della gestione di più cluster.