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 aziendali per vari motivi. Come minimo, la maggior parte delle organizzazioni separa i servizi non di produzione da quelli di produzione posizionandoli in cluster diversi. In scenari più complessi, le organizzazioni possono scegliere più cluster per separare i servizi tra livelli, impostazioni internazionali, team o provider di infrastrutture.
La maggior parte dei motivi per l'adozione di più cluster rientra in tre categorie di requisiti:
- Isolamento:separa il piano di controllo e quello dati dei servizi, principalmente per migliorare l'affidabilità o soddisfare esigenze di sicurezza.
- Posizione: posiziona i servizi in località specifiche per soddisfare esigenze di disponibilità, latenza e località
- Scala: soprattutto nel contesto dei cluster Kubernetes, scalabilità dei servizi oltre i limiti pratici imposti da un singolo cluster
Approfondiremo questi aspetti 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 è di utilizzare il minor numero di cluster possibile. Determina quali delle esigenze multi-cluster hanno la priorità più alta per la tua organizzazione e non possono essere compromesse, quindi fai i compromessi appropriati per creare un'architettura multi-cluster.
Se la tua organizzazione sta prendendo in considerazione una modalità cluster per modello di servizio o cluster-per-team, potresti considerare 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 impegnano a 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 tra il piano di controllo e/o il 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 in genere viene generato quando si considerano i seguenti aspetti:
Ambiente
Molto spesso le organizzazioni eseguono i propri servizi di sviluppo, gestione temporanea/test e produzione in cluster separati, spesso in esecuzione su reti e progetti cloud diversi. Questa separazione viene eseguita per evitare interruzioni accidentali dei servizi di produzione e impedire l'accesso ai dati sensibili durante lo sviluppo o i test.Livelli di carico di lavoro
Spesso le organizzazioni con molte applicazioni complesse raggruppano 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 in termini di accesso, sicurezza, upgrade, criteri e altro ancora. Un esempio di questa classificazione è la separazione dei servizi stateless e stateful posizionandoli in cluster separati.Impatto ridotto degli errori
Quando le organizzazioni vogliono limitare l'impatto di un errore dell'operatore, di un guasto del cluster o di un relativo guasto dell'infrastruttura, possono suddividere i propri servizi tra più cluster.Upgrade
Se le organizzazioni sono preoccupate di potenziali problemi con l'upgrade in loco (ovvero, errore dell'automazione, malfunzionamenti delle applicazioni o la possibilità di eseguire il rollback), possono scegliere di eseguire il deployment di una copia dei loro servizi in un nuovo cluster. Questo tipo di upgrade richiede la pianificazione o l'automazione per renderlo possibile, assicurandoti di gestire la gestione del traffico e la replica dello stato durante il processo di upgrade.Separazione tra sicurezza e normative
Le organizzazioni possono scegliere di isolare i servizi per diversi motivi, tra cui mantenere i carichi di lavoro soggetti a requisiti normativi separati da quelli meno sensibili o eseguire servizi di terze parti (meno affidabili) su un'infrastruttura separata dai servizi proprietari (cluster).Separazione dei tenant
La separazione dei tenant in più cluster avviene spesso per diversi motivi, tra cui l'isolamento della sicurezza, dell'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 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ò verificarsi anche se il carico di lavoro stesso è sensibile alla latenza dei servizi downstream.Disponibilità
L'esecuzione dello stesso servizio in più zone di disponibilità in un unico cloud provider (o su più provider) può offrire una disponibilità complessiva maggiore.Giurisdizione
La residenza dei dati e altri requisiti di elaborazione giurisdizionali possono richiedere che le risorse di calcolo e di archiviazione siano 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 addirittura inopportuno da consolidare in un unico cloud provider o regione. A seconda dei requisiti di elaborazione e distribuzione, potrebbe essere necessario eseguire il deployment di un'applicazione vicino ai dati.Infrastruttura/servizi legacy
Così come può essere difficile trasferire i 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 degli sviluppatori
Spesso le organizzazioni traggono vantaggio dall'essere in grado di offrire agli sviluppatori una scelta sui servizi gestiti su cloud che utilizzano. 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 risorse aggiuntive allocate in ciascun provider.Esigenze di computing locale/edge
Infine, poiché le organizzazioni vogliono adottare pratiche di modernizzazione delle applicazioni in ambienti di lavoro più tradizionali, come warehouse, fabbriche, negozi al dettaglio e così via, questo richiede la gestione di molti più carichi di lavoro su molti più elementi di infrastruttura.
Scalabilità
Poiché GKE può scalare i cluster fino a più di 5000 nodi, questi limiti raramente diventano un motivo per utilizzare più cluster. Prima che un cluster raggiunga i limiti di scalabilità, le organizzazioni spesso decidono di distribuire servizi su più cluster. Per i cluster che raggiungono i limiti di scalabilità, l'esecuzione di un'applicazione su più cluster può eliminare alcuni problemi, ma comporta l'ulteriore complessità di gestire più cluster.