Anmerkung des Übersetzers.: Dieses Material stammt aus einem Bildungsprojekt — eine Antwort auf die häufige Frage beim Entwerfen einer Infrastruktur auf Basis von Kubernetes. Wir hoffen, dass die ausreichend ausführlichen Beschreibungen der Vor- und Nachteile jeder Option Ihnen helfen, eine optimale Entscheidung auch für Ihr Projekt zu treffen.
TL;DR: derselbe Satz von Workloads kann auf mehreren großen Clustern ausgeführt werden (auf jeden Cluster werden viele Workloads verteilt) oder auf vielen kleinen (mit wenigen Workloads in jedem Cluster).
Nachfolgend finden Sie eine Tabelle, die die Vor- und Nachteile jedes Ansatzes bewertet:
Bei der Verwendung von Kubernetes als Plattform für den Betrieb von Anwendungen tauchen oft mehrere grundlegende Fragen zur Feinabstimmung von Clustern auf:
- Wie viele Cluster sollen verwendet werden?
- Wie groß sollen sie sein?
- Was soll jeder Cluster beinhalten?
In diesem Artikel versuche ich, all diese Fragen zu beantworten, indem ich die Vor- und Nachteile jedes Ansatzes analysiere.
Die Fragestellung
Als Softwareentwickler entwickeln und betreiben Sie wahrscheinlich gleichzeitig viele Anwendungen.
Außerdem werden viele Instanzen dieser Anwendungen sicherlich in verschiedenen Umgebungen gestartet – zum Beispiel könnten dies sein dev, test und prod.
Infolgedessen ergibt sich eine gesamte Matrix von Anwendungen und Umgebungen:
Anwendungen und Umgebungen
Im obigen Beispiel sind 3 Anwendungen und 3 Umgebungen dargestellt, was insgesamt 9 mögliche Szenarien ergibt.
Jede Instanz einer Anwendung ist eine autarke Deployment-Einheit, mit der unabhängig von anderen gearbeitet werden kann.
Beachten Sie, dass Instanz einer Anwendung kann aus mehreren Komponentenbestehen, wie Frontend, Backend, Datenbank usw. Bei einer Mikrodiensten-Anwendung würde die Instanz alle Mikrodienste umfassen.
Infolgedessen haben Benutzer von Kubernetes mehrere Fragen:
- Sollten alle Instanzen einer Anwendung in einem Cluster betrieben werden?
- Sollte für jede Instanz einer Anwendung ein separater Cluster eingerichtet werden?
- Oder sollte vielleicht eine Kombination der oben genannten Ansätze genutzt werden?
All diese Optionen sind durchaus machbar, denn Kubernetes ist ein flexibles System, das dem Benutzer keine Möglichkeiten nimmt.
Hier sind einige mögliche Ansätze:
- ein großer gemeinsamer Cluster;
- viele kleine, spezialisierte Cluster;
- ein Cluster pro Anwendung;
- ein Cluster pro Umgebung.
Wie unten gezeigt, liegen die ersten beiden Ansätze an den entgegengesetzten Enden des Spektrums:
Von wenigen großen Clustern (links) bis zu vielen kleinen (rechts)
Im Allgemeinen wird ein Cluster als „größer“ als ein anderer betrachtet, wenn er mehr Knoten und Pods hat. Zum Beispiel ist ein Cluster mit 10 Knoten und 100 Pods größer als ein Cluster mit 1 Knoten und 10 Pods.
Nun, lassen Sie uns anfangen!
1. Ein großer gemeinsamer Cluster
Die erste Option besteht darin, alle Workloads in einem Cluster zu hosten:
Ein großer Cluster
Im Rahmen dieses Ansatzes wird der Cluster als universelle Infrastrukturplattform verwendet – alles Notwendige wird einfach in dem bestehenden Kubernetes-Cluster bereitgestellt.
In Kubernetes können Teile des Clusters logisch voneinander getrennt werden, sodass für jede Instanz der Anwendung ein eigenes Namensraum verwendet werden kann.
Lassen Sie uns die Vor- und Nachteile dieses Ansatzes betrachten.
+ Effiziente Ressourcennutzung
Im Falle eines einzigen Clusters wird nur eine Kopie aller Ressourcen benötigt, die notwendig sind, um einen Kubernetes-Cluster zu starten und zu verwalten.
Das gilt zum Beispiel für die Master-Knoten. Normalerweise gibt es für jeden Kubernetes-Cluster 3 Master-Knoten, sodass für einen einzelnen Cluster deren Anzahl gleich bleibt (zum Vergleich: 10 Cluster benötigen 30 Master-Knoten).
Dieses Detail gilt auch für andere Dienste, die im gesamten Cluster betrieben werden, wie Lastenausgleicher, Ingress-Controller, Authentifizierungssysteme, Protokollierung und Monitoring.
In einem einzigen Cluster können all diese Dienste sofort für alle Workloads verwendet werden (es müssen keine Kopien erstellt werden, wie im Fall mehrerer Cluster).
+ Kosteneffizienz
Daraus ergibt sich, dass eine geringere Anzahl von Clustern normalerweise günstiger ist, da die Ausgaben für überflüssige Ressourcen entfallen.
Das gilt insbesondere für Master-Knoten, die erhebliche Kosten verursachen können, unabhängig von der Art der Bereitstellung (On-Premises oder in der Cloud).
Einige verwaltete Kubernetes-Dienste wie oder , bieten eine verwaltete Schicht kostenlos an. In diesem Fall sind die Kosten weniger kritisch.
Es gibt auch verwaltete Dienste, die eine feste Gebühr für die Arbeit jedes Kubernetes-Clusters erheben (z. B. ).
+ Effektive Verwaltung
Einen Cluster zu verwalten, ist einfacher als mehrere.
Die Verwaltung kann folgende Aufgaben umfassen:
- Aktualisierung der Kubernetes-Version;
- Einrichtung der CI/CD-Pipeline;
- Installation des CNI-Plugins;
- Konfiguration des Benutzerauthentifizierungssystems;
- Installation des Zugangscontrollers;
und viele andere …
Im Fall eines Clusters muss man sich nur einmal um all dies kümmern.
Bei mehreren Clustern müssen die Operationen jedoch mehrfach wiederholt werden, was wahrscheinlich eine gewisse Automatisierung der Prozesse und Werkzeuge erfordert, um Systematik und Einheitlichkeit zu gewährleisten.
Jetzt ein paar Worte zu den Nachteilen.
− Einzelner Ausfallpunkt
Im Falle eines Ausfalls des einzigen Clusters werden sofort Ressourcen) abgeschlossen ist, lösen wir alle Arbeitslasten nicht mehr funktionieren!
Es gibt viele Möglichkeiten, wie etwas schiefgehen kann:
- Das Upgrade von Kubernetes führt zu unerwarteten Nebenwirkungen;
- Ein Clusterkomponente (z. B. ein CNI-Plugin) funktioniert nicht wie erwartet;
- Eine der Clusterkomponenten ist falsch konfiguriert;
- Ein Ausfall der zugrunde liegenden Infrastruktur.
Ein solcher Vorfall kann allen Arbeitslasten, die im gemeinsamen Cluster gehostet werden, erheblichen Schaden zufügen.
− Fehlende strikte Isolierung
Die Arbeit in einem gemeinsamen Cluster bedeutet, dass Anwendungen die Hardware, Netzwerkmöglichkeiten und das Betriebssystem auf den Clusterknoten gemeinsam nutzen.
In gewisser Weise sind zwei Container mit zwei verschiedenen Anwendungen, die auf demselben Knoten laufen, ähnlich wie zwei Prozesse, die auf demselben Computer unter demselben Betriebssystem-Kernel laufen.
Linux-Container bieten eine gewisse Form der Isolation, aber sie ist bei weitem nicht so stark wie die einer virtuellen Maschine. Im Wesentlichen ist ein Prozess im Container derselbe Prozess, der im Hostbetriebssystem ausgeführt wird.
Dies kann aus Sicherheitssicht problematisch sein: Eine solche Anordnung ermöglicht theoretisch, dass nicht verbundene Anwendungen miteinander interagieren (ob absichtlich oder versehentlich).
Darüber hinaus nutzen alle Arbeitslasten im Kubernetes-Cluster gemeinsam einige clusterweite Dienste wie — dies ermöglicht es Anwendungen, die Services anderer Anwendungen im Cluster zu finden.
Die oben genannten Punkte können unterschiedliche Bedeutungen haben, abhängig von den an die Sicherheit der Anwendungen gestellten Anforderungen.
Kubernetes bietet verschiedene Werkzeuge zur Vermeidung von Problemen im Sicherheitssystem, wie und . Für ihre korrekte Einrichtung ist jedoch bestimmte Erfahrung erforderlich; zudem sind sie nicht in der Lage, alle Sicherheitslücken zu schließen.
Es ist wichtig, stets daran zu denken, dass Kubernetes ursprünglich für gemeinsame Nutzung, nicht für Isolation und Sicherheit.
− Keine strikte Multi-Tenancy
Angesichts der Fülle gemeinsamer Ressourcen im Kubernetes-Cluster gibt es viele Möglichkeiten, wie verschiedene Anwendungen "einander in die Quere kommen" können.
Zum Beispiel kann eine Anwendung eine bestimmte gemeinsame Ressource (wie CPU oder Speicher) monopolieren und anderen Anwendungen, die auf demselben Knoten laufen, den Zugriff darauf verwehren.
Kubernetes bietet verschiedene Mechanismen zur Kontrolle eines solchen Verhaltens, wie (! siehe auch den Artikel „“ — Anm. d. Ü.), und . Wie im Sicherheitsfall ist ihre Einrichtung jedoch relativ komplex, und sie können nicht alle unvorhergesehenen Nebenwirkungen verhindern.
− Eine große Anzahl von Benutzern
Bei einem einzelnen Cluster muss der Zugang für viele Personen geöffnet werden. Je mehr es sind, desto höher ist das Risiko, dass sie etwas „kaputtmachen“.
Innerhalb des Clusters kann kontrolliert werden, wer was tun kann, mithilfe von (! siehe den Artikel „“ — Anm. d. Ü.). Es wird jedoch nicht verhindern, dass Benutzer innerhalb ihres Verantwortungsbereichs etwas „kaputt machen“.
− Cluster können nicht unbegrenzt wachsen
Ein Cluster, der für alle Arbeitslasten verwendet wird, wird wahrscheinlich sehr groß sein (was die Anzahl der Knoten und Pods betrifft).
Aber hier entsteht ein weiteres Problem: Cluster in Kubernetes können nicht unbegrenzt wachsen.
Es gibt eine theoretische Grenze für die Größe eines Clusters. In Kubernetes liegt diese bei etwa .
In der Praxis können jedoch die Probleme viel früher beginnen — zum Beispiel schon bei .
Das Problem ist, dass große Cluster eine hohe Belastung für die Steuerungsebene von Kubernetes darstellen. Mit anderen Worten, um einen Cluster betriebsfähig zu halten und die Ressourcen effizient zu nutzen, ist eine sorgfältige Konfiguration erforderlich.
Dieses Problem wird in dem entsprechenden Artikel im Originalblog mit dem Titel „».
Aber betrachten wir den gegenteiligen Ansatz: viele kleine Cluster.
2. Viele kleine, spezialisierte Cluster
Bei diesem Ansatz verwenden Sie einen separaten Cluster für jedes bereitzustellende Element:
Viele kleine Cluster
Für die Zwecke dieses Artikels wird unter bereitzustellendes Element ein Anwendungsexemplar verstanden — zum Beispiel eine Entwicklungsversion einer separaten Anwendung.
In dieser Strategie wird Kubernetes als spezialisierte Laufzeitumgebung für einzelne Anwendungsinstanzen verwendet.
Lassen Sie uns die Vor- und Nachteile dieses Ansatzes betrachten.
+ Eingeschränkter
Radius der Auswirkungen
Im Falle eines „Ausfalls“ des Clusters sind die negativen Folgen auf die Arbeitslasten beschränkt, die in diesem Cluster bereitgestellt wurden. Alle anderen Workloads bleiben unberührt.
+ Isolierung
Arbeitslasten, die in separaten Clustern platziert sind, teilen sich keine gemeinsamen Ressourcen wie Prozessor, Speicher, Betriebssystem, Netzwerk oder andere Dienste.
Infolgedessen erhalten wir eine strenge Isolierung zwischen nicht verwandten Anwendungen, was sich positiv auf ihre Sicherheit auswirken kann.
+ Geringe Zahl an Nutzern
Da jeder Cluster nur eine begrenzte Anzahl an Arbeitslasten enthält, verringert sich die Anzahl der Nutzer, die darauf zugreifen können.
Je weniger Menschen Zugriff auf den Cluster haben, desto geringer ist das Risiko, dass etwas „kaputt geht“.
Schauen wir uns die Nachteile an.
- Ineffiziente Ressourcennutzung
Wie bereits erwähnt, benötigt jeder Kubernetes-Cluster eine bestimmte Menge an Steuerungsressourcen: Master-Knoten, Komponenten der Steuerungsebene, Überwachungs- und Protokollierungslösungen.
Bei einer großen Anzahl kleiner Cluster muss ein größerer Teil der Ressourcen für die Verwaltung aufgewendet werden.
Eine ineffiziente Ressourcennutzung führt automatisch zu hohen Kosten.
Zum Beispiel wird die Wartung von 30 Master-Knoten anstelle von drei bei gleicher Rechenleistung zwangsläufig Auswirkungen auf die Ausgaben haben.
− Schwierigkeiten bei der Verwaltung
Die Verwaltung einer Vielzahl von Kubernetes-Clustern ist viel komplizierter als die Arbeit mit einem einzigen.
Sie müssen zum Beispiel die Authentifizierung und Autorisierung für jedes Cluster einrichten. Auch die Aktualisierung der Kubernetes-Version wird mehrmals erforderlich sein.
Wahrscheinlich werden Sie Automatisierung anwenden müssen, um die Effizienz all dieser Aufgaben zu steigern.
Schauen wir uns jetzt weniger extreme Szenarien an.
3. Ein Cluster für jede Anwendung
Bei diesem Ansatz erstellen Sie einen separaten Cluster für alle Instanzen einer bestimmten Anwendung:
Cluster für die Anwendung
Dieser Weg kann als Verallgemeinerung des Prinzips „ein separater Cluster für jedes Team“ betrachtet werden, da normalerweise ein Team von Ingenieuren an der Entwicklung einer oder mehrerer Anwendungen arbeitet.
Lassen Sie uns die Vor- und Nachteile dieses Ansatzes betrachten.
+ Cluster können auf die Anwendung zugeschnitten werden
Wenn eine Anwendung besondere Anforderungen hat, können diese im Cluster umgesetzt werden, ohne andere Cluster zu beeinträchtigen.
Solche Anforderungen können Worker mit GPU, bestimmte CNI-Plugins, Service-Mesh oder irgendeinen anderen Dienst umfassen.
Jeder Cluster kann auf die Anwendung, die darin läuft, angepasst werden, damit er nur das enthält, was benötigt wird.
− Verschiedene Umgebungen in einem Cluster
Ein Nachteil dieses Ansatzes besteht darin, dass Instanzen von Anwendungen aus verschiedenen Umgebungen in einem Cluster koexistieren.
Zum Beispiel läuft die Produktionsversion einer Anwendung im selben Cluster wie die Entwicklungsversion. Dies bedeutet auch, dass die Entwickler in demselben Cluster arbeiten, in dem die Produktionsversion der Anwendung betrieben wird.
Wenn es aufgrund der Aktivitäten der Entwickler oder von Fehlern in der Entwicklungsversion zu einem Ausfall des Clusters kommt, könnte potenziell auch die Produktionsversion betroffen sein – ein erheblicher Nachteil dieses Ansatzes.
Und schließlich das letzte Szenario in unserer Liste.
4. Ein Cluster für jede Umgebung
Dieses Szenario sieht die Zuweisung eines separaten Clusters für jede Umgebung vor:
Ein Cluster für jede Umgebung
Zum Beispiel könnten Sie Cluster haben dev, test und prod, in denen Sie alle Instanzen der Anwendung starten, die für eine bestimmte Umgebung vorgesehen sind.
Hier sind die Vor- und Nachteile eines solchen Ansatzes.
+ Isolation der Produktionsumgebung
Im Rahmen dieses Ansatzes sind alle Umgebungen voneinander isoliert. In der Praxis ist dies jedoch besonders für die Produktionsumgebung wichtig.
Produktionsversionen der Anwendung sind nun nicht mehr von den Ereignissen in anderen Clustern und Umgebungen abhängig.
Wenn im Entwicklungscluster plötzlich ein Problem auftritt, funktionieren die Produktionsversionen der Anwendungen weiter, als wäre nichts passiert.
+ Cluster können an die Umgebung angepasst werden
Jeder Cluster kann an seine Umgebung angepasst werden. Zum Beispiel kann man:
- Entwicklungs- und Debugging-Tools im Entwicklungscluster installieren;
- Testframeworks und -tools im Cluster installieren; test;
- leistungsfähigere Hardware und Netzwerkkapazitäten im Cluster nutzen. prod.
Dies erhöht die Effizienz sowohl der Entwicklung als auch des Betriebs der Anwendungen.
+ Einschränkung des Zugangs zum Produktionscluster
Die Notwendigkeit, direkt mit dem Produktionscluster zu arbeiten, tritt nicht oft auf, sodass man den Personenkreis, der Zugriff darauf hat, erheblich einschränken kann.
Man kann sogar noch weiter gehen und den Menschen den Zugang zu diesem Cluster ganz verweigern, während alle Deployments über ein automatisiertes CI/CD-Tool durchgeführt werden. Ein solcher Ansatz minimiert das Risiko menschlicher Fehler dort, wo es am relevantesten ist.
Jetzt ein paar Worte zu den Nachteilen.
− Fehlende Isolation zwischen Anwendungen
Der Hauptnachteil des Ansatzes ist das Fehlen von Hardware- und Ressourcenauslagen zwischen Anwendungen.
Unabhängige Anwendungen nutzen gemeinsam die Ressourcen des Clusters: Betriebssystemkerne, Prozessoren, Speicher und einige andere Dienste.
Wie bereits erwähnt, kann dies potenziell gefährlich sein.
− Unmöglichkeit, Abhängigkeiten von Anwendungen zu lokalisieren
Wenn eine Anwendung bestimmte Anforderungen hat, müssen diese in allen Clustern erfüllt werden.
Zum Beispiel, wenn eine Anwendung eine GPU benötigt, muss jeder Cluster mindestens einen Worker mit GPU enthalten (selbst wenn dieser nur von dieser Anwendung genutzt wird).
Infolgedessen riskieren wir höhere Kosten und eine ineffiziente Nutzung der Ressourcen.
Fazit
Bei Vorhandensein einer bestimmten Anzahl von Anwendungen können diese in mehreren großen Clustern oder in vielen kleinen untergebracht werden.
In dem Artikel werden die Vor- und Nachteile verschiedener Ansätze untersucht, von einem großen globalen Cluster bis hin zu mehreren kleinen und spezialisierten:
- ein großer gemeinsamer Cluster;
- viele kleine, spezialisierte Cluster;
- ein Cluster pro Anwendung;
- ein Cluster pro Umgebung.
Welchen Ansatz sollten wir also wählen?
Wie üblich hängt die Antwort vom Nutzungsszenario ab: Man muss die Vor- und Nachteile verschiedener Ansätze abwägen und die optimalste Variante wählen.
Die Auswahl beschränkt sich jedoch nicht auf die oben genannten Beispiele – jede Kombination kann eingesetzt werden!
Zum Beispiel könnte man für jedes Team ein Paar Cluster einrichten: ein Cluster für die Entwicklung (in dem Umgebungen dev und test) und ein Cluster für Produktion (in dem sich die Produktionsumgebung befindet).
Basierend auf den Informationen aus diesem Artikel können Sie die Vor- und Nachteile entsprechend dem spezifischen Szenario optimieren. Viel Erfolg!
P.S.
Lesen Sie auch in unserem Blog:
- «»;
- «»;
- «»;
- «».
Quelle: habr.com
