Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
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 obiettivi 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 più cluster per separare i servizi tra livelli, impostazioni internazionali, team o provider di infrastrutture.
La maggior parte dei motivi per cui 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à: in particolare nel contesto dei cluster Kubernetes, la 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 diversi 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.
I parchi risorse e i Google Cloud
componenti e le funzionalità che li supportano
si impegnano a semplificare il più possibile la gestione di più cluster, ma c'è sempre un po' di complessità di gestione aggiuntiva 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
Spesso 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 il test.
Livellamento dei workload
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 vengono trattati con particolare attenzione in termini di accesso, sicurezza, upgrade, norme 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 dell'operatore, di un errore del cluster o di un errore dell'infrastruttura correlato, possono suddividere i servizi su più cluster.
Upgrade
Quando le organizzazioni sono preoccupate per potenziali problemi con l'upgrade in-place (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.
L'upgrade in questo modo richiede pianificazione o automazione per essere possibile,
assicurandosi di gestire la gestione del traffico e la replica dello stato durante il
procedura di upgrade.
Separazione per motivi di sicurezza/normativi
Le organizzazioni possono scegliere di isolare i servizi per molti motivi, ad esempio per mantenere i carichi di lavoro soggetti a requisiti normativi separati da quelli meno sensibili o per eseguire servizi di terze parti (meno attendibili) su un'infrastruttura separata da quella dei servizi proprietari (attendibili) (cluster).
Separazione degli utenti
La separazione degli utenti 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 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à
L'esecuzione dello stesso servizio in più zone di disponibilità in un singolo fornitore cloud (o in più fornitori) può fornire una disponibilità complessiva superiore.
Giurisdizione
La residenza dei dati e altri requisiti di elaborazione per giurisdizione possono richiedere che l'elaborazione e lo spazio di archiviazione si trovino in una regione specifica, il che richiede l'implementazione dell'infrastruttura in più data center o provider cloud.
Attrazione dei dati
Un ampio corpus di dati o anche determinate istanze di database può essere difficile, impossibile o addirittura sconsigliabile da consolidare in un singolo fornitore o regione cloud. A seconda dei requisiti di elaborazione e pubblicazione, potrebbe essere necessario eseguire il deployment di un'applicazione in prossimità dei 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 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.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-07-31 UTC."],[],[],null,["While it is generally a best practice to use as few clusters as possible,\norganizations choose to deploy multiple clusters to achieve their technical and\nbusiness objectives for a variety of reasons. At a minimum, most organizations\nseparate their non-production from their production services by placing them in\ndifferent clusters. In more complex scenarios, organizations might choose\nmultiple clusters to separate services across tiers, locales, teams, or\ninfrastructure providers.\n\nMost reasons for adopting multiple clusters fall into three categories\nof requirements:\n\n- **Isolation:** separating the control plane and data plane of services, primarily to improve reliability or address security needs\n- **Location:** placing services in specific locations to address availability, latency, and locality needs\n- **Scale:** especially in the context of Kubernetes clusters, scaling services beyond the practical limits imposed by a single cluster\n\nWe look at these in more detail in the following sections.\n\nIn many cases, organizations need to balance several of these requirements\nsimultaneously. As you think about your own organization, remember that our\ngeneral recommendation is to use as few clusters as possible. Determine which\nof the multi-cluster needs are the highest priority for your organization and\ncannot be compromised, and then make appropriate tradeoffs to create a\nmulti-cluster architecture.\n\nIf you find your organization considering a *cluster per service-model* or a\n*cluster-per-team* mode, you might want to consider the management burden\nimposed on the operators of such a system.\n[Fleets](/kubernetes-engine/fleet-management/docs/fleet-concepts) and the Google Cloud\n[components and features that support them](/kubernetes-engine/fleet-management/docs)\nstrive to make managing multiple clusters as easy as possible, but there is\nalways some additional management complexity with more clusters.\n\nIsolation\n\nIn this context, *isolation* refers to separation of the control plane and/or\ndata plane, both of which can be achieved by running multiple clusters. However,\ndepending on implementation, this separation likely also extends to data plane\nisolation. Isolation usually comes up when considering the following:\n\n- **Environment** \n\n More often than not, organizations run their development, staging/test, and production\n services across separate clusters, often running on different networks and cloud\n projects. This separation is done to avoid accidental disruption of production\n services and prevent access to sensitive data during development or testing.\n\n- **Workload tiering** \n\n Often organizations that have many complex applications tier their\n services, choosing to run their more critical services on separate clusters from\n their less critical ones. In such an environment, these more critical services\n and their clusters are treated with special consideration around access,\n security, upgrades, policy, and more. An example of this tiering is separating\n *stateless* and *stateful* services by placing them on separate clusters.\n\n- **Reduced impact from failure** \n\n When organizations want to limit the impacts of an operator mistake, cluster\n failure, or related infrastructure failure, they can split their services\n across multiple clusters.\n\n- **Upgrades** \n\n When organizations are concerned about potential issues with upgrading in-place\n (that is, upgrading automation failure, application flakiness, or the ability to\n roll back), they can choose to deploy a copy of their services in a new cluster.\n Upgrading in this fashion requires planning or automation to make it possible,\n being sure to address traffic management and state replication during the\n upgrade process.\n\n- **Security/regulatory separation** \n\n Organizations can choose to isolate services for many reasons, including keeping\n workloads subject to regulatory requirements separate from less-sensitive ones,\n or running third-party (less-trusted) services on separate infrastructure from\n first-party (trusted) services (clusters).\n\n- **Tenant separation** \n\n Separating tenants into multiple clusters is often done for a variety of reasons,\n including security isolation, performance isolation, cost accounting, and\n even ownership.\n\nLocation\n\n- **Latency** \n\n Certain services have latency requirements that must be met by physically\n locating that workload in a specific location (or geography). This need can\n occur if upstream services or end-users are sensitive to latency, but can also\n easily occur if the workload itself is sensitive to downstream service latency.\n\n- **Availability** \n\n Running the same service across multiple availability zones in a single-cloud\n provider (or across multiple providers) can provide higher overall availability.\n\n- **Jurisdiction** \n\n Data residency and other jurisdictional processing requirements can require\n compute and storage to live within a specific region, requiring infrastructure\n to be deployed in multiple data centers or cloud providers.\n\n- **Data gravity** \n\n A large corpus of data, or even certain database instances, can be difficult,\n impossible, or even inadvisable to consolidate in a single cloud provider or\n region. Depending on the processing and serving requirements, an application\n might need to be deployed close to its data.\n\n- **Legacy infrastructure/services** \n\n Just as data can be difficult to move to the cloud, some legacy infrastructure\n is similarly difficult to move. Although these legacy services are immobile, deploying additional clusters for the development of new services allows organizations to increase development velocity.\n\n- **Developer choice** \n\n Organizations often benefit from being able to provide developers choice in\n the cloud-managed services that they consume. Generally, choice lets teams move\n more quickly with tools that are best-suited to their needs at the expense of\n needing to manage additional resources allocated in each provider.\n\n- **Local/edge compute needs** \n\n Finally, as organizations want to adopt application modernization practices in\n more traditional work environments, like warehouses, factory floors, retail\n stores, and so on, this necessitates managing many more workloads on many more\n pieces of infrastructure.\n\nScale\n\nBecause GKE can scale clusters to more than\n[5000 nodes](/kubernetes-engine/docs/concepts/planning-large-workloads#above-5000),\nthese limits rarely become a reason to operate multiple clusters. Before a\ncluster reaches scalability limits, organizations often decide to distribute\nservices across multiple clusters. For clusters that do reach scalability\nlimits, running an application across multiple clusters can ease some\nchallenges, but with the added complexity of managing multiple clusters."]]
