Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Obwohl es sich im Allgemeinen empfiehlt, möglichst wenige Cluster zu verwenden, wählen Organisationen aber aus verschiedenen Gründen die Bereitstellung mehrerer Cluster, um ihre technischen und geschäftlichen Ziele zu erreichen. Die meisten Organisationen trennen Produktions- und Nicht-Produktionsdienste voneinander, indem sie sie in verschiedenen Clustern bereitstellen. In komplexeren Szenarien können Organisationen mehrere Cluster auswählen, um Dienste auf verschiedene Ebenen, Sprachen, Teams oder Infrastrukturanbieter aufzuteilen.
Die häufigsten Gründe für die Einführung mehrerer Cluster lassen sich in drei Kategorien von Anforderungen unterteilen:
Isolation: Trennen der Steuerungsebene und der Datenebene von Diensten, hauptsächlich zur Verbesserung der Zuverlässigkeit oder Adressierung von Sicherheitsanforderungen
Standort: Platzieren von Diensten an bestimmten Standorten, um Verfügbarkeit-, Latenz- und Standortanforderungen zu erfüllen
Skalierung: Insbesondere im Zusammenhang mit Kubernetes-Clustern die Skalierung von Diensten über die praktischen Grenzen eines einzelnen Clusters hinaus
Die Kategorien werden in den folgenden Abschnitten ausführlicher behandelt.
In vielen Fällen müssen Organisationen mehrere dieser Anforderungen gleichzeitig erfüllen. Achten Sie in Ihrer Organisation darauf, dass Sie generell möglichst wenige Cluster verwenden sollten. Ermitteln Sie, welche der Multi-Cluster-Anforderungen die höchste Priorität für Ihre Organisation haben und nicht kompromittiert werden können, und gehen Sie dann entsprechende Kompromisse ein, um eine Multi-Cluster-Architektur zu erstellen.
Wenn Ihre Organisation ein Cluster pro Dienst-Modell oder einen Cluster pro Team-Modus in Betracht zieht, sollten Sie überlegen, wie viel Verwaltungsaufwand für die Operatoren eines solchen Systems entsteht.
Flotten und die Google Cloud
unterstützenden Komponenten und Funktionen sollen die Verwaltung mehrerer Cluster so einfach wie möglich machen. Es gibt jedoch immer zusätzliche Verwaltungskomplexität bei mehr Clustern.
Isolation
In diesem Kontext bezieht sich Isolation auf die Trennung der Steuerungsebene und/oder Datenebene. Beide können durch Ausführen mehrerer Cluster erreicht werden. Abhängig von der Implementierung erstreckt sich diese Trennung wahrscheinlich aber auch auf die Datenisolation. Isolation tritt in der Regel in folgenden Fällen auf:
Umgebung
Sehr oft führen Organisationen ihre Entwicklungs-, Staging-/Test- und Produktionsdienste in separaten Clustern aus, die häufig in verschiedenen Netzwerken und Cloudprojekten ausgeführt werden. Diese Trennung soll dazu führen, dass die Produktionsdienste nicht versehentlich unterbrochen werden und der Zugriff auf sensible Daten während der Entwicklung oder Tests verhindert wird.
Arbeitslast-Tiering
Oft wenden Unternehmen, die viele komplexe Anwendungen haben, ein Dienst-Tierung an, um kritische und weniger kritische Dienste auf verschiedenen Clustern auszuführen. In einer solchen Umgebung werden diese kritischen Dienste und ihre Cluster im Hinblick auf Zugriff, Sicherheit, Upgrades, Richtlinien usw. mit besonderer Aufmerksamkeit behandelt. Ein Beispiel für dieses Tiering ist die Bereitstellung von zustandslosen und zustandsorientierten Diensten in separaten Clustern.
Reduzierte Auswirkungen von Fehlern
Wenn Unternehmen die Auswirkungen eines Bedienerfehlers, eines Clusterfehlers oder eines damit verbundenen Infrastrukturfehlers begrenzen möchten, können sie ihre Dienste auf mehrere Cluster aufteilen.
Upgrades
Wenn Organisationen sich Gedanken über mögliche Probleme beim Upgrade machen, z. B. Fehler bei automatischen Upgrades, instabile Anwendungen oder Rollback-Möglichkeit, können sie eine Kopie ihrer Dienste in einem neuen Cluster bereitstellen.
Ein Upgrade auf diese Weise erfordert Planung oder Automatisierung. Trafficverwaltung und Zustandsreplikation müssen während des Upgrades berücksichtigt werden.
Trennung von Sicherheit und Regulierung
Organisationen können Dienste aus verschiedenen Gründen isolieren, um beispielsweise Arbeitslasten, die rechtlichen Anforderungen unterliegen, von weniger vertraulichen Diensten abzugrenzen. Auch können Drittanbieterdienste (weniger vertrauenswürdig) auf separaten Infrastrukturen als eigene (vertrauenswürdige) Dienste (Cluster) ausgeführt werden.
Mandantentrennung
Die Trennung von Mandanten in mehrere Cluster wird aus verschiedenen Gründen häufig durchgeführt, darunter Sicherheitsisolation, Leistungsisolation, Kostenrechnung und sogar Eigentümerschaft.
Standort
Latenz
Einige Dienste haben Latenzanforderungen, die erfüllt werden müssen. Dafür wird eine Arbeitslast an einem bestimmten Standort (oder in einer geografischen Region) gesucht. Dies kann passieren, wenn vorgelagerte Dienste oder Endnutzer empfindlich auf Latenz reagieren, aber auch wenn die Arbeitslast selbst empfindlich auf nachgelagerte Dienstlatenz reagiert.
Verfügbarkeit
Wenn Sie denselben Dienst in mehreren Verfügbarkeitszonen von einem einzelnen Cloud-Anbieter (oder über mehrere Anbieter) ausführen, können Sie eine höhere Verfügbarkeit erzielen.
Rechtsprechung
Datenstandort und andere rechtliche Bestimmungen in Bezug auf die Datenverarbeitung können dazu führen, dass Computing und Speicher in einer bestimmten Region leben müssen, sodass die Infrastruktur in mehreren Rechenzentren oder Cloud-Anbietern bereitgestellt werden muss.
Datengravitation
Es kann schwierig, unrealistisch oder gar nicht empfehlenswert sein, einen großen Korpus von Daten oder sogar Datenbankinstanzen über einen einzelnen Cloud-Anbieter oder eine einzelne Cloud-Region zusammenzuführen. Abhängig von den Verarbeitungs- und Bereitstellungsanforderungen muss eine Anwendung möglicherweise in der Nähe ihrer Daten bereitgestellt werden.
Legacy-Infrastruktur/Dienste
So wie das Verschieben von Daten in die Cloud schwierig sein kann, ist auch das Verschieben einiger Legacy-Infrastrukturen schwierig. Obwohl diese Legacy-Dienste unflexibel sind, können Unternehmen über die Bereitstellung zusätzlicher Cluster für die Entwicklung neuer Dienste die Entwicklungsgeschwindigkeit erhöhen.
Entwicklerauswahl
Organisationen profitieren häufig, wenn sie Entwicklerauswahl bei von ihnen verwalteten Cloud-Diensten bieten. Im Allgemeinen können Teams bei einer Auswahl schneller mit Tools arbeiten, die sich am besten für ihre Bedürfnisse eignen. Allerdings müssen dann zusätzliche Ressourcen für jeden Anbieter verwaltet werden.
Lokale/Edge-Computing-Anforderungen Schließlich möchten Unternehmen die Modernisierung von Anwendungen in herkömmlichen Arbeitsumgebungen wie Lagerhallen, Fabrikgebäuden, Einzelhandelsgeschäften usw. anpassen. Dazu müssen Sie viel mehr Arbeitslasten auf viel mehr Infrastrukturkomponenten verwalten.
Skalieren
Da GKE Cluster auf mehr als 5.000 Knoten skalieren kann, sind diese Grenzen selten ein Grund, mehrere Cluster zu betreiben. Bevor ein Cluster an die Grenzen der Skalierbarkeit stößt, entscheiden sich Unternehmen häufig für eine Verteilung der Dienste auf mehrere Cluster. Bei Clustern, die an die Grenzen der Skalierbarkeit stoßen, kann die Ausführung einer Anwendung über mehrere Cluster einige Herausforderungen erleichtern, allerdings mit der zusätzlichen Komplexität der Verwaltung mehrerer Cluster.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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."]]
