Sebbene sia generalmente una best practice, utilizzare il minor numero possibile di cluster, scelgono di eseguire il deployment di più cluster per raggiungere i propri obiettivi commerciali per una serie di motivi. Come minimo, la maggior parte delle organizzazioni separano la loro attività non di produzione dai servizi di produzione posizionandoli in diversi cluster. In scenari più complessi, le organizzazioni potrebbero scegliere in più cluster per separare i servizi su livelli, impostazioni internazionali, team con i provider di infrastrutture.
La maggior parte dei motivi per l'adozione di più cluster rientra in tre categorie dei 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 garantire la disponibilità. esigenze di latenza e località
- Scalabilità: soprattutto nel contesto dei cluster Kubernetes, della 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 trovare un equilibrio tra molti di questi requisiti. contemporaneamente. Quando pensi alla tua organizzazione, ricorda che le nostre il suggerimento generale è quello di utilizzare il minor numero possibile di cluster. Determina quali delle esigenze multi-cluster sono la priorità più alta per la tua organizzazione, non può essere compromesso e quindi fare i compromessi appropriati per creare multi-cluster.
Se trovi la tua organizzazione che sta prendendo in considerazione un cluster per modello di servizio o una cluster-per-team, può essere utile considerare il carico della gestione imposte 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, per isolamento si intende la separazione del piano di controllo e/o entrambi raggiungibili eseguendo più cluster. Tuttavia, a seconda dell'implementazione, questa separazione probabilmente si estende anche al piano dati e l'isolamento dei dati. L'isolamento di solito si verifica quando si considera quanto segue:
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 effettuata per evitare interruzioni accidentali della produzione. e impedire l'accesso a dati sensibili durante lo sviluppo o i test.Livelli di carico di lavoro
Spesso le organizzazioni con molte applicazioni complesse gravano su di eseguire i servizi più critici su cluster separati a quelli meno critici. In un ambiente di questo tipo, i 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 è stateless e stateful posizionandoli in cluster separati.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 di potenziali problemi con l'upgrade in loco cioè errori di automazione durante l'upgrade, instabilità dell'applicazione o la capacità 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 fisicamente la localizzazione del carico di lavoro in una località (o area geografica). Questa esigenza può si verificano se i servizi upstream o gli utenti finali sono sensibili alla latenza, ma possono anche si verificano facilmente se il carico di lavoro stesso è sensibile alla latenza del servizio downstream.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 o regione. In base ai requisiti di elaborazione e distribuzione, potrebbe essere necessario eseguire il deployment vicino ai dati.Infrastruttura/servizi legacy
Così come può essere difficile spostare i dati nel cloud, anche alcune infrastrutture legacy è altrettanto difficile 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 scelta in ai servizi gestiti nel cloud di cui usufruiscono. In genere, la scelta consente ai team più rapidamente con gli strumenti più adatti alle loro esigenze, a scapito della di gestire risorse aggiuntive allocate in ciascun provider.Esigenze di computing locali/perimetrali
Infine, poiché le organizzazioni vogliono adottare pratiche di modernizzazione delle applicazioni ambienti di lavoro più tradizionali, come magazzini, fabbriche, negozi negozi e così via, per cui è necessario gestire molti più carichi di lavoro e dell'infrastruttura.
Scala
Poiché GKE può scalare i cluster 5000 nodi, questi limiti raramente diventano 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 la scalabilità limiti, l'esecuzione di un'applicazione su più cluster può attenuare sfide, ma con l'ulteriore complessità derivante dalla gestione di più cluster.