Sebbene in genere sia 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 commerciali per una serie di motivi. Come minimo, la maggior parte delle organizzazioni separa i servizi non di produzione da quelli di produzione inserendoli 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 infrastrutture.
La maggior parte dei motivi per adottare più cluster rientra in tre categorie di requisiti:
- Isolamento:separazione del piano di controllo e del piano dati dei servizi, principalmente per migliorare l'affidabilità o soddisfare le esigenze di sicurezza
- Posizione:posizionamento dei servizi in località specifiche per soddisfare le esigenze di disponibilità, latenza e località
- Scalabilità:soprattutto nel contesto dei cluster Kubernetes, scalare i servizi oltre i limiti pratici imposti da un singolo cluster
Questi aspetti vengono esaminati in modo più dettagliato nelle sezioni seguenti.
In molti casi, le organizzazioni devono bilanciare contemporaneamente diversi di questi requisiti. Quando pensi alla tua organizzazione, ricorda che il nostro consiglio generale è di utilizzare il minor numero possibile di cluster. Determina quali delle esigenze multicluster sono la priorità più alta per la tua organizzazione e non possono essere compromesse, quindi fai i compromessi appropriati per creare un'architettura multicluster.
Se la tua organizzazione sta prendendo in considerazione una modalità cluster per modello di servizio o cluster per team, ti consigliamo di valutare il carico di gestione imposto agli operatori di un sistema di questo tipo. I parchi risorse e i Google Cloud componenti e le funzionalità che li supportano cercano di semplificare il più possibile la gestione di più cluster, ma c'è sempre una maggiore complessità di gestione con più cluster.
Isolamento
In questo contesto, l'isolamento si riferisce alla separazione del control plane e/o del data plane, entrambi ottenibili eseguendo più cluster. Tuttavia, a seconda dell'implementazione, questa separazione si estende probabilmente anche all'isolamento del piano dati. L'isolamento viene in genere preso in considerazione quando si valutano i seguenti aspetti:
Ambiente
Il più delle volte, le organizzazioni eseguono i servizi di sviluppo, gestione temporanea/test e produzione su cluster separati, spesso su reti e progetti cloud diversi. Questa separazione viene eseguita per evitare interruzioni accidentali dei servizi di produzione e impedire l'accesso a dati sensibili durante lo sviluppo o i test.Livelli di workload
Spesso le organizzazioni che hanno molte applicazioni complesse suddividono i servizi in livelli, 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 in termini di accesso, sicurezza, upgrade, policy e altro ancora. Un esempio di questo livello è la separazione dei servizi stateless e stateful posizionandoli su cluster separati.Impatto ridotto in caso di errore
Quando le organizzazioni vogliono limitare gli impatti di un errore dell'operatore, di un errore del cluster o di un errore dell'infrastruttura correlata, possono dividere i propri servizi in più cluster.Upgrade
Quando le organizzazioni sono preoccupate per potenziali problemi con l'upgrade in loco (ovvero errori di automazione dell'upgrade, instabilità dell'applicazione o possibilità di rollback), possono scegliere di eseguire il deployment di una copia dei propri servizi in un nuovo cluster. L'upgrade in questo modo richiede la pianificazione o l'automazione per renderlo possibile, assicurandosi di gestire la gestione del traffico e la replica dello stato durante il processo di upgrade.Separazione di sicurezza/normativa
Le organizzazioni possono scegliere di isolare i servizi per molti motivi, tra cui mantenere i carichi di lavoro soggetti a requisiti normativi separati da quelli meno sensibili o eseguire servizi di terze parti (meno attendibili) su un'infrastruttura separata dai servizi (cluster) proprietari (attendibili).Separazione dei tenant
La separazione dei tenant in più cluster viene spesso eseguita per una serie di motivi, tra cui l'isolamento della sicurezza, l'isolamento delle prestazioni, la contabilità dei costi e persino la proprietà.
Località
Latenza
Alcuni servizi hanno requisiti di latenza che devono essere soddisfatti posizionando fisicamente il workload in una posizione (o area geografica) specifica. Questa necessità può verificarsi se i servizi upstream o gli utenti finali sono sensibili alla latenza, ma anche se il carico di lavoro stesso è sensibile alla latenza del servizio downstream.Disponibilità
L'esecuzione dello stesso servizio in più zone di disponibilità in un singolo fornitore di servizi cloud (o in più fornitori) può fornire una disponibilità complessiva più elevata.Giurisdizione
La residenza dei dati e altri requisiti di elaborazione giurisdizionali possono richiedere che il calcolo e l'archiviazione si trovino all'interno di una regione specifica, richiedendo che l'infrastruttura venga implementata in più data center o fornitori di servizi cloud.Gravità dei dati
Un grande corpus di dati o anche determinate istanze di database possono essere difficili, impossibili o addirittura sconsigliabili da consolidare in un unico provider cloud o regione. A seconda dei requisiti di elaborazione e pubblicazione, un'applicazione potrebbe dover essere implementata vicino ai suoi dati.Infrastruttura/servizi legacy
Proprio come i dati possono essere difficili da spostare nel cloud, anche alcune infrastrutture legacy sono altrettanto 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 scelta dei servizi gestiti nel cloud che utilizzano. In genere, la scelta consente ai team di muoversi più rapidamente con gli strumenti più adatti alle loro esigenze a scapito della necessità di gestire risorse aggiuntive allocate in ogni provider.Esigenze di calcolo locale/edge
Infine, poiché le organizzazioni vogliono adottare pratiche di modernizzazione delle applicazioni in ambienti di lavoro più tradizionali, come magazzini, stabilimenti, negozi al dettaglio e così via, ciò richiede la gestione di molti più carichi di lavoro su molte più infrastrutture.
Scala
Poiché GKE può scalare i cluster a più di 5000 nodi, questi limiti raramente diventano un motivo per gestire più cluster. Prima che un cluster raggiunga i limiti di scalabilità, le organizzazioni spesso 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ò semplificare alcune sfide, ma con la maggiore complessità della gestione di più cluster.