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 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 control plane e del data plane dei servizi, principalmente per migliorare l'affidabilità o soddisfare le esigenze di sicurezza
- Località:inserimento dei servizi in località specifiche per soddisfare le esigenze di disponibilità, latenza e località
- Scala:soprattutto nel contesto dei cluster Kubernetes, scalare i servizi oltre i limiti pratici imposti da un singolo cluster
Li esaminiamo 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 la nostra raccomandazione generale è di utilizzare il minor numero possibile di cluster. Determina quali delle esigenze multi-cluster sono la massima priorità per la tua organizzazione e non possono essere compromesse, quindi effettua i compromessi appropriati per creare un'architettura multi-cluster.
Se la tua organizzazione sta prendendo in considerazione un modello di cluster per servizio o una modalità 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 la complessità di gestione aggiuntiva è sempre maggiore con più cluster.
Isolamento
In questo contesto, il termine 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 data plane. L'isolamento viene in genere preso in considerazione quando si esaminano 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 ai dati sensibili durante lo sviluppo o i test.Livelli di workload
Spesso le organizzazioni che hanno molte applicazioni complesse classificano 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 merito ad accesso, sicurezza, upgrade, policy e altro ancora. Un esempio di questa classificazione è la separazione dei servizi senza stato e con stato inserendoli in cluster separati.Impatto ridotto in caso di errore
Quando le organizzazioni vogliono limitare l'impatto di un errore dell'operatore, di un errore del cluster o di un errore dell'infrastruttura correlata, possono suddividere i servizi su più cluster.Upgrade
Quando le organizzazioni sono preoccupate per potenziali problemi con l'upgrade in-place (ovvero l'errore di automazione dell'upgrade, l'instabilità dell'applicazione o la possibilità di eseguire il rollback), possono scegliere di eseguire il deployment di una copia dei 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 workload soggetti a requisiti normativi separati da quelli meno sensibili o eseguire servizi di terze parti (meno attendibili) su un'infrastruttura separata dai servizi (cluster) di prime parti (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 localizzando fisicamente il workload 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 facilmente anche se il workload stesso è sensibile alla latenza del servizio downstream.Disponibilità
L'esecuzione dello stesso servizio in più zone di disponibilità in un singolo provider di servizi cloud (o in più provider) 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 risiedano in una regione specifica, richiedendo il deployment dell'infrastruttura in più data center o provider di servizi cloud.Gravità dei dati
Un grande corpus di dati o anche alcune istanze di database possono essere difficili, impossibili o addirittura sconsigliabili da consolidare in un singolo provider di servizi cloud o in una singola regione. A seconda dei requisiti di elaborazione e pubblicazione, potrebbe essere necessario eseguire il deployment di un'applicazione vicino ai relativi dati.Infrastruttura/servizi legacy
Proprio come i dati possono essere difficili da spostare 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 scelta dei servizi gestiti dal cloud che utilizzano. In genere, 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 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, è necessario gestire molti più workload 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 complessità aggiuntiva della gestione di più cluster.