Beim Erstellen eines Kubernetes-Clusters können Fragen auftauchen: Wie viele Worker-Knoten müssen konfiguriert werden und welcher Typ? Was ist für einen On-Premise-Cluster besser: Kaufen Sie mehrere leistungsstarke Server oder nutzen Sie ein Dutzend alte Maschinen in Ihrem Rechenzentrum? Ist es besser, acht Single-Core- oder zwei Quad-Core-Instanzen in der Cloud zu nutzen?
Die Antworten auf diese Fragen finden Sie im Artikel. in der Übersetzung des Befehls .
Clusterkapazität
Im Allgemeinen kann man sich einen Kubernetes-Cluster als einen großen „Superknoten“ vorstellen. Seine gesamte Rechenleistung ist die Summe der Leistungen aller seiner konstituierenden Knoten.
Es gibt mehrere Möglichkeiten, Ihr gewünschtes Clusterkapazitätsziel zu erreichen. Wir benötigen beispielsweise einen Cluster mit einer Gesamtkapazität von 8 Prozessorkernen und 32 GB RAM, da eine Reihe von Anwendungen so viele Ressourcen erfordert. Dann können Sie zwei Knoten mit 16 GB Speicher oder vier Knoten mit 8 GB Speicher, zwei Quad-Core-Prozessoren oder vier Dual-Core-Prozessoren installieren.
Hier sind nur zwei Möglichkeiten, einen Cluster zu erstellen:
Beide Optionen erzeugen einen Cluster mit der gleichen Kapazität, aber die untere Konfiguration verfügt über vier kleinere Knoten und die obere Konfiguration über zwei größere Knoten.
Welche Option ist besser?
Um diese Frage zu beantworten, schauen wir uns die Vorteile beider Optionen an. Wir haben sie in einer Tabelle zusammengefasst.
Mehrere große Knoten
Viele kleine Knoten
Einfacheres Cluster-Management (wenn es vor Ort ist)
Reibungslose automatische Skalierung
Günstiger (wenn vor Ort)
Der Preis ist kaum anders (in der Cloud)
Kann ressourcenintensive Anwendungen ausführen
Vollständige Replikation
Ressourcen werden effizienter genutzt (weniger Overhead für System-Daemons).
Höhere Clusterfehlertoleranz
Bitte beachten Sie, dass es sich hier nur um Worker-Knoten handelt. Die Wahl der Anzahl und Größe der Hauptknoten ist ein völlig anderes Thema.
Lassen Sie uns jeden Punkt aus der Tabelle genauer besprechen.
Erste Option: mehrere große Knoten
Die extremste Option ist ein Worker-Knoten für die gesamte Clusterkapazität. Im obigen Beispiel wäre dies ein einzelner Worker-Knoten mit 16 CPU-Kernen und 16 GB RAM.
Pros
Plus Nr. 1. Einfachere Verwaltung
Es ist einfacher, ein paar Maschinen zu verwalten als eine ganze Flotte. Updates und Fixes lassen sich schneller bereitstellen und die Synchronisierung ist einfacher. Auch die Zahl der Ausfälle in absoluten Zahlen ist geringer.
Bitte beachten Sie, dass alle oben genannten Punkte für Ihre Hardware, Ihre Server und nicht für Cloud-Instanzen gelten.
Anders sieht es in der Cloud aus. Dort übernimmt der Cloud-Dienstleister die Verwaltung. Daher unterscheidet sich die Verwaltung von zehn Knoten in der Cloud nicht wesentlich von der Verwaltung eines Knotens.
Traffic-Routing und Lastverteilung zwischen Pods in der Cloud : Aus dem Internet kommender Datenverkehr wird an den Haupt-Load-Balancer gesendet, der den Datenverkehr an den Port eines der Knoten weiterleitet (der NodePort-Dienst legt den Port in jedem Cluster-Knoten im Bereich 30000-32767 fest). Die von kube-proxy festgelegten Regeln leiten den Datenverkehr vom Knoten zum Pod um. So sieht es für zehn Pods auf zwei Knoten aus:
Vorteil Nr. 2: Weniger Kosten pro Knoten
Ein leistungsstarkes Auto ist teurer, aber der Preisanstieg verläuft nicht unbedingt linear. Mit anderen Worten: Ein Zehn-Core-Server mit 10 GB Speicher ist in der Regel günstiger als zehn Single-Core-Server mit der gleichen Speichermenge.
Beachten Sie jedoch, dass diese Regel bei Cloud-Diensten normalerweise nicht funktioniert. In den aktuellen Preissystemen aller großen Cloud-Anbieter steigen die Preise linear mit der Kapazität.
Daher kann man in der Cloud meist nicht an leistungsfähigeren Servern sparen.
Vorteil Nr. 3: Sie können ressourcenintensive Anwendungen ausführen
Einige Anwendungen erfordern leistungsstarke Server in einem Cluster. Wenn ein maschinelles Lernsystem beispielsweise 8 GB Speicher benötigt, können Sie es nicht auf 1-GB-Knoten ausführen, sondern nur mit mindestens einem großen Worker-Knoten.
Cons
Nachteil Nr. 1. Viele Pods pro Knoten
Wenn die gleiche Aufgabe auf weniger Knoten ausgeführt wird, verfügt jeder von ihnen natürlich über mehr Pods.
Dies könnte ein Problem sein.
Der Grund dafür ist, dass jedes Modul einen gewissen Overhead für die Containerlaufzeit (z. B. Docker) sowie für Kubelet und cAdvisor verursacht.
Beispielsweise prüft ein Kubelet regelmäßig alle Container auf einem Knoten auf Überlebensfähigkeit – je mehr Container, desto mehr Arbeit muss das Kubelet leisten.
CAdvisor sammelt Ressourcennutzungsstatistiken für alle Container auf einem Knoten, und Kubelet fragt diese Informationen regelmäßig ab und stellt sie über eine API bereit. Auch hier bedeuten mehr Container mehr Arbeit für cAdvisor und Kubelet.
Wenn die Anzahl der Module zunimmt, kann dies das System verlangsamen und sogar seine Zuverlässigkeit beeinträchtigen.
Im Kubernetes-Repository einige dass Knoten zwischen den Status „Bereit“ und „Nicht bereit“ wechseln, weil regelmäßige Kubelet-Prüfungen aller Container auf einem Knoten zu lange dauern.
Aus diesem Grund Kubernetes . Abhängig von der Leistung des Knotens können Sie mehr Pods pro Knoten ausführen, es ist jedoch schwer vorherzusagen, ob es Probleme geben wird oder alles gut funktioniert. Es lohnt sich, die Arbeit vorab zu testen.
Nachteil Nr. 2. Einschränkung der Replikation
Zu wenige Knoten schränken den effektiven Umfang der Anwendungsreplikation ein. Wenn Sie beispielsweise über eine Hochverfügbarkeitsanwendung mit fünf Replikaten, aber nur zwei Knoten verfügen, wird der effektive Replikationsgrad der Anwendung auf zwei reduziert.
Fünf Replikate können nur auf zwei Knoten verteilt werden. Wenn einer von ihnen ausfällt, werden mehrere Replikate gleichzeitig deaktiviert.
Wenn Sie fünf oder mehr Knoten haben, wird jedes Replikat auf einem separaten Knoten ausgeführt, und bei Ausfall eines Knotens wird höchstens ein Replikat entfernt.
Daher erfordern Hochverfügbarkeitsanforderungen möglicherweise eine bestimmte Mindestanzahl von Knoten im Cluster.
Nachteil Nr. 3. Schlimmere Folgen eines Scheiterns
Bei einer geringen Anzahl von Knoten hat jeder Ausfall schwerwiegendere Folgen. Wenn Sie beispielsweise nur zwei Knoten haben und einer davon ausfällt, verschwindet die Hälfte Ihrer Module sofort.
Natürlich wird Kubernetes die Arbeitslast vom ausgefallenen Knoten auf andere verlagern. Wenn es jedoch nur wenige davon gibt, ist möglicherweise nicht genügend freie Kapazität vorhanden. Infolgedessen sind einige Ihrer Anwendungen nicht verfügbar, bis Sie den ausgefallenen Knoten aufrufen.
Je mehr Knoten vorhanden sind, desto geringer sind die Auswirkungen von Hardwareausfällen.
Nachteil Nr. 4: Mehr Schritte zur automatischen Skalierung
Kubernetes verfügt über ein Cluster-Auto-Scaling-System für die Cloud-Infrastruktur, mit dem Sie je nach Ihren aktuellen Anforderungen automatisch Knoten hinzufügen oder entfernen können. Bei größeren Knoten wird die automatische Skalierung abrupter und umständlicher. Wenn Sie beispielsweise auf zwei Knoten einen zusätzlichen Knoten hinzufügen, erhöht sich die Clusterkapazität sofort um 50 %. Und Sie müssen für diese Ressourcen bezahlen, auch wenn Sie sie nicht benötigen.
Wenn Sie also planen, die automatische Cluster-Skalierung zu verwenden, gilt: Je kleiner die Knoten, desto flexibler und kostengünstiger ist die Skalierung.
Schauen wir uns nun die Vor- und Nachteile einer großen Anzahl kleiner Knoten an.
Zweite Option: viele kleine Knoten
Die Vorteile dieses Ansatzes ergeben sich im Wesentlichen aus den Nachteilen der umgekehrten Variante mit mehreren großen Knoten.
Pros
Vorteil Nr. 1: Weniger Auswirkungen von Fehlern
Je mehr Knoten, desto weniger Pods auf jedem Knoten. Wenn Sie beispielsweise über einhundert Module pro zehn Knoten verfügen, verfügt jeder Knoten über durchschnittlich zehn Module.
Wenn einer der Knoten ausfällt, verlieren Sie auf diese Weise nur 10 % der Arbeitslast. Es besteht die Möglichkeit, dass nur eine kleine Anzahl von Replikaten betroffen ist und die gesamte Anwendung weiterhin betriebsbereit bleibt.
Darüber hinaus verfügen die verbleibenden Knoten wahrscheinlich über genügend freie Ressourcen, um die Arbeitslast des ausgefallenen Knotens zu bewältigen, sodass Kubernetes die Pods frei neu planen kann und Ihre Anwendungen relativ schnell wieder in einen funktionsfähigen Zustand zurückkehren.
Vorteil Nr. 2: Gute Replikation
Wenn genügend Knoten vorhanden sind, kann der Kubernetes-Scheduler allen Replikaten unterschiedliche Knoten zuweisen. Auf diese Weise ist beim Ausfall eines Knotens nur ein Replikat betroffen und die Anwendung bleibt verfügbar.
Cons
Nachteil Nr. 1. Schwer zu kontrollieren
Eine große Anzahl von Knoten ist schwieriger zu verwalten. Beispielsweise muss jeder Kubernetes-Knoten mit allen anderen kommunizieren, das heißt, die Anzahl der Verbindungen wächst quadratisch und alle diese Verbindungen müssen verfolgt werden.
Der Knoten-Controller im Kubernetes Controller Manager durchläuft regelmäßig alle Knoten im Cluster, um den Zustand zu überprüfen – je mehr Knoten, desto höher die Belastung des Controllers.
Auch die Belastung der etcd-Datenbank wächst – mit jedem Kubelet- und Kube-Proxy-Aufruf für etcd (über die API), an den etcd Objektaktualisierungen senden soll.
Im Allgemeinen belastet jeder Worker-Knoten die Systemkomponenten der Master-Knoten zusätzlich.
Kubernetes unterstützt offiziell Cluster mit . In der Praxis gibt es jedoch bereits 500 Knoten .
Um eine große Anzahl von Worker-Knoten zu verwalten, sollten Sie leistungsfähigere Master-Knoten wählen. Zum Beispiel Kube-Up die richtige VM-Größe für den Master-Knoten abhängig von der Anzahl der Worker-Knoten. Das heißt, je mehr Worker-Knoten vorhanden sind, desto produktiver sollten die Master-Knoten sein.
Zur Lösung dieser spezifischen Probleme gibt es spezielle Entwicklungen, wie z . Mit diesem System können Sie Einschränkungen umgehen und Cluster mit einer großen Anzahl von Worker-Knoten aufbauen.
Nachteil Nr. 2: Höhere Gemeinkosten.
Auf jedem Worker-Knoten führt Kubernetes eine Reihe von System-Daemons aus – dazu gehören die Container-Laufzeitumgebung (z. B. Docker), kube-proxy und kubelet, einschließlich cAdvisor. Zusammen verbrauchen sie eine bestimmte feste Menge an Ressourcen.
Wenn Sie viele kleine Knoten haben, ist der Anteil dieses Overheads auf jedem Knoten größer. Stellen Sie sich beispielsweise vor, dass alle Systemdämonen auf einem einzelnen Knoten zusammen 0,1 CPU-Kerne und 0,1 GB Arbeitsspeicher nutzen. Wenn Sie über einen Knoten mit zehn Kernen und 10 GB Arbeitsspeicher verfügen, verbrauchen Daemons 1 % der Clusterkapazität. Auf zehn Single-Core-Knoten mit 1 GB Speicher hingegen beanspruchen die Daemons 10 % der Clusterkapazität.
Je weniger Knoten vorhanden sind, desto effizienter wird die Infrastruktur genutzt.
Nachteil Nr. 3. Ineffiziente Ressourcennutzung
Auf kleinen Knoten kann es sein, dass die verbleibenden Ressourcenblöcke zu klein sind, um ihnen eine Arbeitslast zuzuweisen, sodass sie ungenutzt bleiben.
Beispielsweise benötigt jeder Pod 0,75 GB Speicher. Wenn Sie zehn Knoten mit jeweils 1 GB Speicher haben, können Sie zehn Pods ausführen, sodass jeder Knoten über 0,25 GB ungenutzten Speicher verfügt.
Dies bedeutet, dass 25 % des Speichers des gesamten Clusters verschwendet werden.
Auf einem großen Knoten mit 10 GB Speicher können Sie 13 dieser Module ausführen – und es bleibt nur ein ungenutztes Fragment von 0,25 GB übrig.
In diesem Fall werden nur 2,5 % des Speichers verschwendet.
Dadurch werden Ressourcen auf größeren Knoten optimaler genutzt.
Mehrere große Knoten oder viele kleine?
Was ist also besser: ein paar große Knoten in einem Cluster oder viele kleine? Wie immer gibt es keine klare Antwort. Viel hängt von der Art der Anwendung ab.
Wenn eine Anwendung beispielsweise 10 GB Speicher benötigt, sind größere Knoten eine naheliegende Wahl. Und wenn eine Anwendung für eine hohe Verfügbarkeit eine zehnfache Replikation erfordert, lohnt es sich kaum, das Risiko einzugehen, Replikate auf nur zwei Knoten zu platzieren – es müssen mindestens zehn Knoten im Cluster vorhanden sein.
Treffen Sie in Zwischensituationen eine Wahl basierend auf den Vor- und Nachteilen jeder Option. Vielleicht sind einige Argumente für Ihre Situation relevanter als andere.
Und es ist überhaupt nicht notwendig, alle Knoten gleich groß zu machen. Nichts hindert Sie daran, zunächst mit Knoten gleicher Größe zu experimentieren und ihnen dann Knoten unterschiedlicher Größe hinzuzufügen und sie in einem Cluster zusammenzufassen. Worker-Knoten in einem Kubernetes-Cluster können völlig heterogen sein. Sie können also versuchen, die Vorteile beider Ansätze zu kombinieren.
Es gibt kein einheitliches Rezept und jede Situation hat ihre eigenen Nuancen, und nur die Produktion wird die Wahrheit ans Licht bringen.
Vom Cloud-Plattform-Team erstellte Übersetzung .
Mehr über Kubernetes: .
Source: habr.com