Sebbene in genere sia consigliabile utilizzare il minor numero possibile di cluster, per vari motivi le organizzazioni scelgono di implementare più cluster per raggiungere i propri scopi tecnici e commerciali. Come minimo, la maggior parte delle organizzazioni separa i servizi di produzione da quelli non di produzione collocandoli in cluster diversi. In scenari più complessi, le organizzazioni potrebbero scegliere in più cluster per separare i servizi tra livelli, impostazioni internazionali, team con i provider di infrastrutture.
La maggior parte dei motivi per cui adottare più cluster rientra in tre categorie di requisiti:
- Isolamento:separare il piano di controllo dal piano dati dei servizi; principalmente per migliorare l'affidabilità o far fronte alle 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, della scalabilità dei servizi oltre i limiti pratici imposti da un singolo cluster
Analizzeremo questi aspetti in modo più dettagliato nelle sezioni seguenti.
In molti casi, le organizzazioni devono bilanciare molti di questi requisiti. contemporaneamente. Quando pensi alla tua organizzazione, ricorda che il nostro consiglio generale è di utilizzare il minor numero possibile di cluster. Determina quali delle esigenze multi-cluster hanno la massima priorità 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 valutando un modello di cluster per servizio o una modalità cluster per team, ti consigliamo di prendere in considerazione il carico di gestione imposto agli operatori di un sistema di questo tipo. Parchi risorse e Google Cloud i componenti e le funzionalità che le supportano cercare di semplificare il più possibile la gestione di più cluster, ma sempre un'ulteriore complessità di gestione con più cluster.
Isolamento
In questo contesto, l'isolamento si riferisce alla separazione del piano di controllo e/o del piano di dati, che possono essere entrambi ottenuti eseguendo più cluster. Tuttavia, a seconda dell'implementazione, questa separazione si estende probabilmente anche all'isolamento del piano di dati. L'isolamento si verifica in genere quando si prendono in considerazione i seguenti aspetti:
Ambiente
Molto spesso le organizzazioni eseguono i propri processi di sviluppo, gestione temporanea/test e produzione su cluster separati, spesso in esecuzione su reti e cloud diversi in modo programmatico a gestire i progetti. Questa separazione viene eseguita per evitare interruzioni accidentali dei servizi di produzione e per impedire l'accesso a dati sensibili durante lo sviluppo o il test.Livellamento dei carichi di lavoro
Spesso le organizzazioni con molte applicazioni complesse suddividono 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 sono trattati con particolare attenzione per quanto riguarda l'accesso, sicurezza, upgrade, criteri e altro ancora. Un esempio di questa suddivisione in livelli è la separazione dei servizi senza stato e con stato collocandoli in cluster distinti.Riduzione dell'impatto degli errori
Quando le organizzazioni vogliono limitare l'impatto di un errore di un operatore, o un guasto dell'infrastruttura correlato, possono suddividere i loro servizi in più cluster.Upgrade
Quando le organizzazioni sono preoccupate per potenziali problemi con l'upgrade in situ (ad es. errori di 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 perché sia possibile, di gestire la gestione del traffico e la replica dello stato durante processo di upgrade.Separazione tra sicurezza e normative
Le organizzazioni possono scegliere di isolare i servizi per molti motivi, tra cui la conservazione carichi di lavoro soggetti a requisiti normativi separati da quelli meno sensibili, o che eseguono servizi di terze parti (meno attendibili) su un'infrastruttura separata servizi (cluster) proprietari (attendibili).Separazione dei tenant
La separazione dei tenant in più cluster spesso avviene per diversi motivi, tra cui isolamento di sicurezza, isolamento delle prestazioni, contabilità dei costi persino sulla proprietà.
Località
Latenza
Alcuni servizi hanno requisiti di latenza che devono essere soddisfatti collocando fisicamente il carico di lavoro in una località (o area geografica) specifica. Questa necessità può verificarsi se i servizi a monte o gli utenti finali sono sensibili alla latenza, ma può verificarsi facilmente anche se il carico di lavoro stesso è sensibile alla latenza del servizio a valle.Disponibilità
Esecuzione dello stesso servizio in più zone di disponibilità in un singolo cloud (o di più provider) possono offrire una disponibilità complessiva più elevata.Giurisdizione
La residenza dei dati e altri requisiti di elaborazione giurisdizionale possono richiedere le risorse di computing e archiviazione per risiedere all'interno di una regione specifica, che richiede l'infrastruttura il deployment 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 sconsigliato, consolidarlo in un unico cloud provider, regione. In base ai requisiti di elaborazione e distribuzione, potrebbe essere necessario eseguire il deployment vicino ai dati.Infrastruttura/servizi legacy
Proprio come può essere difficile spostare 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 dello sviluppatore
Spesso le organizzazioni traggono vantaggio dalla possibilità di offrire agli sviluppatori la possibilità di scegliere tra i servizi gestiti su cloud che utilizzano. In genere, la scelta consente ai team di muoversi più rapidamente con gli strumenti più adatti alle loro esigenze, a discapito della necessità di gestire risorse aggiuntive allocate in ogni fornitore.Esigenze di calcolo locale/edge
Infine, poiché le organizzazioni vogliono adottare pratiche di modernizzazione delle applicazioni in ambienti di lavoro più tradizionali, come magazzini, reparti di produzione, negozi di vendita al dettaglio e così via, è necessario gestire molti più carichi di lavoro su molti più componenti dell'infrastruttura.
Scala
Poiché GKE può scalare i cluster fino a più di 5000 nodi, spesso questi limiti non sono un motivo per gestire più cluster. Prima di un di un cluster raggiunge i limiti di scalabilità, le organizzazioni spesso decidono di distribuire in più cluster. Per i cluster che raggiungono i limiti di scalabilità, l'esecuzione di un'applicazione su più cluster può semplificare alcune difficoltà, ma con la complessità aggiuntiva della gestione di più cluster.