Auf dieser Seite wird ausführlich erläutert, wie Sie mit Flotten Multi-Cluster-Bereitstellungen verwalten, einschließlich einiger wichtiger Begriffe und Konzepte für Flotten. Flotten sind ein Google Cloud Konzept für die logische Organisation von Clustern und anderen Ressourcen, mit dem Sie Multi-Cluster-Funktionen nutzen und verwalten sowie einheitliche Richtlinien auf Ihre Systeme anwenden können. Flotten sind ein wesentlicher Bestandteil der Multi-Cluster-Funktionalität in Google Cloud.
Der Leitfaden richtet sich an technisch orientierte Leser, darunter Systemarchitekten, Plattformbetreiber und Dienstbetreiber, die mehrere Cluster und die zugehörige Infrastruktur nutzen möchten. Die Konzepte sind überall dort hilfreich, wo in Ihrer Organisation mehrere Cluster ausgeführt werden, ob inGoogle Cloud, für mehrere Cloud-Anbieter oder lokal.
Bevor Sie diese Seite lesen, sollten Sie mit grundlegenden Kubernetes-Konzepten wie Clustern und Namespaces vertraut sein. Ist dies nicht der Fall, finden Sie entsprechende Informationen unter Kubernetes-Grundlagen, in der GKE-Dokumentation und unter Anwendung für Cloud Service Mesh vorbereiten.
Terminologie
Im Folgenden finden Sie einige wichtige Begriffe, die im Zusammenhang mit Flotten verwendet werden.
Flottenfähige Ressourcen
Flottenfähige Ressourcen sind Google Cloud Projektressourcen, die logisch als Flotten gruppiert und verwaltet werden können. Derzeit können nur Kubernetes-Cluster Flottenmitglieder sein.
Flotten-Hostprojekt
Die Implementierung von Flotten erfolgt wie bei vielen anderen Google Cloud -Ressourcen in einem Google Cloud -Projekt, das als Flottenhostprojekt bezeichnet wird. Einem Google Cloud -Projekt kann maximal eine einzige Flotte zugeordnet sein. Diese Einschränkung fördert die Nutzung von Google Cloud -Projekten, um Ressourcen stärker zu trennen, die nicht gemeinsam gesteuert oder genutzt werden.
Infrastruktur gruppieren
Das erste zentrale Konzept für Flotten ist das Konzept der Gruppierung. Dabei wird ausgewählt, welche Elemente von zugehörigen Flottenfähigen Ressourcen Teil einer Flotte sein sollen. Um festzulegen, welche Elemente gruppiert werden, müssen folgende Fragen beantwortet werden:
- Sind die Ressourcen miteinander verbunden?
- Ressourcen mit einem hohen Maß an dienstübergreifender Kommunikation profitieren am meisten von der gemeinsamen Verwaltung in einer Flotte.
- Ressourcen in derselben Bereitstellungsumgebung (z. B. Ihre Produktionsumgebung) sollten in einer Flotte zusammen verwaltet werden.
- Wer verwaltet die Ressourcen?
- Eine einheitliche (oder zumindest als vertrauenswürdig eingestufte) Kontrolle der Ressourcen ist entscheidend für die Gewährleistung der Integrität der Flotte.
Zur Veranschaulichung dieses Aspekts betrachten wir eine Organisation mit mehreren Geschäftszweigen (Lines of Business, LOBs). In einem solchen Fall kommunizieren Dienste selten über LOB-Grenzen hinweg. Die Dienste in den verschiedenen LOBs werden in der Regel unterschiedlich verwaltet (z. B. können sich die Upgrade-Phasen von LOBs unterscheiden) und haben möglicherweise auch unterschiedliche Administratoren für jede LOB. In diesem Fall kann es sinnvoll sein, Flotten LOB-weise zu verwenden. Außerdem ist es möglich, dass jede LOB mehrere Flotte verwendet, um die Produktions- und Nicht-Produktionsdienste voneinander zu trennen.
In den folgenden Abschnitten werden weitere Flottenkonzepte erläutert. Je nach den spezifischen Anforderungen an Ihre Organisation kann es weitere Gründe für das Erstellen mehrerer Flotten geben.
Gleichheit
Ein wichtiges Konzept bei Flotten ist das Konzept der Gleichheit. Das bedeutet, dass bei der Verwendung bestimmter für Flotten aktivierter Funktionen einige Kubernetes-Objekte, z. B. Namespaces, mit demselben Namen in verschiedenen Clustern so behandelt werden, als wären sie identisch. Diese Normalisierung vereinfacht die Verwaltung von Flottenressourcen. Wenn Sie Funktionen verwenden, die auf Gleichheit basieren, bietet diese Annahme der Gleichheit einige gute Anleitungen zur Einrichtung von Namespaces, Diensten und Identitäten. Dabei wird auch berücksichtigt, was die meisten Organisationen selbst implementieren.
Die verschiedenen Arten von Übereinstimmung bieten unterschiedliche Vorteile, wie in der folgenden Tabelle dargestellt:
| Gleichheit | Ermöglicht... |
|---|---|
| Ein Namespace wird in mehreren Clustern als identisch betrachtet. |
|
| Eine Kombination aus Namespace und Dienstname wird in mehreren Clustern als identisch betrachtet. Dienste mit demselben Namen im selben Namespace verwenden denselben Label-Selektor. |
|
| Eine Kombination aus Namespace und Dienstkonto (Identität) wird in mehreren Clustern als identisch betrachtet. |
|
Wie bereits erwähnt, basieren verschiedene Flottenfunktionen auf unterschiedlichen Arten von Gleichheit. Bei einer kleineren Anzahl von Funktionen wird Gleichheit überhaupt nicht verwendet. Weitere Informationen dazu finden Sie unter Bei welchen Funktionen wird Gleichheit verwendet?. Dort erfahren Sie auch, welche Funktionen Sie verwenden können, ohne die flottenweite Gleichheit zu berücksichtigen, und welche Funktionen eine sorgfältigere Planung erfordern.
Namespace-Gleichheit
Das grundlegende Beispiel für Gleichheit in einer Flotte ist die Namespace-Gleichheit. Namespaces mit dem gleichen Namen in unterschiedlichen Clustern werden von vielen Flottenfunktionen als identisch eingestuft. Für dieses Attribut muss beachtet werden, dass ein Namespace logisch für eine komplette Flotte definiert wird, auch wenn die Instanziierung des Namespace nur in einer Teilmenge der Flottenressourcen erfolgt.
Betrachten wir das folgende backend-Namespace-Beispiel. Obwohl der Namespace nur in den Clustern A und B instanziiert wird, wird er implizit für Cluster C reserviert (damit ist es erlaubt, dass ein Dienst im Namespace backend auch in Cluster C terminiert wird, falls nötig).
Dies bedeutet, dass Namespaces der gesamten Flotte und nicht einzelnen Cluster zugewiesen werden. Daher erfordert die Namespace-Gleichheit einheitliche Namespace-Eigentumsrechte in der gesamten Flotte.
Dienstgleichheit
Cloud Service Mesh und Multi-Cluster-Ingress nutzen das Prinzip der Gleichheit von Diensten innerhalb eines Namespace. Ebenso wie bei der Namespace-Gleichheit bedeutet dies, dass Dienste mit dem gleichen Namespace und Dienstnamen als ein Dienst behandelt werden.
Die Dienstendpunkte können im Fall von Cloud Service Mesh für das gesamte Netzwerk zusammengeführt werden. Bei Multi-Cluster-Ingress macht eine MCS-Ressource (MultiClusterService) das Zusammenführen der Endpunkte expliziter. Wir empfehlen aber die Verwendung ähnlicher Verfahren unter Berücksichtigung der Benennung. Deshalb sollten Sie dafür sorgen, dass identisch benannte Dienste innerhalb eines Namespace tatsächlich identisch sind.
Im folgenden Beispiel wird für den Internettraffic über einen gleichnamigen Dienst im Namespace frontend ein Load-Balancing in den Clustern B und C ausgeführt. Ebenso kann der Dienst im Namespace frontend mithilfe der Service Mesh-Attribute innerhalb der Flotte den identisch benannten Dienst im Namespace auth in den Clustern A und C erreichen.
Identitätsgleichheit beim Zugriff auf externe Ressourcen
Mit der Identitätsföderation von Arbeitslasten für die Flotte können Dienste innerhalb einer Flotte eine gemeinsame Identität nutzen, wenn sie auf externe Ressourcen wie Google Cloud -Dienste, Objektspeicher usw. zugreifen. Diese gemeinsame Identität ermöglicht es den Diensten in einer Flotte einmal auf eine externe Ressource und nicht auf jeden Cluster einzeln zuzugreifen.
Das folgende Beispiel veranschaulicht diesen Aspekt. Die Cluster A, B und C sind mit einer gemeinsamen Identität innerhalb ihrer Flotte registriert. Wenn Dienste im Namespace backend auf Google Cloud Ressourcen zugreifen, werden ihre Identitäten einem gemeinsamen Google Cloud Dienstkonto namens back zugeordnet. DasGoogle Cloud -Dienstkonto back kann von beliebig vielen verwalteten Diensten autorisiert werden, von Cloud Storage bis Cloud SQL. Wenn neue Flottenressourcen wie Cluster zum Namespace backend hinzugefügt werden, übernehmen sie automatisch die Gleichheitsattribute der Arbeitslastidentität.
Aufgrund der Identitätsgleichheit ist es wichtig, dass alle Ressourcen in einer Flotte vertrauenswürdig sind und richtig kontrolliert werden. Wenn im vorherigen Beispiel Cluster C zu einem separaten, nicht vertrauenswürdigen Team gehört, kann dieses auch einen backend-Namespace erstellen und auf verwaltete Dienste zugreifen, als wäre es backend in Cluster A oder B.
Identitätsgleichheit innerhalb einer Flotte
Die Identitätsgleichheit wird innerhalb der Flotte wie die zuvor erläuterte externe Identitätsgleichheit angewendet. So wie Flotten-Dienste einmal für einen externen Dienst autorisiert werden, können sie ebenfalls intern autorisiert werden.
Im folgenden Beispiel wird Cloud Service Mesh verwendet, um ein Multi-Cluster-Service Mesh zu erstellen, in dem frontend Zugriff auf backend hat.
Bei Cloud Service Mesh und Flotten müssen Sie nicht angeben, dass frontend in den Clustern B und C auf backend in den Clustern A und B zugreifen kann. Stattdessen geben wir einfach an, dass frontend in der Flotte auf backend in der Flotte zugreifen kann. Durch dieses Attribut wird nicht nur die Autorisierung einfacher, auch die Ressourcengrenzen werden flexibler. Arbeitslasten können jetzt ganz einfach von Cluster zu Cluster verschoben werden, ohne dass sich dies auf ihre Autorisierung auswirkt. Wie bei der Gleichheit der Workload Identity ist die Governance der Flottenressourcen für die Integrität der Dienst-zu-Dienst-Kommunikation entscheidend.
Bei welchen Funktionen wird Gleichheit verwendet?
Eine Reihe von Flottenfunktionen basieren überhaupt nicht auf Gleichheit und können aktiviert und verwendet werden, ohne dass Sie berücksichtigen müssen, ob Sie eine Form von Gleichheit in Ihrer Flotte annehmen möchten. Andere Funktionen (einschließlich Config Sync und Policy Controller) können die Gleichheit verwenden, z. B. wenn Sie einen Namespace in mehreren Flottenmitgliedsclustern für die Konfiguration aus einer Single Source of Truth auswählen möchten. Sie ist jedoch nicht für alle Anwendungsfälle erforderlich. Schließlich gibt es Features wie Multi-Cluster-Ingress und flottenweite Identitätsföderation von Arbeitslasten, die immer eine Form von Gleichheit zwischen Clustern annehmen und möglicherweise je nach Ihren Anforderungen und vorhandenen Arbeitslasten sorgfältig angewendet werden müssen.
Einige Flottenfeatures (z. B. Identitätsföderation von Arbeitslasten für Flotten) erfordern, dass Ihre gesamte Flotte auf die Annahmen der verwendeten Gleichheit vorbereitet ist. Andere Funktionen wie die Teamverwaltung ermöglichen es Ihnen, die Gleichheit schrittweise auf Namespace- oder Teambereichsebene zu aktivieren.
In der folgenden Tabelle sehen Sie, für welche Funktionen eines oder mehrere der in diesem Abschnitt beschriebenen Konzepte für die Gleichheit erforderlich sind.
| Funktion | Unterstützt die schrittweise Einführung von „Gleichheit“ | Abhängig von der Namespace-Gleichheit | Abhängig von der Ähnlichkeit der Dienste | Abhängig von der Identitätsgleichheit |
|---|---|---|---|---|
| Flotten | – | Nein | Nein | Nein |
| Binärautorisierung | – | Nein | Nein | Nein |
| Transparente Verschlüsselung zwischen Knoten | – | Nein | Nein | Nein |
| Netzwerkrichtlinie auf Grundlage von vollständig qualifizierten Domainnamen | – | Nein | Nein | Nein |
| Connect-Gateway | – | Nein | Nein | Nein |
| Config Sync | – | Nein | Nein | Nein |
| Policy Controller | – | Nein | Nein | Nein |
| GKE-Sicherheitsstatus | – | Nein | Nein | Nein |
| Advanced Vulnerability Insights | – | Nein | Nein | Nein |
| Compliancestatus | – | Nein | Nein | Nein |
| Roll-out-Sequenzierung | – | Nein | Nein | Nein |
| Teamverwaltung | Ja | Ja | Ja | Nein |
| Multi-Cluster-Ingress | Ja | Ja | Ja | Ja |
| Multi-Cluster-Dienste | Ja | Ja | Ja | Ja |
| Identitätsföderation von Arbeitslasten für Flotten | Nein | Ja | Ja | Ja |
| Cloud Service Mesh | Nein | Ja | Ja | Ja |
Exklusivität
Flottenfähige Ressourcen können jeweils immer nur einer einzigen Flotte angehören. Diese Beschränkung wird von Google Cloud -Tools und -Komponenten erzwungen. Sie gewährleistet, dass es für die Steuerung eines Clusters nur eine einzige Quelle gibt. Ohne Exklusivität werden selbst die einfachsten Komponenten zu komplex für die Verwendung. Ihre Organisation müsste dann festlegen, wie verschiedene Komponenten aus verschiedenen Flotten miteinander kommunizieren.
Hohe Vertrauensebene
Dienstgleichheit, Gleichheit der Arbeitslastidentität und Gleichheit der Mesh- Identität basieren auf dem Prinzip einer hohen Vertrauensebene zwischen Mitgliedern einer Flotte. Dieses Vertrauen ermöglicht eine optimierte Verwaltung dieser Ressourcen für die gesamte Flotte, anstatt sie ressourcenweise zu verwalten, also clusterweise für Kubernetes-Ressourcen. Außerdem spielen dann auch Clustergrenzen eine geringere Rolle.
Anders ausgedrückt bieten Cluster innerhalb einer Flotte Schutz vor „Blast-Radius“-Problemen, Verfügbarkeit (sowohl der Steuerungsebene als auch der zugrunde liegenden Infrastruktur), Schutz vor Noisy Neighbor-Effekten und vieles mehr. Sie bilden jedoch keine strikte Trenngrenze für Richtlinien und Governance, da Administratoren eines Mitglieds in einer Flotte den Betrieb der Dienste in anderen Mitgliedern der Flotte potenziell beeinflussen können.
Aus diesem Grund empfehlen wir, dass Clustern, die vom Flotten-Administrator als nicht vertrauenswürdig eingestuft werden, in einer eigenen Flotte platziert werden, um sie zu isolieren. Bei Bedarf können einzelne Dienste über die Flotten-Grenze hinaus autorisiert werden.
Teambereiche
Ein Teambereich ist ein Mechanismus, um Ihre Flotte weiter in Gruppen von Clustern zu unterteilen. So können Sie die flottenfähigen Ressourcen definieren, die einem bestimmten Anwendungsteam zugewiesen sind. Je nach Anwendungsfall kann ein einzelner Cluster mit einem Flottenmitglied ohne Teams, einem Team oder mehreren Teams zugeordnet werden, sodass mehrere Teams Cluster gemeinsam nutzen können. Sie können Teambereiche auch verwenden, um Rollouts von Sequenz-Clusterupgrades in Ihrer gesamten Flotte zu sequenzieren. Dies erfordert jedoch, dass jeder Cluster nur einem einzelnen Team zugeordnet ist.
Einem Teambereich können explizit definierte Flotten-Namespaces zugeordnet sein, wobei der Namespace im gesamten Bereich als identisch betrachtet wird. Auf diese Weise haben Sie eine genauere Kontrolle über Namespaces als die standardmäßige Namespace-Gleichheit, die allein von Flotten bereitgestellt wird.
Flottenbasierte Komponenten
Die im Folgenden aufgeführten Komponenten basieren auf Flotten-Konzepten wie Namespace- und Identitätsgleichheit, die die Arbeit mit Clustern und Diensten vereinfachen sollen. Informationen zu den aktuellen Anforderungen oder Einschränkungen für die Verwendung von Flotten mit den einzelnen Komponenten finden Sie unter Komponentenanforderungen.
Workload Identity-Pools
Eine Flotte bietet einen gemeinsamen Workload Identity-Pool, der zur einheitlichen Authentifizierung und Autorisierung von Arbeitslasten innerhalb eines Service Mesh und an externe Dienste verwendet werden kann.Cloud Service Mesh
Cloud Service Mesh besteht aus einer Reihe von Tools, mit denen Sie ein zuverlässiges Service Mesh in Google Cloud, lokal und in anderen unterstützten Umgebungen überwachen und verwalten können. Sie können ein Service Mesh für alle Cluster bilden, die Teil derselben Flotte sind.Config Sync
Mit Config Sync können Sie deklarative Konfigurationspakete für Ihr System bereitstellen und überwachen, die in einer zentralen "Source of Truth" wie einem Git-Repository gespeichert sind, und zwar mithilfe von Core Kubernetes-Konzepte wie Namespaces, Labels und Annotationen. Mit Config Sync wird Konfigurationen für die gesamte Flotte definiert, aber lokal in jeder Mitgliederressource angewendet und erzwungen.Policy Controller
Mit Policy Controller können Sie deklarative Richtlinien für Ihre Kubernetes-Cluster anwenden und erzwingen. Richtlinien dienen als Schutzmaßnahmen und können Sie beim Verwalten von Best Practices, der Sicherheit und der Compliance in Ihren Clustern und Ihrer Flotte unterstützen.Multi-Cluster-Ingress
Multi-Cluster-Ingress verwendet die Flotte, um Cluster und Dienstendpunkte zu definieren, für die ein Load-Balancing des Traffics erfolgen kann. Dies ermöglicht eine niedrige Latenz und Dienste mit Hochverfügbarkeit.
Nächste Schritte
- Weitere Informationen dazu, wann es sich empfiehlt, mehrere Cluster zu verwenden, um Ihre technischen und geschäftlichen Anforderungen zu erfüllen, finden Sie unter Multi-Cluster-Anwendungsfälle.
- Möchten Sie diese Konzepte für Ihre Systeme anwenden? Weitere Informationen finden Sie unter Flottenressourcen planen.