Die Beispiele auf dieser Seite zeigen einige hypothetische Szenarien mit Flotten, die einige Konzepte und Best Practices aus unseren Leitfäden veranschaulichen. Bevor Sie diesen Leitfaden lesen, sollten Sie mit den Konzepten in Einführung in Flotten und Flottenanforderungen und Best Practices vertraut sein.
Beispiel 1: Flotten mit Produktions-, Staging- und Entwicklungsressourcen
In diesem ersten Beispiel gibt es vier Cluster. Zwei Cluster sind für die Produktion bestimmt (in zwei Regionen für die Redundanz), ein weiterer für Staging und Tests und der letzte für die Entwicklung. Alle Cluster sind im Besitz eines Plattformteams und werden zentral von diesem verwaltet. In diesem einfachen Beispiel gibt es zwei Dienste: frontend und backend. Komplexere Szenarien können jedoch eine größere Anzahl von Diensten und Clustern haben.
Ansatz 1: Separate Flotten für Produktion, Staging und Entwicklung
Ein möglicher Ansatz zur Nutzung von Flotten besteht darin, separate Flotten für Produktions-, Staging- und Entwicklungsressourcen zu erstellen.
Dazu erstellen wir drei separate Flotten-Hostprojekte und platzieren entweder Ressourcen in diesen Projekten oder registrieren im Falle unseres lokalen Entwicklungsclusters den Cluster für das Projekt example-dev. Aufgrund des Detaillierungsgrads haben wir in diesem Beispiel nicht auf die Gleichheit der Namespaces und Dienste geachtet, wir haben aber sichergestellt, dass die Namespaces der prod-east- und prod-west-Cluster gut normalisiert sind.
Der Vorteil dieses Ansatzes ist, dass wir eine starke Isolation zwischen den einzelnen Flotten haben. Der Hauptnachteil dieses Ansatzes besteht darin, dass wir drei verschiedene Flotten verwalten müssen, was das Erreichen einer Konsistenz zwischen Produktion, Staging und Entwicklung erschwert. Für Entwicklungsteams ist es auch schwieriger, gegen Dienste im Staging zu entwickeln.
Ansatz 2: Eine Flotte für alle Ressourcen
Bei diesem Ansatz erstellen wir eine Flotte für alle Ressourcen.
Dazu können wir die Ressourcen im Projekt example belassen und die Flotte in diesem Projekt erstellen. Wir hätten unsere Produktions- und Staging-Ressourcen durch Platzieren in andere Flotten-Hostprojekte trennen können und eine freigegebene VPC verwenden können. In diesem Beispiel haben wir aber aus Gründen der Einfachheit darauf verzichtet.
Bei diesem Ansatz müssen wir sicherstellen, dass unsere Namespaces und Dienste innerhalb der Flotte normalisiert sind. Beispielsweise benennen wir unser generisches frontend in den Produktions- und Staging-Clustern in frontend-prod und frontend-staging um. Schließlich könnten wir zwar die ursprünglichen Namen für unsere Entwicklungs-Namespaces beibehalten, aber wir vergeben eindeutigere Namen (wie frontend-dev-alice), damit klar ist, dass es sich um Entwicklungs-Namespaces handelt.
Bei diesem Ansatz tauschen wir die Isolation gegen eine einfachere Verwaltung ein. Wir müssen die Service Mesh-Autorisierung nutzen, um unerwünschte Dienst-zu-Dienst-Kommunikation zu verhindern, können aber das gesamte System mit der einen Flotte problemlos verwalten. Eine solche Anordnung erlaubt es, Richtlinien auf alle Ressourcen anzuwenden. So können wir sicher sein, dass sich die Entwicklung genau so verhält wie die Produktion.
Ansatz 3: Separate Flotten für Produktion und Nicht-Produktion
Bei diesem Ansatz verwenden wir einen Mittelweg, der die Staging- und Entwicklungsressourcen in einer Nicht-Produktions-Flotte vereint und die Produktion in einer separaten Flotte bereitstellt.
Dazu erstellen wir zwei Flotten-Hostprojekte: eins für den Produktionsbereich und eins für den Nicht-Produktionsbereich. Außerdem ordnen wir unsere Ressourcen direkt den Projekten zu, bei denen der dev-Cluster lokal in unserer Nicht-Produktions-Flotte registriert ist. Wir müssen die Namespaces und Dienste zwischen unseren Staging- und Entwicklungsressourcen normalisieren, um für mehr Übersichtlichkeit zu sorgen. Zum Beispiel benennen wir frontend im Staging-Cluster in frontend-staging um.
Der Vorteil besteht darin, dass die Produktion von der Nicht-Produktion getrennt ist. Beispielsweise können wir Entwicklungsdienste für die Kommunikation mit Staging-Diensten aktivieren. Dann kann das frontend der Entwicklerin Alice mit einem backend im Staging kommunizieren, während sie ihren Dienst entwickelt.
Fazit
Jeder in Beispiel 1 beschriebene Ansatz ist richtig. Welche Variante für Ihre Organisation geeignet ist, hängt von der Isolation gegenüber der Konsistenz (und einfachen Verwaltung) ab; also je nachdem, wie viel Isolation zwischen unterschiedlichen Ressourcentypen erforderlich ist und wie viel Konsistenz benötigt wird. Mehr Konsistenz ist mit weniger Flotten leichter zu erreichen. Der dritte Ansatz stellt einen möglichen Kompromiss dar, der die Produktion vollständig isoliert hält und den Entwicklern die Möglichkeit gibt, gegen Staged-Dienste zu arbeiten.
Beispiel 2: Flotten mit unterschiedlichen Ressourceninhabern
Für dieses Beispiel haben wir zwei Teams, Team A und Team B. Diese Teams besitzen und verwalten ihre eigenen Cluster und haben beide die Namespaces frontend und backend für die von ihnen erzeugten Dienste verwendet. Allerdings sind weder frontend noch backend von Team A identisch mit Team B. Die beiden Teams möchten ein Service Mesh erstellen, damit ihre Dienste interagieren können.
Diese Cluster können nicht ohne Weiteres zu einem Teil desselben Mesh-Netzwerks gemacht werden. Ein guter Ausgangspunkt ist das Übertragen der Clustereigentümerschaft an ein zentralisiertes Plattformteam, um das Vertrauen untereinander zu fördern. Wenn sich Team A und Team B einander vertrauen, können sie sich alternativ auch koordinieren, um dieses Vertrauen zu bilden.
Im nächsten Schritt wird die Namespace-Verwendung normalisiert damit frontend und backend nicht mehr in den Clustern dieser beiden Teams überlastet sind. Anschließend können sie eine Flotte für alle Ressourcen einrichten und das Service Mesh erstellen.
Wenn sich diese Vertrauensebene nicht erreichen lässt, sollten Team A und Team B zwei separate Flotten bilden, in denen zwei unterschiedliche Flotten-Hostprojekte genutzt werden. Der Nachteil bei diesem Ansatz ist, dass sie jetzt die Mesh-Föderation nutzen müssen, die sich schwerer als ein einzelnes Mesh-Netzwerk verwalten lässt. Der Vorteil besteht darin, dass kein Team die bereitgestellten Namespaces und Dienste normalisieren muss und nur die explizite und ausdrücklich autorisierte Kommunikation möglich ist.
