🚒 👨🏻‍⚖️ 🖲️ Entwerfen von Kubernetes-Clustern: Wie viele sollte es geben? 🐙 🛠️ 😍

Hinweis perev. : Dieses Material aus dem Lernprojekt learnk8s ist die Antwort auf eine beliebte Frage beim Entwurf einer Infrastruktur auf der Basis von Kubernetes. Wir hoffen, dass ausreichend detaillierte Beschreibungen der Vor- und Nachteile jeder Option dazu beitragen, die beste Wahl für Ihr Projekt zu treffen.

TL; DR : Der gleiche Satz von Workloads kann auf mehreren großen Clustern (jeder Cluster hat eine große Anzahl von Workloads) oder auf vielen kleinen Clustern (mit einer kleinen Anzahl von Lasten in jedem Cluster) ausgeführt werden.

Die folgende Tabelle fasst die Vor- und Nachteile der einzelnen Ansätze zusammen:

Bei der Verwendung von Kubernetes als Plattform für den Betrieb von Anwendungen stellen sich häufig mehrere grundlegende Fragen zu den Feinheiten der Clusterkonfiguration:

Wie viele Cluster sollen verwendet werden?
Wie groß machen sie?
Was sollte jeder Cluster enthalten?

In diesem Artikel werde ich versuchen, all 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 parallel.

Darüber hinaus werden viele Instanzen dieser Anwendungen wahrscheinlich in verschiedenen Umgebungen ausgeführt - zum Beispiel können es Entwickler , Tests und Produkte sein .

Das Ergebnis ist eine ganze Matrix von Anwendungen und Umgebungen:

Anwendungen und Umgebungen

Im obigen Beispiel werden 3 Anwendungen und 3 Umgebungen vorgestellt, was letztendlich 9 mögliche Optionen bietet.

Jede Anwendungsinstanz ist eine eigenständige Bereitstellungseinheit, die unabhängig von anderen betrieben werden kann.

Beachten Sie, dass eine Anwendungsinstanz aus vielen Komponenten bestehen kann.wie Frontend, Backend, Datenbank usw. Im Fall einer Microservice-Anwendung enthält die Instanz alle Microservices.

Infolgedessen haben Kubernetes-Benutzer mehrere Fragen:

Sollte ich alle Anwendungsinstanzen in einem Cluster platzieren?
Sollte ich für jede Instanz der Anwendung einen eigenen Cluster erstellen?
Oder sollten Sie eine Kombination der oben genannten Ansätze verwenden?

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 Möglichkeiten:

ein großer gemeinsamer Cluster;
viele kleine hochspezialisierte Cluster;
ein Cluster für jede Anwendung;
ein Cluster für jede Umgebung.

Wie unten gezeigt, befinden sich die ersten beiden Ansätze am entgegengesetzten Ende der Optionsskala:

Von mehreren großen Clustern (links) zu vielen kleinen Clustern (rechts)

Im Allgemeinen wird ein Cluster als „größer“ als der andere angesehen, wenn er eine größere Summe von Knoten und Pods aufweist. Ein Cluster mit 10 Knoten und 100 Pods ist beispielsweise 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 Cluster

Im Rahmen dieses Ansatzes wird der Cluster als universelle Infrastrukturplattform verwendet. Sie stellen lediglich alles bereit, was Sie in einem vorhandenen Kubernetes-Cluster benötigen.

Namespace'y Kubernetes ermöglicht die logische Trennung eines Teils des Clusters voneinander, sodass der Namensraum für jede Instanz der Anwendung verwendet werden kann.

Schauen wir uns die Vor- und Nachteile dieses Ansatzes an.

+ Effiziente Ressourcennutzung

Bei einem einzelnen Cluster ist nur eine Kopie aller Ressourcen erforderlich, die zum Starten und Verwalten des Kubernetes-Clusters erforderlich sind.

Dies gilt beispielsweise für Masterknoten. Normalerweise gibt es 3 Masterknoten für jeden Kubernetes-Cluster, sodass für einen einzelnen Cluster die Anzahl so bleibt (zum Vergleich benötigen 10 Cluster 30 Masterknoten).

Die obige Feinheit gilt für andere Dienste, die clusterweit betrieben werden, wie z. B. Load Balancer, Ingress-Controller, Authentifizierungs-, Protokollierungs- und Überwachungssysteme.

In einem einzelnen Cluster können alle diese Dienste sofort für alle Workloads verwendet werden (Sie müssen keine Kopien davon erstellen, wie im Fall mehrerer Cluster).

+ Billig

Infolge des Vorstehenden ist eine geringere Anzahl von Clustern normalerweise billiger, da keine Kosten für überschüssige Ressourcen anfallen.

Dies gilt insbesondere für Masterknoten, die unabhängig von der Platzierungsmethode (lokal oder in der Cloud) erhebliche Kosten verursachen können.

Einige verwaltete Kubernetes-Dienste, wie die Google Kubernetes Engine (GKE) oder der Azure Kubernetes-Dienst (AKS) , bieten eine kostenlose Kontrollschicht. In diesem Fall ist das Kostenproblem weniger akut.

Es gibt auch verwaltete Dienste, für die für jeden Kubernetes-Cluster eine feste Gebühr erhoben wird (z. B. Amazon Elastic Kubernetes Service, EKS ).

+ Effektive Verwaltung

Das Verwalten eines einzelnen Clusters ist einfacher als mehrere.

Die Verwaltung kann die folgenden Aufgaben umfassen:

Update-Version von Kubernetes;
CI / CD-Pipeline-Konfiguration
Installation des CNI-Plugins;
Einrichten eines Benutzerauthentifizierungssystems;
Einstellen der Zugriffssteuerung;

und viele andere ...

Bei einem Cluster muss dies alles nur einmal durchgeführt werden.

Bei vielen Clustern müssen Vorgänge viele Male wiederholt werden, was wahrscheinlich eine gewisse Automatisierung von Prozessen und Tools erfordert, um einen systematischen und einheitlichen Prozess sicherzustellen.

Und jetzt ein paar Worte zu den Nachteilen.

- Der Punkt des Versagens

Bei einem Ausfall eines einzelnen Clusters funktionieren alle Workloads sofort nicht mehr !

Es gibt unzählige Möglichkeiten, wenn etwas schief gehen kann:

Das Aktualisieren von Kubernetes führt zu unerwarteten Nebenwirkungen.
Die clusterweite Komponente (z. B. das CNI-Plugin) funktioniert nicht wie erwartet.
Eine der Clusterkomponenten ist nicht richtig konfiguriert.
ein Fehler in der zugrunde liegenden Infrastruktur.

Ein solcher Vorfall kann alle Workloads in einem gemeinsamen Cluster ernsthaft beschädigen.

- Mangel an harter Isolierung

Das Arbeiten in einem gemeinsam genutzten Cluster bedeutet, dass Anwendungen Hardware, Netzwerkfunktionen und das Betriebssystem auf den Clusterknoten gemeinsam nutzen.

In gewisser Weise ähneln zwei Container mit zwei verschiedenen Anwendungen, die auf demselben Host ausgeführt werden, zwei Prozessen, die auf demselben Computer mit demselben Betriebssystemkern ausgeführt werden.

Linux-Container bieten eine Form der Isolation, sind jedoch bei weitem nicht so stark wie beispielsweise virtuelle Maschinen. Im Wesentlichen ist ein Prozess in einem Container derselbe Prozess, der auf dem Host-Betriebssystem ausgeführt wird.

Dies kann ein Sicherheitsproblem sein: Eine solche Organisation ermöglicht theoretisch, dass nicht verwandte Anwendungen (absichtlich oder versehentlich) miteinander interagieren.

Darüber hinaus teilen sich alle Workloads im Kubernetes-Cluster einige clusterweite Dienste, z. B. DNS. Auf diese Weise können Anwendungen die Dienste anderer Anwendungen im Cluster finden.

Alle oben genannten Elemente können abhängig von den Anforderungen an die Anwendungssicherheit unterschiedliche Bedeutungen haben.

Kubernetes bietet verschiedene Tools zur Vermeidung von Sicherheitsproblemen, z. B. PodSecurityPolicies und NetworkPolicies . Für die richtige Konfiguration sind jedoch einige Erfahrungen erforderlich. Außerdem können sie nicht alle Sicherheitslücken schließen.

Es ist wichtig, sich immer daran zu erinnern, dass Kubernetes ursprünglich für die Freigabe konzipiert wurde.und nicht für Isolation und Sicherheit .

- Mangel an engen Mandantenfähigkeit

Angesichts der Fülle gemeinsam genutzter Ressourcen im Kubernetes-Cluster gibt es viele Möglichkeiten, wie sich verschiedene Anwendungen gegenseitig auf den Fersen sein können.

Beispielsweise kann eine Anwendung eine gemeinsam genutzte Ressource (z. B. einen Prozessor oder Speicher) monopolisieren und anderen Anwendungen, die auf demselben Knoten ausgeführt werden, den Zugriff darauf entziehen.

Kubernetes bietet verschiedene Mechanismen zur Steuerung dieses Verhaltens, z. B. Ressourcenanforderungen und -limits (siehe auch Artikel „ CPU-Limits und aggressive Drosselung in Kubernetes “ - ca. Übersetzung) , ResourceQuotas und LimitRanges . Wie im Fall der Sicherheit ist ihre Konfiguration jedoch nicht trivial und sie können nicht alle unvorhergesehenen Nebenwirkungen verhindern.

- Eine große Anzahl von Benutzern

Bei einem einzelnen Cluster müssen viele Personen den Zugriff darauf öffnen. Und je größer ihre Anzahl ist, desto höher ist das Risiko, dass sie „etwas kaputt machen“.

Innerhalb des Clusters können Sie mithilfe der rollenbasierten Zugriffssteuerung (RBAC) steuern, wer und was getan werden kann (siehe Artikel „ Benutzer und RBAC-Autorisierung in Kubernetes “ - ca. Übertragung ) . Es wird jedoch nicht verhindern, dass Benutzer innerhalb der Grenzen ihres Verantwortungsbereichs etwas „brechen“.

- Cluster können nicht unbegrenzt wachsen

Der Cluster, der für alle Workloads verwendet wird, ist wahrscheinlich ziemlich groß (in Bezug auf die Anzahl der Knoten und Pods).

Hier tritt jedoch ein anderes Problem auf: Cluster in Kubernetes können nicht unbegrenzt wachsen.

Die Clustergröße ist theoretisch begrenzt. Bei Kubernetes sind es ungefähr 5.000 Knoten, 150.000 Pods und 300.000 Container .

Im wirklichen Leben können Probleme jedoch viel früher auftreten - beispielsweise bei nur 500 Knoten .

Tatsache ist, dass große Cluster eine hohe Last auf die Kubernetes-Kontrollschicht ausüben. Mit anderen Worten, um den Cluster betriebsbereit zu halten und Ressourcen effizient zu nutzen, ist eine sorgfältige Optimierung erforderlich.

Dieses Problem wird in einem verwandten Artikel im ursprünglichen Blog mit dem Titel " Architektur von Kubernetes-Clustern - Auswahl einer Worker-Knotengröße " behandelt.

Aber schauen wir uns den umgekehrten Ansatz an: 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 bezieht sich ein bereitgestelltes Element auf eine Instanz einer Anwendung, z. B. die Entwicklungsversion einer separaten Anwendung.

Diese Strategie verwendet Kubernetes als spezielle Laufzeit für einzelne Anwendungsinstanzen.

Schauen wir uns die Vor- und Nachteile dieses Ansatzes an.

+ Begrenzter "Explosionsradius"

Wenn ein Cluster ausfällt, sind die negativen Folgen nur auf die Workloads beschränkt, die in diesem Cluster bereitgestellt wurden. Alle anderen Workloads bleiben erhalten.

+ Isolierung

Auf einzelnen Clustern gehostete Workloads teilen keine Ressourcen wie Prozessor, Speicher, Betriebssystem, Netzwerk oder andere Dienste.

Infolgedessen erhalten wir eine enge Isolation zwischen nicht verwandten Anwendungen, was sich positiv auf deren Sicherheit auswirken kann.

+ Kleine Anzahl von Benutzern

Da jeder Cluster nur eine begrenzte Anzahl von Workloads enthält, wird die Anzahl der Benutzer mit Zugriff darauf reduziert.

Je weniger Personen 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 einen bestimmten Satz von Steuerungsressourcen: Hauptknoten, Komponenten der Steuerungsschicht, Lösungen für die Überwachung und Protokollierung.

Bei einer großen Anzahl kleiner Cluster ist es erforderlich, einen größeren Anteil der Ressourcen für die Verwaltung zuzuweisen.

- Hohe Kosten

Ineffiziente Ressourcennutzung verursacht automatisch hohe Kosten.

Beispielsweise wirkt sich die Wartung von 30 statt drei Masterknoten mit derselben Rechenleistung zwangsläufig auf die Kosten aus.

- Verwaltungsschwierigkeiten

Das Verwalten mehrerer Kubernetes-Cluster ist viel schwieriger als das Verwalten eines Clusters.

Beispielsweise müssen Sie die Authentifizierung und Autorisierung für jeden Cluster konfigurieren. Das Aktualisieren der Kubernetes-Version muss ebenfalls mehrmals durchgeführt werden.

Höchstwahrscheinlich müssen Sie Automatisierung anwenden, um die Effektivität all dieser Aufgaben zu erhöhen.

Betrachten Sie nun weniger extreme Szenarien.

3. Ein Cluster pro Anwendung

Im Rahmen dieses Ansatzes erstellen Sie einen separaten Cluster für alle Instanzen einer bestimmten Anwendung:

Cluster pro Anwendung

Diese Methode kann als Verallgemeinerung des Prinzips des „ separaten Clusters pro Team “ angesehen werden, da normalerweise ein Team von Ingenieuren an der Entwicklung einer oder mehrerer Anwendungen beteiligt ist.

Schauen wir uns die Vor- und Nachteile dieses Ansatzes an.

+ Cluster kann für die Anwendung angepasst werden

Wenn die Anwendung spezielle Anforderungen hat, können sie in einem Cluster implementiert werden, ohne andere Cluster zu beeinflussen.

Solche Anforderungen können GPU-Mitarbeiter, bestimmte CNI-Plugins, Service-Mesh oder einen anderen Service umfassen.

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 verschiedenen Umgebungen im selben Cluster vorhanden sind.

Beispielsweise wird die Produktversion der Anwendung im selben Cluster wie die Entwicklungsversion ausgeführt. Dies bedeutet auch, dass Entwickler ihre Aktivitäten in demselben Cluster ausführen, in dem die Produktionsversion der Anwendung ausgeführt wird.

Wenn ein Fehler aufgrund von Aktionen von Entwicklern oder Störungen der Entwicklungsversion im Cluster auftritt, kann auch die Produktversion möglicherweise darunter leiden - ein großer Nachteil dieses Ansatzes.

Und schließlich das letzte Skript auf unserer Liste.

4. Ein Cluster für jede Umgebung

In diesem Szenario wird für jede Umgebung ein separater Cluster zugewiesen:

Ein Cluster für die Umgebung

Sie können beispielsweise Entwicklungs- , Test- und Produktcluster verwenden, in denen Sie alle für eine bestimmte Umgebung bestimmten Anwendungsinstanzen ausführen.

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 für die Produktumgebung.

Produktionsversionen der Anwendung sind jetzt unabhängig davon, was in anderen Clustern und Umgebungen geschieht.

Wenn also plötzlich ein Problem im Entwicklungscluster auftritt, funktionieren die Produktversionen der Anwendungen weiterhin so, als wäre nichts passiert.

+ Cluster kann an die Umgebung angepasst werden

Jeder Cluster kann auf seine Umgebung zugeschnitten werden. Zum Beispiel können Sie:

Installieren Sie Entwicklungs- und Debugging-Tools im Entwicklungscluster.
Test - Frameworks und Tools im Installationstest Cluster ;
Verwenden Sie leistungsstärkere Geräte und Netzwerkkanäle im Produktcluster .

Auf diese Weise können Sie die Effizienz sowohl bei der Entwicklung als auch beim Betrieb von Anwendungen steigern.

+ Beschränken Sie den Zugriff auf den Produktionscluster

Die Notwendigkeit, direkt mit einem Produktcluster zu arbeiten, tritt selten auf, sodass Sie den Personenkreis, der Zugriff darauf hat, erheblich einschränken können.

Sie können noch weiter gehen und den Benutzern im Allgemeinen den Zugriff auf diesen Cluster verweigern und alle Bereitstellungen mit dem automatisierten CI / CD-Tool ausführen. Ein solcher Ansatz minimiert das Risiko menschlicher Fehler genau dort, wo es am relevantesten ist.

Und jetzt ein paar Worte zu den Nachteilen.

- Fehlende Isolation zwischen Anwendungen

Der Hauptnachteil des Ansatzes ist das Fehlen von Hardware- und Ressourcenisolation zwischen Anwendungen.

Nicht verwandte Anwendungen teilen sich Clusterressourcen: den Systemkern, den Prozessor, den Speicher und einige andere Dienste.

Wie bereits erwähnt, kann dies möglicherweise gefährlich sein.

- Unfähigkeit, Anwendungsabhängigkeiten zu lokalisieren

Wenn die Anwendung spezielle Anforderungen hat, müssen diese in allen Clustern erfüllt sein.

Wenn eine Anwendung beispielsweise eine GPU benötigt, muss jeder Cluster mindestens einen Worker mit einer GPU enthalten (auch wenn er nur von dieser Anwendung verwendet wird).

Infolgedessen laufen wir Gefahr, höhere Kosten und einen ineffizienten Ressourceneinsatz zu verursachen.

Fazit

Wenn Sie über einen bestimmten Satz von Anwendungen verfügen, können Sie diese in mehreren großen Clustern oder in vielen kleinen Clustern platzieren.

Der Artikel beschreibt die Vor- und Nachteile verschiedener Ansätze, die von einem globalen Cluster bis zu mehreren kleinen und hochspezialisierten reichen:

ein großer gemeinsamer Cluster;
viele kleine hochspezialisierte Cluster;
ein Cluster für jede Anwendung;
ein Cluster für jede Umgebung.

Welchen Ansatz wählen Sie?

Wie üblich hängt die Antwort vom Anwendungsfall ab: Sie müssen die Vor- und Nachteile verschiedener Ansätze abwägen und die optimalste Option auswählen.

Die Auswahl ist jedoch nicht auf die obigen Beispiele beschränkt - Sie können eine beliebige Kombination davon verwenden!

Ein Cluster für die Entwicklung (die haben: Zum Beispiel können Sie ein Paar Cluster pro Team organisieren Entwickler und Testumgebungen ) und einen Cluster für die Produktion (wo die Produktionsumgebung befinden wird).

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 in unserem Blog:

Entwerfen von Kubernetes-Clustern: Wie viele sollte es geben?