Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Bien qu'il soit généralement recommandé d'utiliser le moins de clusters possible, les entreprises choisissent de déployer plusieurs clusters pour atteindre leurs objectifs techniques et commerciaux pour diverses raisons. La plupart des entreprises séparent au minimum leurs services hors production de leurs services de production en les plaçant dans des clusters différents. Dans des scénarios plus complexes, les entreprises peuvent choisir d'utiliser plusieurs clusters pour séparer les services entre les niveaux, les paramètres régionaux, les équipes ou les fournisseurs d'infrastructure.
Dans la plupart des cas, l'utilisation de plusieurs clusters relève de trois catégories d'exigences :
Isolation : séparation entre le plan de contrôle et le plan de données des services, principalement pour améliorer la fiabilité ou répondre aux besoins de sécurité
Emplacement : disposition des services dans des emplacements spécifiques pour répondre aux besoins de disponibilité, de latence et de localisation
Scaling : en particulier dans le contexte des clusters Kubernetes, le scaling des services au-delà des limites pratiques imposées par un seul cluster
Nous examinons ces catégories plus en détail dans les sections suivantes.
Dans de nombreux cas, les entreprises doivent équilibrer plusieurs de ces critères en même temps. En ce qui concerne votre propre entreprise, n'oubliez pas que nous recommandons d'utiliser le moins de clusters possible. Déterminez les besoins de multicluster avec le niveau de priorité le plus élevé pour votre entreprise et ne pouvant pas être compromis, puis effectuez les ajustements nécessaires pour créer une architecture multicluster.
Si votre entreprise envisage le mode de cluster par modèle de service ou de cluster par équipe, vous devez tenir compte des contraintes de gestion qui incombent aux opérateurs d'un tel système.
Les parcs et les Google Cloud
composants et fonctionnalités compatibles avec Google Cloud s'efforcent de faciliter la gestion de plusieurs clusters, mais elle est toujours plus complexe avec plus de clusters.
Isolation
Dans ce contexte, l'isolation fait référence à la séparation du plan de contrôle et/ou du plan de données, pouvant s'atteindre dans les deux cas en exécutant plusieurs clusters. Toutefois, en fonction de la mise en œuvre, cette séparation peut également s'étendre à l'isolation du plan de données. L'isolation s'effectue généralement lorsque les conditions suivantes sont remplies :
Environnement
La plupart du temps, les entreprises exécutent leurs services de développement, de préproduction/test et de production sur des clusters distincts, souvent sur différents réseaux et projets cloud. Cette séparation permet d'éviter toute interruption accidentelle des services de production et d'empêcher l'accès aux données sensibles pendant les phases de développement ou de tests.
Hiérarchisation des charges de travail
Souvent, les entreprises qui gèrent de nombreuses applications complexes hiérarchisent leurs services, en choisissant d'exécuter leurs services les plus critiques sur des clusters qui diffèrent de leurs clusters moins importants. Dans un environnement de ce type, ces services plus critiques et leurs clusters sont traités avec une attention particulière en ce qui concerne l'accès, la sécurité, les mises à niveau, les stratégies, etc. Un exemple de cette hiérarchie consiste à séparer les services sans état et les services avec état, en les plaçant sur des clusters distincts.
Impact réduit en cas de défaillance
Lorsque les entreprises souhaitent limiter les effets d'une erreur d'opérateur, d'une défaillance du cluster ou d'une défaillance d'infrastructure associée, elles peuvent répartir leurs services sur plusieurs clusters.
Mises à niveau
Lorsque les entreprises s'inquiètent des problèmes potentiels liés à la mise à niveau existante (c'est-à-dire en cas d'échec de l'automatisation de la mise à niveau, de la fiabilité de l'application ou de la possibilité d'effectuer un rollback), elles peuvent choisir de déployer une copie de leurs services dans un nouveau cluster.
Pour pouvoir être appliquée, cette méthode de mise à niveau nécessite une planification ou une automatisation. Veillez à gérer la gestion du trafic et la réplication de l'état pendant le processus de mise à niveau.
Sécurité/séparation réglementaire
Les entreprises peuvent choisir d'isoler les services pour de nombreuses raisons, y compris pour maintenir la séparation entre les charges de travail soumises à des exigences réglementaires et celles qui sont moins sensibles, ou pour exécuter des services tiers (moins fiables) sur une infrastructure distincte de celles des services (clusters) propriétaires (fiables).
Séparation des locataires
La séparation des locataires en plusieurs clusters est souvent effectuée pour différentes raisons, y compris l'isolation de sécurité, l'isolation des performances, la comptabilité analytique, et même la propriété.
Location (Emplacement)
Latence
Certains services ont des exigences de latence qui doivent être respectées en localisant physiquement la charge de travail dans un emplacement ou une zone géographique spécifique. Cela peut être nécessaire si les utilisateurs finaux ou les services en amont sont sensibles à la latence, mais également si la charge de travail elle-même est sensible à la latence du service en aval.
Disponibilité
L'exécution du même service sur plusieurs zones de disponibilité dans un fournisseur cloud unique (ou à travers plusieurs fournisseurs) peut entraîner une disponibilité globale plus élevée.
Juridiction
La résidence des données et d'autres exigences en termes de traitement juridictionnel peuvent nécessiter que le calcul et le stockage soient actifs dans une région spécifique, ce qui nécessite le déploiement d'une infrastructure dans plusieurs centres de données ou fournisseurs cloud.
Gravité des données
Il peut être difficile, impossible, voire contre-indiqué de consolider un grand corpus de données, ou même certaines instances de bases de données, chez un seul fournisseur cloud ou dans une seule région. En fonction des exigences de traitement et de diffusion, une application peut avoir besoin d'être déployée à proximité de ses données.
Infrastructure/services anciens
De même que les données peuvent être difficiles à migrer vers le cloud, certaines ancienne infrastructures peuvent l'être tout autant. Bien que ces anciens services soient immuables, le déploiement de clusters supplémentaires pour le développement de nouveaux services permet aux entreprises d'accélérer le développement.
Choix du développeur
Les entreprises bénéficient souvent du choix des développeurs dans les services gérés dans le cloud qu'elles utilisent. En règle générale, ce choix permet aux équipes de travailler plus rapidement avec des outils qui répondent mieux à leurs besoins au détriment de la nécessité de gérer des ressources supplémentaires allouées à chaque fournisseur.
Besoins en calcul local/edge computing
Enfin, pour les entreprises qui souhaitent adopter des pratiques de modernisation d'applications dans des environnements de travail plus traditionnels (tels que des entrepôts, des sites de production, des commerces de détail, etc.), il sera nécessaire de gérer davantage de charges de travail sur davantage d'éléments d'infrastructure.
Effectuer le scaling
Étant donné que GKE peut faire évoluer les clusters à plus de 5 000 nœuds, ces limites justifient rarement de faire fonctionner plusieurs clusters. Avant qu'un cluster n'atteigne les limites d'évolutivité, les entreprises décident souvent de distribuer les services sur plusieurs clusters. Pour les clusters qui atteignent les limites d'évolutivité, l'exécution d'une application sur plusieurs clusters peut faciliter certaines problématiques, mais avec la complexité supplémentaire d'avoir à gérer plusieurs clusters.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/31 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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."]]
