Hinweis.: dieses Material stammt aus einem Bildungsprojekt – eine Antwort auf eine häufige Frage bei der Planung von Infrastruktur auf Basis von Kubernetes. Wir hoffen, dass die ausführlichen Beschreibungen der Vor- und Nachteile jeder Variante Ihnen helfen, die beste Wahl für Ihr Projekt zu treffen.
TL;DR: derselbe Satz von Arbeitslasten kann auf mehreren großen Clustern (jeder Cluster mit einer großen Anzahl von Workloads) oder auf vielen kleinen Clustern (mit wenigen Arbeitslasten in jedem Cluster) ausgeführt werden.
Nachfolgend finden Sie eine Tabelle, in der die Vor- und Nachteile jedes Ansatzes bewertet werden:
Beim Einsatz von Kubernetes als Plattform für die Bereitstellung von Anwendungen tauchen häufig einige grundlegende Fragen zu den Feinheiten der Clusterkonfiguration auf:
- Wie viele Cluster sollten verwendet werden?
- Wie groß sollten sie sein?
- Was sollte jeder Cluster umfassen?
In diesem Artikel werde ich versuchen, alle diese Fragen zu beantworten, indem ich die Vor- und Nachteile jedes Ansatzes analysiere.
Die Fragestellung
Als Softwareentwickler entwickeln und betreiben Sie wahrscheinlich gleichzeitig mehrere Anwendungen.
Darüber hinaus werden viele Instanzen dieser Anwendungen sicherlich in verschiedenen Umgebungen gestartet – zum Beispiel könnten dies sein dev, test und prod.
Das Ergebnis ist eine gesamte Matrix aus Anwendungen und Umgebungen:
Anwendungen und Umgebungen
Im obigen Beispiel sind 3 Anwendungen und 3 Umgebungen dargestellt, was insgesamt 9 mögliche Kombinationen ergibt.
Jede Instanz einer Anwendung stellt eine eigenständige Deployment-Einheit dar, mit der unabhängig von anderen gearbeitet werden kann.
nicht mit einem Bindestrich beginnt. In YAML bedeutet dies, dass Instanz der Anwendung kann aus vielen Komponenten, wie Frontend, Backend, Datenbank usw. Im Fall einer mikroservicebasierten Anwendung umfasst eine Instanz alle Mikrodienste.
Das führt bei Kubernetes-Nutzern zu mehreren Fragen:
- Sollten alle Instanzen der Anwendung in einem Cluster platziert werden?
- Sollte für jede Instanz der Anwendung ein separater Cluster eingerichtet werden?
- Oder sollten möglicherweise Kombinationen der oben genannten Ansätze genutzt werden?
Alle diese Optionen sind durchaus praktikabel, da Kubernetes ein flexibles System ist, das die Möglichkeiten der Benutzer nicht einschränkt.
Hier sind einige der möglichen Wege:
- ein großer gemeinsamer Cluster;
- viele kleine spezialisierte Cluster;
- ein Cluster für jede Anwendung;
- ein Cluster für jede Umgebung.
Wie unten gezeigt, liegen die ersten beiden Ansätze an den gegenüberliegenden Enden der Optionsskala:
Von mehreren großen Clustern (links) bis hin zu vielen kleinen (rechts)
Im Allgemeinen gilt, dass ein Cluster "größer" ist als ein anderer, wenn er eine größere Anzahl von Knoten und Pods hat. Beispielsweise ist ein Cluster mit 10 Knoten und 100 Pods größer als ein Cluster mit 1 Knoten und 10 Pods.
Na dann, lass uns anfangen!
1. Ein großer gemeinsamer Cluster
Die erste Option ist, alle Arbeitslasten in einem Cluster zu platzieren:
Ein großer Cluster
In diesem Ansatz wird der Cluster als universelle Infrastrukturplattform verwendet - alles Notwendige wird einfach im bestehenden Kubernetes-Cluster bereitgestellt.
Kubernetes ermöglichen es, Teile des Clusters logisch voneinander zu trennen, sodass für jede Instanz der Anwendung ein eigenes Namensraum verwendet werden kann.
Lass uns die Vor- und Nachteile dieses Ansatzes betrachten.
+ Effektive Ressourcennutzung
Im Falle eines einzelnen Clusters ist nur ein Exemplar aller Ressourcen erforderlich, die für den Betrieb und das Management eines Kubernetes-Clusters nötig sind.
Dies gilt zum Beispiel für die Master-Knoten. In der Regel gibt es für jeden Kubernetes-Cluster drei Master-Knoten, was bedeutet, dass es bei einem einzelnen Cluster auch bei dieser Anzahl bleibt (zum Vergleich: Für zehn Cluster sind 30 Master-Knoten erforderlich).
Diese Erwägung gilt auch für andere Dienste, die im gesamten Cluster funktionieren, wie Lastenausgleich, Ingress-Controller, Authentifizierungssysteme, Logging und Monitoring.
In einem einzelnen Cluster können all diese Dienste gleichzeitig für alle Workloads verwendet werden (es müssen keine Kopien erstellt werden, wie es bei mehreren Clustern erforderlich wäre).
+ Kosteneffizienz
Infolgedessen ist eine geringere Anzahl von Clustern in der Regel günstiger, da die Kosten für überflüssige Ressourcen entfallen.
Dies gilt insbesondere für Master-Knoten, die unabhängig von der Bereitstellungsart (lokal oder in der Cloud) erhebliche Kosten verursachen können.
Einige verwaltete Kubernetes-Dienste, wie zum Beispiel oder , bieten eine kostenlose Verwaltungsschicht. In diesem Fall ist das Kostenproblem weniger drängend.
Es gibt auch Managed-Services, die eine feste Gebühr für den Betrieb jedes Kubernetes-Clusters erheben (zum Beispiel, ).
+ Effiziente Administration
Die Verwaltung eines Clusters ist einfacher als die mehrerer.
Die Administration kann folgende Aufgaben umfassen:
- aktualisieren der Kubernetes-Version;
- einrichten der CI/CD-Pipeline;
- installieren des CNI-Plugins;
- einrichten des Benutzerauthentifizierungssystems;
- installieren des Zugangskontroll-Controllers;
und viele andere…
Bei einem einzelnen Cluster muss all dies nur einmal erledigt werden.
Für mehrere Cluster müssen die Vorgänge wiederholt werden, was wahrscheinlich eine Automatisierung der Prozesse und Tools erfordert, um Konsistenz und Einheitlichkeit zu gewährleisten.
Jetzt einige Worte zu den Nachteilen.
− Einzelner Ausfallpunkt
Im Falle eines Ausfalls des einzigen Clusters werden sofort alle alle Arbeitslasten betroffen sein!
Es gibt viele Szenarien, in denen etwas schiefgehen kann:
- ein Upgrade von Kubernetes führt zu unerwarteten Nebeneffekten;
- Ein gemeinsames Clusterkomponente (zum Beispiel ein CNI-Plugin) funktioniert nicht wie erwartet;
- Einer der Clusterkomponenten ist falsch konfiguriert;
- Ein Fehler in der zugrunde liegenden Infrastruktur.
Ein solcher Vorfall kann allen in einem gemeinsamen Cluster gehosteten Arbeitslasten erheblichen Schaden zufügen.
− Fehlende strikte Isolation
Die Arbeit in einem gemeinsamen Cluster bedeutet, dass Anwendungen die Hardware, Netzwerkressourcen 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 Betriebssystemkern laufen.
Linux-Container bieten eine gewisse Form der Isolation, jedoch ist diese bei weitem nicht so stark wie die, die beispielsweise von virtuellen Maschinen bereitgestellt wird. Im Grunde genommen ist ein Prozess in einem Container der gleiche Prozess, der im Betriebssystem des Hosts ausgeführt wird.
Das kann aus sicherheitstechnischer Sicht problematisch sein: Eine solche Organisation ermöglicht theoretisch die Interaktion zwischen nicht verbundenen Anwendungen (absichtlich oder versehentlich).
Darüber hinaus nutzen alle Workloads 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 je nach den Sicherheitsanforderungen der Anwendungen unterschiedliche Bedeutungen haben.
Kubernetes bietet verschiedene Werkzeuge zur Vermeidung von Sicherheitsproblemen, wie zum Beispiel und . Für ihre korrekte Konfiguration ist jedoch ein gewisses Maß an Erfahrung erforderlich, zudem können sie nicht alle Sicherheitslücken schließen.
Es ist wichtig, sich immer wieder vor Augen zu führen, dass Kubernetes ursprünglich für gemeinsame Nutzung, und nicht für Isolation und Sicherheit.
− Mangel an striktem Multi-Tenancy
Angesichts der Vielzahl von gemeinsamen 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 gemeinsame Ressource (wie CPU oder RAM) monopolisieren und andere Anwendungen auf demselben Knoten den Zugriff darauf verwehren.
Kubernetes bietet verschiedene Mechanismen zur Kontrolle dieses Verhaltens, wie (siehe auch den Artikel „“ — Anm. d. Übers.), und . Allerdings ist, wie im Fall von Sicherheit, die Konfiguration nicht trivial und kann nicht alle unvorhergesehenen Nebenwirkungen verhindern.
− Eine große Anzahl von Benutzern
Bei einem einzigen Cluster müssen viele Benutzer Zugriff darauf erhalten. Je mehr Benutzer es sind, desto höher ist das Risiko, dass sie etwas „zerstören“.
Innerhalb des Clusters kann kontrolliert werden, wer was tun kann, durch (siehe den Artikel „“ — Anm. d. Übers.). Allerdings hindert es die Benutzer nicht daran, innerhalb ihres Verantwortungsbereichs etwas „zu zerbrechen“.
− Cluster können nicht unbegrenzt wachsen
Ein Cluster, der für alle Arbeitslasten verwendet wird, wird wahrscheinlich recht groß sein (in Bezug auf Knoten und Pods).
Aber hier stellt sich ein anderes Problem: Kubernetes-Cluster können nicht unbegrenzt wachsen.
Es gibt eine theoretische Grenze für die Clustergröße. In Kubernetes beträgt sie etwa .
In der Praxis können jedoch Probleme viel früher auftreten — zum Beispiel schon bei .
Das liegt daran, dass große Cluster eine hohe Last auf die Kubernetes-Steuerebene bringen. Mit anderen Worten, um einen Cluster in einem funktionsfähigen Zustand zu halten und die Ressourcen effektiv zu nutzen, ist eine sorgfältige Konfiguration erforderlich.
Dieses Problem wird in dem passenden Artikel im Originalblog mit dem Titel „».
Aber lassen Sie uns einen gegensätzlichen Ansatz betrachten: viele kleine Cluster.
2. Viele kleine, spezialisierte Cluster
Bei diesem Ansatz nutzen Sie einen separaten Cluster für jedes bereitzustellende Element:
Viele kleine Cluster.
Für die Zwecke dieses Artikels wird unter bereitzustellendem Element eine Instanz einer Anwendung verstanden — zum Beispiel die Entwicklungsversion einer speziellen Anwendung.
In dieser Strategie wird Kubernetes als spezialisierte Ausführungsumgebung für einzelne Anwendungsinstanzen eingesetzt.
Lass uns die Vor- und Nachteile dieses Ansatzes betrachten.
+ Eingeschränkter „Explosionsradius“
Im Falle eines „Ausfalls“ des Clusters sind die negativen Folgen nur auf die Workloads beschränkt, die in diesem Cluster implementiert wurden. Alle anderen Workloads bleiben unberührt.
+ Isolation
Workloads, die in separaten Clustern platziert sind, haben keine gemeinsamen Ressourcen, wie CPU, RAM, Betriebssystem, Netzwerk oder andere Dienste.
Das Ergebnis ist eine strenge Isolation zwischen nicht miteinander verbundenen Anwendungen, was sich positiv auf deren Sicherheit auswirken kann.
+ Wenige Benutzer
Da in jedem Cluster nur eine begrenzte Anzahl von Workloads vorhanden ist, wird die Anzahl der Benutzer mit Zugriff darauf verringert.
Je weniger Personen Zugriff auf den Cluster haben, desto geringer ist das Risiko, dass etwas „kaputtgeht“.
Lassen Sie uns die Nachteile betrachten.
− Ineffiziente Ressourcennutzung
Wie bereits erwähnt, benötigt jeder Kubernetes-Cluster eine bestimmte Menge an Verwaltungsressourcen: Master-Knoten, Steuerungskomponenten sowie Lösungen für Monitoring und Logging.
Bei einer großen Anzahl kleiner Cluster muss ein größerer Anteil der Ressourcen für das Management aufgewendet werden.
− Kosten
Ineffiziente Ressourcennutzung führt automatisch zu hohen Ausgaben.
Zum Beispiel wirkt sich die Unterhaltung von 30 Master-Knoten anstelle von drei bei gleicher Rechenleistung zwangsläufig auf die Kosten aus.
− Verwaltungskomplexität
Die Administration vieler Kubernetes-Cluster ist weitaus komplexer als die Arbeit mit einem einzelnen Cluster.
Zum Beispiel müssen Authentifizierung und Autorisierung für jeden Cluster eingerichtet werden. Auch Updates der Kubernetes-Version müssen mehrere Male durchgeführt werden.
Wahrscheinlich wird Automatisierung notwendig sein, um die Effizienz all dieser Aufgaben zu steigern.
Betrachten wir nun weniger extreme Szenarien.
3. Ein Cluster für jede Anwendung
Bei diesem Ansatz erstellen Sie einen separaten Cluster für alle Instanzen einer bestimmten Anwendung:
Cluster pro Anwendung
Dieser Ansatz kann als eine Verallgemeinerung des Prinzips betrachtet werden, dassein separater Cluster für jedes Teamda in der Regel ein Ingenieurteam an einem oder mehreren Anwendungen arbeitet.
Lass uns die Vor- und Nachteile dieses Ansatzes betrachten.
+ Der Cluster kann speziell auf die Anwendung abgestimmt 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 einen anderen Dienst umfassen.
Jeder Cluster kann speziell für die Anwendung, die darin läuft, angepasst werden, sodass er nur die notwendigen Komponenten enthält.
− 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. Das bedeutet auch, dass Entwickler in demselben Cluster arbeiten, in dem die Produktionsversion der Anwendung betrieben wird.
Wenn aufgrund der Aktionen von Entwicklern oder Fehlern in der Entwicklungsversion im Cluster ein Ausfall auftritt, 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 Zuordnung eines separaten Clusters für jede Umgebung vor:
Ein Cluster pro Umgebung
Zum Beispiel könnten Sie Cluster haben, dev, test und prod, in denen Sie alle Instanzen der Anwendung ausführen, die für eine bestimmte Umgebung bestimmt sind.
Hier sind die Vor- und Nachteile dieses Ansatzes.
+ Isolation der Produktionsumgebung
Bei diesem Ansatz sind alle Umgebungen voneinander isoliert. Dies ist insbesondere für die Produktionsumgebung von großer Bedeutung.
Produktionsversionen der Anwendung sind nun unabhängig von dem, was in anderen Clustern und Umgebungen geschieht.
Sollte also im Entwickler-Cluster plötzlich ein Problem auftreten, werden die Produktionsversionen der Anwendungen weiterhin funktionieren, als wäre nichts passiert.
+ Cluster können an die Umgebung angepasst werden
Jedes Cluster kann an seine Umgebung angepasst werden. Zum Beispiel kann man:
- Entwicklungs- und Debugging-Tools im Entwickler-Cluster installieren;
- Test-Frameworks und Tools im Cluster installieren test;
- leistungsstärkere Hardware und Netzwerkverbindungen im Cluster verwenden prod.
Dies steigert die Effizienz sowohl in der Entwicklung als auch im Betrieb von Anwendungen.
+ Zugangsbeschränkung zum Produktions-Cluster
Die Notwendigkeit, direkt mit dem Prod-Cluster zu arbeiten, tritt nicht häufig auf, sodass der Kreis der Personen, die Zugang dazu haben, erheblich eingeschränkt werden kann.
Man kann sogar noch weiter gehen und den Personen den Zugang zu diesem Cluster vollständig entziehen, während alle Bereitstellungen mit einem automatisierten CI/CD-Tool durchgeführt werden. Ein solcher Ansatz minimiert das Risiko menschlicher Fehler genau dort, wo es am relevantesten ist.
Jetzt einige Worte zu den Nachteilen.
− Fehlende Isolierung zwischen Anwendungen
Der Hauptnachteil dieses Ansatzes ist die fehlende hardware- und ressourcentechnische Isolierung zwischen den Anwendungen.
Unverknüpfte Anwendungen nutzen gemeinsam die Ressourcen des Clusters: das Betriebssystem, den Prozessor, den Arbeitsspeicher 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 besondere Anforderungen hat, müssen diese in allen Clustern erfüllt werden.
Wenn eine Anwendung eine GPU benötigt, muss jeder Cluster mindestens einen Worker mit GPU enthalten (auch wenn dieser nur von dieser Anwendung genutzt wird).
Das könnte dazu führen, dass wir höhere Kosten und eine ineffiziente Ressourcennutzung riskieren.
Fazit
Bei einem bestimmten Satz von Anwendungen können diese in mehreren großen Clustern oder in vielen kleinen untergebracht werden.
Der Artikel behandelt die Vor- und Nachteile verschiedener Ansätze, von einem globalen Cluster bis hin zu mehreren kleinen, spezifischen:
- ein großer gemeinsamer Cluster;
- viele kleine spezialisierte Cluster;
- ein Cluster für jede Anwendung;
- ein Cluster für jede Umgebung.
Also, welchen Ansatz sollte man wählen?
Wie üblich hängt die Antwort vom Nutzungsszenario ab: Man muss die Vor- und Nachteile der verschiedenen Ansätze abwägen und die optimale Lösung wählen.
Die Wahl ist jedoch nicht auf die oben genannten Beispiele beschränkt – es kann jede Kombination verwendet werden!
Zum Beispiel könnte man für jedes Team jeweils zwei Cluster einrichten: einen Cluster für die Entwicklung (in dem die Umgebungen dev und test) und einen Cluster für production (in dem sich die Produktionsumgebung befindet).
Basierend auf den Informationen in diesem Artikel können Sie die Vor- und Nachteile entsprechend Ihrem spezifischen Szenario optimieren. Viel Erfolg!
P.S.
Lesen Sie auch in unserem Blog:
- «»;
- «»;
- «»;
- «».
Quelle: habr.com
