Notiz. übersetzen: Dieses Material stammt aus einem Bildungsprojekt ist die Antwort auf eine häufig gestellte Frage beim Entwurf einer Kubernetes-basierten Infrastruktur. Wir hoffen, dass ziemlich detaillierte Beschreibungen der Vor- und Nachteile jeder Option Ihnen dabei helfen, die beste Wahl für Ihr Projekt zu treffen.
TL; DR: Derselbe Satz von Arbeitslasten kann auf mehreren großen Clustern (jeder Cluster verfügt über eine große Anzahl von Arbeitslasten) oder auf vielen kleinen (mit einer kleinen Anzahl von Lasten in jedem Cluster) ausgeführt werden.
Nachfolgend finden Sie eine Tabelle, in der die Vor- und Nachteile der einzelnen Ansätze bewertet werden:
Bei der Verwendung von Kubernetes als Plattform zum Ausführen von Anwendungen stellen sich häufig mehrere grundlegende Fragen zu den Feinheiten der Cluster-Einrichtung:
- Wie viele Cluster sollte ich verwenden?
- Wie groß soll ich sie machen?
- Was sollte jeder Cluster beinhalten?
In diesem Artikel werde ich versuchen, alle diese Fragen zu beantworten, indem ich die Vor- und Nachteile jedes Ansatzes analysiere.
Erklärung einer Frage
Als Softwareentwickler entwickeln und betreiben Sie wahrscheinlich viele Anwendungen gleichzeitig.
Darüber hinaus ist es wahrscheinlich, dass viele Instanzen dieser Anwendungen in unterschiedlichen Umgebungen ausgeführt werden – dies kann beispielsweise der Fall sein dev, Test и Stoß.
Das Ergebnis ist eine ganze Matrix von Anwendungen und Umgebungen:
Anwendungen und Umgebungen
Das obige Beispiel stellt 3 Anwendungen und 3 Umgebungen dar, was insgesamt 9 mögliche Optionen ergibt.
Jede Anwendungsinstanz ist eine eigenständige Bereitstellungseinheit, mit der unabhängig von anderen gearbeitet werden kann.
Bitte beachten Sie, dass Anwendungsinstanz kann aus vielen bestehen Komponenten, wie Frontend, Backend, Datenbank usw. Im Falle einer Microservices-Anwendung umfasst die Instanz alle Microservices.
Daher haben Kubernetes-Benutzer mehrere Fragen:
- Sollten alle Anwendungsinstanzen in einem Cluster platziert werden?
- Lohnt es sich, für jede Anwendungsinstanz einen separaten Cluster zu haben?
- Oder sollte vielleicht eine Kombination der oben genannten Ansätze verwendet werden?
Alle diese Optionen sind durchaus realisierbar, da Kubernetes ein flexibles System ist, das die Möglichkeiten des Benutzers nicht einschränkt.
Hier sind einige der möglichen Wege:
- ein großer gemeinsamer Cluster;
- viele kleine hochspezialisierte Cluster;
- ein Cluster pro Anwendung;
- ein Cluster pro Umgebung.
Wie unten gezeigt, liegen die ersten beiden Ansätze am entgegengesetzten Ende der Optionsskala:
Von ein paar großen Clustern (links) zu vielen kleinen (rechts)
Im Allgemeinen gilt ein Cluster als „größer“ als ein anderer, wenn er über eine größere Summe an Knoten und Pods verfügt. Beispielsweise ist ein Cluster mit 10 Knoten und 100 Pods größer als ein Cluster mit 1 Knoten und 10 Pods.
Nun, fangen wir an!
1. Ein großer gemeinsamer Cluster
Die erste Möglichkeit besteht darin, alle Workloads in einem Cluster zu platzieren:
Ein großer Haufen
Innerhalb dieses Ansatzes wird der Cluster als universelles Element verwendet Infrastrukturplattform – Sie stellen einfach alles, was Sie brauchen, in einem vorhandenen Kubernetes-Cluster bereit.
Kubernetes ermöglicht es, Teile des Clusters logisch voneinander zu trennen, sodass jede Anwendungsinstanz einen eigenen Namensraum haben kann.
Schauen wir uns die Vor- und Nachteile dieses Ansatzes an.
+ Effizienter Ressourceneinsatz
Mit einem einzelnen Cluster benötigen Sie nur eine Kopie aller Ressourcen, die zum Ausführen und Verwalten des Kubernetes-Clusters erforderlich sind.
Dies gilt beispielsweise für Masterknoten. Normalerweise verfügt jeder Kubernetes-Cluster über 3 Master-Knoten, sodass diese Anzahl für einen einzelnen Cluster unverändert bleibt (zum Vergleich: 10 Cluster benötigen 30 Master-Knoten).
Die obige Feinheit gilt auch für andere Dienste, die im gesamten Cluster betrieben werden, wie z. B. Load Balancer, Ingress Controller, Authentifizierungs-, Protokollierungs- und Überwachungssysteme.
In einem einzelnen Cluster können alle diese Dienste gleichzeitig für alle Workloads genutzt werden (es ist nicht erforderlich, Kopien davon zu erstellen, wie es bei mehreren Clustern der Fall ist).
+ Günstig
Aus den oben genannten Gründen sind weniger Cluster in der Regel günstiger, da keine Gemeinkosten anfallen.
Dies gilt insbesondere für Masterknoten, die unabhängig davon, wie sie gehostet werden (lokal oder in der Cloud), eine erhebliche Menge Geld kosten können.
Einige verwaltete Kubernetes-Dienste, wie z oder Stellen Sie die Kontrollschicht kostenlos zur Verfügung. In diesem Fall ist die Kostenfrage weniger akut.
Es gibt auch verwaltete Dienste, die eine feste Gebühr für den Betrieb jedes Kubernetes-Clusters erheben (z. B. ).
+ Effiziente Verwaltung
Die Verwaltung eines Clusters ist einfacher als die Verwaltung mehrerer.
Die Verwaltung kann folgende Aufgaben umfassen:
- Aktualisierung der Kubernetes-Version;
- Einrichten einer CI/CD-Pipeline;
- Installieren des CNI-Plugins;
- Einrichten eines Benutzerauthentifizierungssystems;
- Installation eines Zugangscontrollers;
und viele andere…
Im Falle eines Clusters müssen Sie dies alles nur einmal tun.
Bei vielen Clustern müssen Vorgänge viele Male wiederholt werden, was wahrscheinlich eine gewisse Automatisierung von Prozessen und Tools erfordert, um Konsistenz und Konsistenz im Prozess sicherzustellen.
Und nun ein paar Worte zu den Nachteilen.
− Single Point of Failure
Im Falle einer Ablehnung Sohle Der Cluster funktioniert sofort nicht mehr alle Arbeitsbelastung!
Es gibt viele Möglichkeiten, wie etwas schief gehen kann:
- Das Aktualisieren von Kubernetes führt zu unerwarteten Nebenwirkungen.
- Eine Cluster-weite Komponente (z. B. ein CNI-Plugin) funktioniert nicht mehr wie erwartet.
- Eine der Clusterkomponenten ist nicht richtig konfiguriert.
- Fehler in der zugrunde liegenden Infrastruktur.
Ein solcher Vorfall kann allen in einem gemeinsam genutzten Cluster gehosteten Workloads ernsthaften Schaden zufügen.
− Keine starre Isolierung
Die Ausführung in einem gemeinsam genutzten Cluster bedeutet, dass Anwendungen die Hardware, Netzwerkfunktionen und das Betriebssystem auf den Clusterknoten gemeinsam nutzen.
In gewissem Sinne sind zwei Container mit zwei unterschiedlichen Anwendungen, die auf demselben Knoten ausgeführt werden, wie zwei Prozesse, die auf derselben Maschine mit demselben Betriebssystemkernel ausgeführt werden.
Linux-Container bieten eine gewisse Form der Isolation, diese ist jedoch bei weitem nicht so stark wie beispielsweise die von virtuellen Maschinen. Im Wesentlichen ist ein Prozess in einem Container derselbe Prozess, der auf dem Host-Betriebssystem ausgeführt wird.
Dies kann ein Sicherheitsproblem darstellen: Diese Anordnung ermöglicht theoretisch die Kommunikation unabhängiger Anwendungen miteinander (entweder absichtlich oder versehentlich).
Darüber hinaus nutzen alle Workloads in einem Kubernetes-Cluster einige Cluster-weite Dienste gemeinsam, z – Dadurch können Anwendungen Dienste anderer Anwendungen im Cluster finden.
Alle oben genannten Punkte können je nach Anwendungssicherheitsanforderungen unterschiedliche Bedeutungen haben.
Kubernetes bietet verschiedene Tools zur Vermeidung von Sicherheitsproblemen wie z и . Allerdings erfordert die korrekte Einrichtung etwas Erfahrung, zudem sind sie nicht in der Lage, absolut alle Sicherheitslücken zu schließen.
Es ist wichtig, sich immer daran zu erinnern, wofür Kubernetes ursprünglich entwickelt wurde Teilen, nicht für Isolation und Sicherheit.
− Fehlende strikte Mandantenfähigkeit
Angesichts der Fülle an gemeinsam genutzten Ressourcen in einem Kubernetes-Cluster gibt es viele Möglichkeiten, wie verschiedene Anwendungen sich gegenseitig auf die Füße treten können.
Beispielsweise könnte eine Anwendung eine gemeinsam genutzte Ressource (z. B. CPU oder Speicher) monopolisieren und anderen Anwendungen, die auf demselben Knoten ausgeführt werden, den Zugriff darauf verweigern.
Kubernetes bietet verschiedene Mechanismen zur Steuerung dieses Verhaltens, wie z (siehe auch den Artikel „" - ca. übersetzt), и . Allerdings ist ihre Konfiguration, wie auch im Fall der Sicherheit, nicht trivial und sie sind nicht in der Lage, alle unvorhergesehenen Nebenwirkungen absolut zu verhindern.
− Große Anzahl von Benutzern
Im Falle eines einzelnen Clusters müssen Sie vielen Personen den Zugriff darauf ermöglichen. Und je größer ihre Zahl, desto größer ist das Risiko, dass sie etwas „kaputt machen“.
Innerhalb des Clusters können Sie steuern, wer was tun darf (siehe Artikel „" - ca. übersetzt). Es wird jedoch nicht verhindern, dass Benutzer innerhalb der Grenzen ihres Verantwortungsbereichs etwas „kaputt machen“.
− Cluster können nicht unbegrenzt wachsen
Der Cluster, der für alle Arbeitslasten verwendet wird, wird wahrscheinlich ziemlich groß sein (im Hinblick auf die Anzahl der Knoten und Pods).
Doch hier entsteht ein weiteres Problem: Cluster in Kubernetes können nicht unbegrenzt wachsen.
Es gibt eine theoretische Grenze für die Clustergröße. In Kubernetes ist es ungefähr .
Im wirklichen Leben können Probleme jedoch viel früher beginnen – zum Beispiel einfach mit .
Tatsache ist, dass große Cluster die Kubernetes-Kontrollschicht stark belasten. Mit anderen Worten: Um den Cluster effizient am Laufen zu halten, ist eine sorgfältige Abstimmung erforderlich.
Dieses Problem wird in einem verwandten Artikel im Originalblog mit dem Titel „".
Aber betrachten wir den umgekehrten Ansatz: viele kleine Cluster.
2. Viele kleine, spezialisierte Cluster
Bei diesem Ansatz verwenden Sie für jedes bereitgestellte Element einen separaten Cluster:
Viele kleine Cluster
Für die Zwecke dieses Artikels unter einsetzbares Element bezieht sich auf eine Instanz einer Anwendung – zum Beispiel eine Entwicklungsversion einer separaten Anwendung.
Diese Strategie nutzt Kubernetes als Spezialisierung Laufzeit für einzelne Anwendungsfälle.
Schauen wir uns die Vor- und Nachteile dieses Ansatzes an.
+ Begrenzter „Explosionsradius“
Wenn ein Cluster ausfällt, beschränken sich die negativen Folgen nur auf die Workloads, die in diesem Cluster bereitgestellt wurden. Alle anderen Workloads bleiben davon unberührt.
+ Isolierung
In einzelnen Clustern gehostete Workloads teilen sich keine Ressourcen wie Prozessor, Speicher, Betriebssystem, Netzwerk oder andere Dienste.
Das Ergebnis ist eine strenge Isolierung zwischen unabhängigen Anwendungen, was sich positiv auf deren Sicherheit auswirken kann.
+ Geringe Benutzeranzahl
Da jeder Cluster nur eine begrenzte Menge an Workloads enthält, wird die Anzahl der Benutzer mit Zugriff darauf reduziert.
Je weniger Menschen Zugriff auf den Cluster haben, desto geringer ist das Risiko, dass etwas „kaputt geht“.
Schauen wir uns die Nachteile an.
− Ineffizienter Ressourceneinsatz
Wie bereits erwähnt, erfordert jeder Kubernetes-Cluster einen bestimmten Satz von Verwaltungsressourcen: Masterknoten, Komponenten der Kontrollschicht, Überwachungs- und Protokollierungslösungen.
Bei einer großen Anzahl kleiner Cluster muss ein größerer Anteil der Ressourcen für das Management bereitgestellt werden.
− Teuer
Eine ineffiziente Nutzung von Ressourcen zieht automatisch hohe Kosten nach sich.
Wenn beispielsweise 30 statt drei Masterknoten mit der gleichen Rechenleistung betrieben werden, wirkt sich dies zwangsläufig auf die Kosten aus.
− Schwierigkeiten bei der Verwaltung
Die Verwaltung mehrerer Kubernetes-Cluster ist viel schwieriger als die Verwaltung nur eines.
Beispielsweise müssen Sie die Authentifizierung und Autorisierung für jeden Cluster konfigurieren. Auch die Kubernetes-Version muss mehrfach aktualisiert werden.
Um all diese Aufgaben effizienter zu gestalten, müssen Sie wahrscheinlich Automatisierung einsetzen.
Schauen wir uns nun weniger extreme Szenarien an.
3. Ein Cluster pro Anwendung
Bei diesem Ansatz erstellen Sie einen separaten Cluster für alle Instanzen einer bestimmten Anwendung:
Cluster pro Anwendung
Dieser Weg kann als Verallgemeinerung des Prinzips „separater Cluster pro Team“, da in der Regel ein Team von Ingenieuren eine oder mehrere Anwendungen entwickelt.
Schauen wir uns die Vor- und Nachteile dieses Ansatzes an.
+ Der Cluster kann an die Anwendung angepasst werden
Wenn eine Anwendung besondere Anforderungen hat, können diese in einem Cluster implementiert werden, ohne dass sich dies auf andere Cluster auswirkt.
Zu diesen Anforderungen können GPU-Worker, bestimmte CNI-Plugins, ein Service-Mesh oder ein anderer Dienst gehören.
Jeder Cluster kann auf die darin ausgeführte Anwendung zugeschnitten werden, sodass er nur das enthält, was benötigt wird.
− Verschiedene Umgebungen in einem Cluster
Der Nachteil dieses Ansatzes besteht darin, dass Anwendungsinstanzen aus unterschiedlichen Umgebungen im selben Cluster koexistieren.
Beispielsweise wird die Produktversion der Anwendung im selben Cluster wie die Entwicklungsversion ausgeführt. Dies bedeutet auch, dass Entwickler im selben Cluster agieren, in dem auch die Produktionsversion der Anwendung betrieben wird.
Wenn aufgrund von Aktionen von Entwicklern oder Störungen in der Entwicklungsversion ein Fehler im Cluster auftritt, könnte möglicherweise auch die Produktversion darunter leiden – ein großer Nachteil dieses Ansatzes.
Und schließlich das letzte Szenario auf unserer Liste.
4. Ein Cluster pro Umgebung
Dieses Szenario beinhaltet die Zuweisung eines separaten Clusters für jede Umgebung:
Ein Cluster pro Umgebung
Es kann beispielsweise sein, dass Sie Cluster haben dev, Test и Stoß, in dem Sie alle Instanzen der Anwendung ausführen, die einer bestimmten Umgebung zugeordnet sind.
Hier sind die Vor- und Nachteile dieses Ansatzes.
+ Isolierung der Produktumgebung
Bei diesem Ansatz sind alle Umgebungen voneinander isoliert. In der Praxis ist dies jedoch besonders wichtig in einer Produktionsumgebung.
Produktionsversionen der Anwendung sind jetzt unabhängig von den Vorgängen in anderen Clustern und Umgebungen.
Wenn im Entwicklungscluster plötzlich ein Problem auftritt, funktionieren die Produktversionen der Anwendungen auf diese Weise weiter, als wäre nichts passiert.
+ Der Cluster kann an die Umgebung angepasst werden
Jeder Cluster kann an seine Umgebung angepasst werden. Sie können zum Beispiel:
- Installieren Sie Tools für Entwicklung und Debugging im Entwicklungscluster.
- Installieren Sie Testframeworks und -tools im Cluster Test;
- Verwenden Sie leistungsfähigere Hardware und Netzwerkkanäle im Cluster Stoß.
Dadurch können Sie die Effizienz sowohl bei der Anwendungsentwicklung als auch beim Betrieb steigern.
+ Einschränken des Zugriffs auf den Produktionscluster
Die Notwendigkeit, direkt mit einem Produktcluster zu arbeiten, besteht selten, sodass Sie den Kreis der Personen, die Zugriff darauf haben, erheblich einschränken können.
Sie können sogar noch weiter gehen und Personen den Zugriff auf diesen Cluster gänzlich verweigern und alle Bereitstellungen mithilfe eines automatisierten CI/CD-Tools durchführen. Ein solcher Ansatz minimiert das Risiko menschlicher Fehler genau dort, wo es am relevantesten ist.
Und nun ein paar Worte zu den Nachteilen.
− Keine Isolation zwischen Anwendungen
Der Hauptnachteil des Ansatzes ist die fehlende Hardware- und Ressourcenisolierung zwischen Anwendungen.
Unabhängige Anwendungen teilen sich Clusterressourcen: den Systemkern, den Prozessor, den Speicher und einige andere Dienste.
Wie bereits erwähnt, kann dies potenziell gefährlich sein.
− Unfähigkeit, Anwendungsabhängigkeiten zu lokalisieren
Wenn eine Anwendung besondere Anforderungen stellt, müssen diese über alle Cluster hinweg erfüllt werden.
Wenn eine Anwendung beispielsweise eine GPU erfordert, muss jeder Cluster mindestens einen Worker mit einer GPU enthalten (auch wenn dieser nur von dieser Anwendung verwendet wird).
Dadurch riskieren wir höhere Kosten und eine ineffiziente Ressourcennutzung.
Abschluss
Wenn Sie über einen bestimmten Satz von Anwendungen verfügen, können diese in mehreren großen oder vielen kleinen Clustern platziert werden.
Der Artikel diskutiert die Vor- und Nachteile verschiedener Ansätze, die von einem globalen Cluster bis hin zu mehreren kleinen und hochspezialisierten Clustern reichen:
- ein großer allgemeiner Cluster;
- viele kleine hochspezialisierte Cluster;
- ein Cluster pro Anwendung;
- ein Cluster pro Umgebung.
Welchen Ansatz sollten Sie also wählen?
Wie immer hängt die Antwort vom Anwendungsfall ab: Sie müssen die Vor- und Nachteile verschiedener Ansätze abwägen und die optimale Option auswählen.
Die Auswahl ist jedoch nicht auf die oben genannten Beispiele beschränkt – Sie können jede beliebige Kombination davon verwenden!
Sie können beispielsweise für jedes Team mehrere Cluster organisieren: einen Entwicklungscluster (in dem es Umgebungen gibt). dev и Test) und Cluster für Produktion (wo sich die Produktionsumgebung befindet).
Basierend auf den Informationen in diesem Artikel können Sie die Vor- und Nachteile für ein bestimmtes Szenario entsprechend optimieren. Viel Glück!
PS
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «";
- «".
Source: habr.com