Bei der Erstellung eines Kubernetes-Clusters können Fragen auftreten: Wie viele Arbeitsknoten sollten eingerichtet werden und welchen Typ? Was ist besser für ein On-Premise-Cluster: einige leistungsstarke Server kaufen oder ein Dutzend älterer Maschinen in Ihrem Rechenzentrum nutzen? Und in der Cloud, sollte man acht Einzelkern- oder zwei Quad-Core-Instanzen wählen?
Die Antworten auf diese Fragen finden Sie im Artikel in der Übersetzung des Teams .
Die Kapazität des Clusters
Insgesamt kann ein Kubernetes-Cluster als großer "Superknoten" betrachtet werden. Die gesamte Rechenleistung ist die Summe der Kapazitäten aller beteiligten Knoten.
Es gibt mehrere Möglichkeiten, die gewünschte Kapazität des Clusters zu erreichen. Zum Beispiel benötigen wir einen Cluster mit einer Gesamtkapazität von 8 Prozessorkernen und 32 GB RAM, da der Satz an Anwendungen so viele Ressourcen benötigt. Dann könnte man zwei Knoten mit 16 GB RAM oder vier Knoten mit 8 GB RAM installieren, zwei Quad-Core-Prozessoren oder vier Dual-Core-Prozessoren.
Hier sind nur zwei mögliche Möglichkeiten, einen Cluster zu erstellen:
Beide Optionen bieten einen Cluster mit der gleichen Kapazität, aber in der Konfiguration unten gibt es vier kleinere Knoten, während in der Konfiguration oben zwei größere Knoten stehen.
Welche Option ist besser?
Um diese Frage zu beantworten, betrachten wir die Vorteile beider Optionen. Wir haben sie in einer Tabelle zusammengefasst.
Einige große Knoten
Viele kleine Knoten
Einfache Verwaltung des Clusters (wenn On-Premise)
Reibungslose Automatisierung der Skalierung
Kostengünstiger (wenn On-Premise)
Die Preise unterscheiden sich kaum (in der Cloud)
Ressourcenintensive Anwendungen können ausgeführt werden
Vollwertige Replikation
Ressourcen werden effizienter genutzt (weniger Overhead für System-Daemons)
Höhere Fehlertoleranz des Clusters
Bitte beachten Sie, dass wir hier nur über Arbeitsknoten sprechen. Die Wahl der Anzahl und Größe der Master-Knoten ist ein ganz anderes Thema.
Lassen Sie uns also jeden Punkt aus der Tabelle näher betrachten.
Erste Option: mehrere große Knoten
Die extremste Variante ist ein einzelner Arbeitsknoten für die gesamte Cluster-Kapazität. In dem obigen Beispiel würde dies ein Arbeitsknoten mit 16 CPU-Kernen und 16 GB RAM sein.
Vorteile
Vorteil Nr. 1. Einfachere Verwaltung
Es ist einfacher, mehrere Maschinen zu verwalten als einen ganzen Park. Updates und Fixes schneller anzuwenden und die Synchronisierung ist einfacher. Auch die Anzahl der Ausfälle in absoluten Zahlen ist geringer.
Bitte beachten Sie, dass alles, was bisher gesagt wurde, für eigene Hardware und Server gilt, nicht für Cloud-Instanzen.
In der Cloud ist die Situation anders. Dort ist der Cloud-Anbieter für die Verwaltung verantwortlich. Somit unterscheidet sich die Verwaltung von zehn Knoten in der Cloud nicht wesentlich von der Verwaltung eines einzelnen Knotens.
Die Traffic-Routing und Lastverteilung zwischen Pods in der Cloud : Der aus dem Internet kommende Traffic wird an den Hauptlastenausgleichsanschluss geleitet, der den Traffic an den Port eines der Knoten weiterleitet (der Service NodePort gibt einen Port im Bereich von 30000-32767 in jedem Knoten des Clusters frei). Die von kube-proxy festgelegten Regeln leiten den Traffic vom Knoten an den Pod weiter. So sieht das für zehn Pods auf zwei Knoten aus:
Plus Nummer 2. Niedrigere Kosten pro Knoten
Ein leistungsstarker Server ist teurer, aber der Preisanstieg ist nicht unbedingt linear. Mit anderen Worten, ein zehnkerniger Server mit 10 GB RAM ist in der Regel günstiger als zehn einstückige Server mit der gleichen Menge an RAM.
Bitte beachten Sie jedoch, dass diese Regel in der Regel nicht für Cloud-Dienste gilt. In den aktuellen Preismodellen aller großen Cloud-Anbieter steigen die Preise linear mit der Erhöhung der Kapazität.
Somit lässt sich in der Cloud normalerweise nicht bei leistungsstarken Servern sparen.
Plus Nummer 3. Ressourcenintensive Anwendungen können betrieben werden
Einige Anwendungen benötigen leistungsstarke Server im Cluster. Zum Beispiel, wenn ein maschinelles Lernsystem 8 GB RAM benötigt, können Sie es nicht auf Knoten mit 1 GB starten, sondern nur, wenn mindestens ein großer Arbeitsknoten vorhanden ist.
Nachteile
Nachteil Nummer 1. Viele Pods pro Knoten
Wenn dieselbe Aufgabe mit einer geringeren Anzahl von Knoten ausgeführt wird, dann gibt es natürlich mehr Pods auf jedem von ihnen.
Das könnte zum Problem werden.
Der Grund dafür ist, dass jedes Modul einige Overheadkosten für die Container-Laufzeitumgebung (zum Beispiel Docker) sowie für kubelet und cAdvisor verursacht.
Zum Beispiel überprüft kubelet regelmäßig die Lebensfähigkeit aller Container auf dem Knoten – je mehr Container, desto mehr Arbeit hat kubelet.
CAdvisor sammelt Statistiken über die Ressourcennutzung aller Container auf einem Knoten, während kubelet regelmäßig diese Informationen abruft und sie über die API bereitstellt. Je mehr Container vorhanden sind, desto mehr Arbeit gibt es sowohl für cAdvisor als auch für kubelet.
Wenn die Anzahl der Module steigt, kann dies das System verlangsamen und sogar dessen Zuverlässigkeit gefährden.
Im Kubernetes-Repository haben einige , dass die Knoten zwischen den Status Ready/NotReady springen, da die regelmäßigen Prüfungen von kubelet für alle Container auf dem Knoten zu viel Zeit in Anspruch nehmen.
Aus diesem Grund . Je nach Leistung des Knotens können Sie mehr Pods pro Knoten betreiben, aber es ist schwer vorherzusagen, ob Probleme auftreten oder ob alles reibungslos funktioniert. Es ist ratsam, die Funktion im Voraus zu testen.
Nachteil Nr. 2. Einschränkung bei der Replikation
Eine zu geringe Anzahl von Knoten schränkt den effektiven Replikationsgrad von Anwendungen ein. Wenn Sie beispielsweise eine Hochverfügbarkeitsanwendung mit fünf Replikaten haben, aber nur zwei Knoten verfügbar sind, reduziert sich der effektive Replikationsgrad der Anwendung auf zwei.
Fünf Replikate können nur auf zwei Knoten verteilt werden, und wenn einer von ihnen ausfällt, fallen sofort mehrere Replikate aus.
Wenn Sie fünf oder mehr Knoten haben, wird jede Replik auf einem separaten Knoten ausgeführt, und der Ausfall eines Knotens hat höchstens Auswirkungen auf eine Replik.
Daraus folgt, dass die Anforderungen an die Hochverfügbarkeit eine bestimmte Mindestanzahl von Knoten im Cluster erfordern können.
Nachteil Nr. 3. Schwerwiegendere Folgen eines Ausfalls
Bei einer geringen Anzahl von Knoten hat jeder Ausfall schwerwiegendere Auswirkungen. Wenn Sie beispielsweise nur zwei Knoten haben und einer davon ausfällt, verschwindet sofort die Hälfte Ihrer Module.
Natürlich wird Kubernetes die Arbeitslast von dem ausgefallenen Knoten auf andere verschieben. Aber wenn es nur wenige gibt, könnte der verfügbare Platz nicht ausreichen. Infolgedessen werden einige Ihrer Anwendungen nicht verfügbar sein, bis Sie den ausgefallenen Knoten wiederhergestellt haben.
Je mehr Knoten vorhanden sind, desto weniger Einfluss haben Hardwareausfälle.
Nachteil Nr. 4. Größere Schritte beim automatischen Skalieren
In Kubernetes gibt es ein System zur automatischen Skalierung von Clustern für Cloud-Infrastrukturen, das es ermöglicht, Knoten je nach aktuellen Bedürfnissen automatisch hinzuzufügen oder zu entfernen. Mit größeren Knoten wird die automatisierte Skalierung jedoch drastischer und ungeschickter. Wenn Sie beispielsweise zwei Knoten haben, erhöht das Hinzufügen eines zusätzlichen Knotens die Kapazität des Clusters sofort um 50%. Sie müssen jedoch auch für diese Ressourcen bezahlen, selbst wenn Sie sie nicht benötigen.
Wenn Sie also planen, die automatische Skalierung des Clusters zu nutzen, gilt: Je kleiner die Knoten, desto flexibler und kosteneffizienter wird 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 gegenteiligen Variante mit wenigen großen Knoten.
Vorteile
Plus Punkt Nr. 1. Geringere Auswirkungen bei Ausfällen
Je mehr Knoten vorhanden sind, desto weniger Pods befinden sich auf jedem Knoten. Wenn Sie beispielsweise hundert Pods auf zehn Knoten haben, befinden sich im Durchschnitt zehn Pods auf jedem Knoten.
Wenn also einer der Knoten ausfällt, verlieren Sie lediglich 10% der Arbeitslast. Es ist wahrscheinlich, dass nur eine geringe Anzahl von Replikaten betroffen ist, während die Anwendungen insgesamt weiterhin funktionsfähig bleiben.
Zudem stehen auf den verbleibenden Knoten wahrscheinlich ausreichende Ressourcen für die Arbeitslast des ausgefallenen Knotens zur Verfügung, sodass Kubernetes die Pods problemlos umplanen kann und Ihre Anwendungen relativ schnell wieder funktionsfähig sind.
Plus Punkt Nr. 2. Gute Replikation
Wenn genügend Knoten vorhanden sind, kann der Kubernetes-Planer jedem Replikat unterschiedliche Knoten zuweisen. Dadurch wird im Falle eines Knotenfehlers nur eine Replikat betroffen sein, während die Anwendung weiterhin verfügbar bleibt.
Nachteile
Minus Punkt Nr. 1. Schwierigeres Management
Eine größere Anzahl von Knoten ist schwieriger zu verwalten. Jeder Kubernetes-Knoten muss beispielsweise mit allen anderen Knoten interagieren, sodass die Anzahl der Verbindungen quadratisch wächst, und all diese Verbindungen müssen überwacht werden.
Der Knotencontroller im Kubernetes-Controller-Manager überprüft regelmäßig alle Knoten im Cluster auf ihre Funktionsfähigkeit - je mehr Knoten vorhanden sind, desto höher ist die Belastung für den Controller.
Die Belastung für die Datenbank etcd steigt ebenfalls - jeder Kubelet und Kube-Proxy ruft für etcd (über die API), an die etcd Updates von Objekten übertragen muss.
Im Allgemeinen verursacht jeder Arbeitsknoten zusätzliche Belastungen für die Systemkomponenten der Masterknoten.
Offiziell unterstützt Kubernetes Cluster mit In der Praxis können jedoch bereits 500 Knoten .
Um eine große Anzahl von Arbeitsknoten zu verwalten, sollten leistungsfähigere Masterknoten ausgewählt werden. Zum Beispiel installiert kube-up die passende VM-Größe für den Masterknoten abhängig von der Anzahl der Arbeitsknoten. Das bedeutet, je mehr Arbeitsknoten, desto leistungsfähiger müssen die Masterknoten sein.
Um diese spezifischen Probleme zu lösen, gibt es spezielle Entwicklungen wie Dieses System ermöglicht es, Einschränkungen zu umgehen und Cluster mit einer enormen Anzahl von Arbeitsknoten zu erstellen.
Nachteil Nr. 2. Höhere Overheadkosten.
Auf jedem Arbeitsknoten führt Kubernetes eine Reihe von System-Dämonen aus – dazu gehören die Container-Laufzeit (z. B. Docker), kube-proxy und kubelet, sowie cAdvisor. Gemeinsam verbrauchen sie eine bestimmte feste Menge an Ressourcen.
Wenn Sie viele kleine Knoten haben, ist der Anteil dieser Overheadkosten auf jedem Knoten höher. Stellen Sie sich beispielsweise vor, dass alle System-Dämonen eines Knotens zusammen 0,1 CPU-Kerne und 0,1 GB Speicher verbrauchen. Wenn Sie einen zehnekernigen Knoten mit 10 GB Speicher haben, verbrauchen die Dämonen 1% der Cluster-Kapazität. Auf der anderen Seite werden auf zehn ein Kernknoten mit je 1 GB Speicher die Dämonen 10% der Cluster-Kapazität beanspruchen.
Das bedeutet, je weniger Knoten, desto effizienter wird die Infrastruktur genutzt.
Nachteil Nr. 3. Ineffiziente Ressourcennutzung.
Auf kleinen Knoten kann es vorkommen, dass die verbleibenden Ressourcenausschnitte zu klein sind, um ihnen eine Arbeitslast zuzuweisen, weshalb sie ungenutzt bleiben.
Zum Beispiel benötigt jeder Pod 0,75 GB Speicher. Wenn Sie zehn Knoten haben und jeder 1 GB Speicher hat, können zehn Pods gestartet werden – am Ende verbleiben auf jedem Knoten 0,25 GB ungenutzter Speicher.
Das bedeutet, dass 25% des Speichers des gesamten Clusters ungenutzt bleiben.
Auf einem großen Knoten mit 10 GB Speicher können Sie 13 solcher Module starten – und es bleibt nur ein ungenutzter Abschnitt von 0,25 GB.
In diesem Fall werden nur 2,5% des Speichers ungenutzt.
So werden Ressourcen an großen Knoten optimal genutzt.
Mehrere große Knoten oder viele kleine?
Was ist also besser: mehrere große Knoten im Cluster oder viele kleine? Wie immer gibt es keine eindeutige Antwort. Vieles hängt von der Art der Anwendung ab.
Wenn eine Anwendung beispielsweise 10 GB Speicher benötigt, liegt die Wahl auf großen Knoten nahe. Wenn die Anwendung jedoch eine zehnfache Replikation für hohe Verfügbarkeit erfordert, sollte man nicht riskieren, die Replikate nur auf zwei Knoten zu verteilen — im Cluster sollten mindestens zehn Knoten vorhanden sein.
In Zwischensituationen treffen Sie die Wahl nach den Vor- und Nachteilen jeder Option. Möglicherweise sind einige Argumente relevanter für Ihre Situation als andere.
Es ist nicht unbedingt erforderlich, alle Knoten in der gleichen Größe zu gestalten. Nichts hindert Sie daran, zunächst mit Knoten derselben Größe zu experimentieren und dann Knoten anderer Größe hinzuzufügen, um sie im Cluster zu kombinieren. Die Arbeitsknoten eines Kubernetes-Clusters können vollständig heterogen sein. Sie können also versuchen, die Vorteile beider Ansätze zu vereinen.
Ein einzelnes Rezept existiert nicht, und jede Situation hat ihre eigenen Nuancen, die nur die Produktion zeigen wird.
Die Übersetzung wurde vom Team der Cloud-Plattform vorbereitet .
Mehr über Kubernetes: .
Quelle: habr.com
