Drei Ebenen der automatischen Skalierung in Kubernetes: Wie man sie effektiv nutzt

Für das umfassende Verständnis von Kubernetes ist es wichtig, verschiedene Methoden zur Skalierung von Clusterressourcen zu kennen: laut den Entwicklern des Systems, ist das eine der Hauptaufgaben von Kubernetes. Wir haben einen Überblick über die Mechanismen der horizontalen und vertikalen Automatisierung sowie der Größenänderung von Clustern vorbereitet und Empfehlungen zusammengestellt, wie man diese effektiv nutzen kann.

Der Artikel Kubernetes Autoscaling 101: Cluster Autoscaler, Horizontal Autoscaler und Vertical Pod Autoscaler wurde von einem Team übersetzt, das das Autoscaling in Kubernetes aaS von Mail.ru.

Warum es wichtig ist, über Skalierung nachzudenken

Kubernetes – ein Werkzeug zur Verwaltung von Ressourcen und Orchestrierung. Natürlich ist es auch schön, mit tollen Funktionen für Bereitstellung, Überwachung und Verwaltung von Pods zu experimentieren (ein Pod-Modul ist eine Gruppe von Containern, die als Antwort auf eine Anfrage ausgeführt werden).

Es gibt jedoch auch andere Überlegungen:

1. Wie kann man Module und Anwendungen skalieren?
2. Wie hält man Container in einem arbeitsfähigen und effizienten Zustand?
3. Wie reagiert man auf ständige Änderungen im Code und auf Nutzerlasten?

Die Konfiguration von Kubernetes-Clustern zur Ressourcenausbalancierung und Leistungsoptimierung kann eine komplexe Aufgabe sein, die Fachwissen über die interne Funktionsweise von Kubernetes erfordert. Die Last auf Ihre Anwendung oder Dienste kann im Laufe des Tages oder sogar innerhalb einer Stunde variieren, daher ist es besser, die Balance als einen kontinuierlichen Prozess zu betrachten.

Ebenen des Kubernetes-Autoscalings

Effektives Autoscaling erfordert Koordination zwischen zwei Ebenen:

1. Die Pod-Ebene, die das horizontale Autoscaling (Horizontal Pod Autoscaler, HPA) und das vertikale Autoscaling (Vertical Pod Autoscaler, VPA) umfasst. Dies ist die Skalierung der vorhandenen Ressourcen für Ihre Container.
2. Die Cluster-Ebene, die vom Cluster-Autoscaler (Cluster Autoscaler, CA) verwaltet wird, der die Anzahl der Knoten innerhalb des Clusters erhöht oder verringert.

Modul für horizontales Autoscaling (HPA)

Wie der Name schon sagt, skaliert der HPA die Anzahl der Pod-Repliken. Als Trigger für die Änderung der Anzahl der Repliken nutzen die meisten DevOps die CPU- und Speicherauslastung. Es ist jedoch auch möglich, das System basierend auf benutzerdefinierten Metriken, deren Kombination oder sogar externer Metriken.

Hochrangiges Schema für die Funktionsweise des HPA:

1. HPA überwacht kontinuierlich die bei der Einrichtung angegebenen Metrikwerte mit dem standardmäßigen Intervall von 30 Sekunden.
2. HPA versucht, die Anzahl der Pods zu erhöhen, wenn ein festgelegter Schwellenwert erreicht wird.
3. HPA aktualisiert die Anzahl der Replikate innerhalb des Deployments/Replikationscontrollers.
4. Der Deployment-/Replikationscontroller setzt dann alle erforderlichen zusätzlichen Pods in Betrieb.

HPA startet den Prozess zur Bereitstellung von Pods, wenn der Schwellenwert der Metriken erreicht wird.

Bei der Verwendung von HPA beachten Sie Folgendes:

• Das Standardprüfintervall von HPA beträgt 30 Sekunden. Es wird durch das Flag festgelegt. horizontal-pod-autoscaler-sync-period im Controller-Manager.
• Die relative Fehlertoleranz beträgt standardmäßig 10%.
• Nach der letzten Erhöhung der Anzahl der Pods wartet HPA drei Minuten auf die Stabilisierung der Metriken. Dieses Intervall wird durch das Flag festgelegt. horizontal-pod-autoscaler-upscale-delay.
• Nach der letzten Verringerung der Anzahl der Pods wartet HPA fünf Minuten auf die Stabilisierung. Dieses Intervall wird durch das Flag festgelegt. horizontal-pod-autoscaler-downscale-delay.
• HPA funktioniert am besten mit Deployment-Objekten und nicht mit Replikationscontrollern. Horizontales Autoskalieren ist nicht kompatibel mit Rollout-Updates, die direkt mit Replikationscontrollern arbeiten. Bei einem Deployment hängt die Anzahl der Replikate direkt von den Deployment-Objekten ab.

Vertikale Skalierung von Pods

Die vertikale Skalierung (VPA) weist bestehenden Pods mehr (oder weniger) CPU- oder Speicherressourcen zu. Sie ist für zustandsbehaftete (stateful) oder zustandsfreie (stateless) Pods geeignet, ist jedoch hauptsächlich für stateful-Dienste gedacht. Dennoch können Sie VPA auch für stateless-Module anwenden, wenn Sie die ursprünglich zugewiesenen Ressourcen automatisch anpassen müssen.

Die VPA reagiert ebenfalls auf OOM-Ereignisse (Out of Memory, nicht genügend Speicher). Um die CPU-Zeit und den Speicher zu ändern, ist ein Neustart der Pods erforderlich. Bei einem Neustart berücksichtigt VPA das Verteilungskostenbudget (pods distribution budget, PDB), um die minimal erforderliche Anzahl von Pods sicherzustellen.

Sie können den minimalen und maximalen Ressourcenverbrauch für jedes Modul festlegen. So lässt sich der maximale Arbeitsspeicher auf 8 GB begrenzen. Dies ist nützlich, wenn die aktuellen Knoten nicht mehr als 8 GB Speicher pro Container bereitstellen können. Detaillierte Spezifikationen und Funktionsweisen sind beschrieben in der offiziellen VPA-Wiki.

Darüber hinaus verfügt die VPA über eine interessante Empfehlungsfunktion (VPA Recommender). Sie überwacht den Ressourcenverbrauch und OOM-Ereignisse aller Module, um neue Werte für den Speicher und die CPU-Zeit basierend auf einem intelligenten Algorithmus unter Berücksichtigung historischer Metriken vorzuschlagen. Es gibt auch eine API, die einen Pod-Descriptor akzeptiert und die vorgeschlagenen Ressourcenwerte zurückgibt.

Es ist wichtig zu beachten, dass der VPA Recommender die "Limits" der Ressourcen nicht überwacht. Dies kann dazu führen, dass ein Modul die Ressourcen innerhalb der Knoten monopolisiert. Es ist besser, ein Grenzwert auf Namespace-Ebene festzulegen, um einen übermäßigen Verbrauch von Speicher oder CPU-Zeit zu vermeiden.

Hohe Überblick über die Funktionsweise der VPA:

1. Die VPA prüft kontinuierlich die angegebenen Metrikwerte in Intervallen von standardmäßig 10 Sekunden.
2. Wenn der festgelegte Schwellenwert erreicht wird, versucht die VPA, die zugewiesene Ressourcenzahl zu ändern.
3. Die VPA aktualisiert die Anzahl der Ressourcen innerhalb des Deployments-/Replica-Controllers.
4. Bei einem Neustart der Module werden alle neuen Ressourcen auf die erstellten Instanzen angewandt.

Die VPA fügt die erforderliche Menge an Ressourcen hinzu.

Berücksichtigen Sie bei der Verwendung von VPA folgende Punkte:

• Das Skalieren erfordert einen obligatorischen Neustart des Pods. Dies ist notwendig, um Instabilitäten nach Änderungen zu vermeiden. Zur Sicherheit starten die Module neu und verteilen sich auf Knoten basierend auf den neuen zugewiesenen Ressourcen.
• Die VPA und HPA sind derzeit nicht miteinander kompatibel und können nicht auf denselben Pods arbeiten. Wenn Sie beide Skalierungsmechanismen in einem Cluster anwenden, stellen Sie sicher, dass die Einstellungen nicht zulassen, dass sie auf denselben Objekten aktiviert werden.
• VPA konfiguriert Containeranfragen an Ressourcen basierend auf deren vergangenem und aktuellem Nutzung. Es legt keine Nutzungslimits für Ressourcen fest. Es können Probleme mit der fehlerhaften Funktion von Anwendungen auftreten, die zunehmend Ressourcen beanspruchen, was dazu führt, dass Kubernetes das betreffende Pod abschaltet.
• VPA befindet sich derzeit noch in der frühen Entwicklungsphase. Seien Sie darauf vorbereitet, dass das System in naher Zukunft einige Änderungen erfahren könnte. Sie können über bekannte Einschränkungen und Entwicklungspläne. So ist geplant, eine Zusammenarbeit zwischen VPA und HPA zu implementieren sowie die Bereitstellung von Modulen zusammen mit einer Politik der vertikalen automatischen Skalierung für diese (z. B. ein spezielles Label ‘requires VPA’).

Automatische Skalierung des Kubernetes-Clusters

Der Cluster-Autoscaler (CA) verändert die Anzahl der Knoten basierend auf der Anzahl der wartenden Pod-Module. Das System überprüft regelmäßig das Vorhandensein wartender Module – und erhöht die Größe des Clusters, wenn mehr Ressourcen benötigt werden und das Cluster nicht die festgelegten Limits überschreitet. CA interagiert mit dem Anbieter von Cloud-Diensten, fordert zusätzliche Knoten an oder gibt inaktive frei. Die erste öffentliche Version von CA wurde in Kubernetes 1.8 vorgestellt.

Hochrangiges Schema der Funktionsweise von CA:

1. CA überprüft alle 10 Sekunden standardmäßig das Vorhandensein von Modulen im Wartestatus.
2. Wenn ein oder mehrere Module im Wartestatus sind, weil im Cluster nicht genügend verfügbare Ressourcen zur Verfügung stehen, versucht er, einen oder mehrere zusätzliche Knoten vorzubereiten.
3. Wenn der Cloud-Diensteanbieter den erforderlichen Knoten bereitstellt, wird dieser dem Cluster hinzugefügt und ist bereit, die Pod-Module zu bedienen.
4. Der Kubernetes-Planer verteilt die wartenden Module auf den neuen Knoten. Wenn anschließend einige Module weiterhin im Wartestatus bleiben, wird der Prozess wiederholt – und es werden neue Knoten dem Cluster hinzugefügt.

Automatische Bereitstellung von Knoten im Cloud-Cluster

Berücksichtigen Sie Folgendes bei der Verwendung von CA:

• CA gewährleistet, dass alle Module im Cluster Platz zum Ausführen haben, unabhängig von der CPU-Auslastung. Darüber hinaus versucht er sicherzustellen, dass im Cluster keine unnötigen Knoten vorhanden sind.
• CA registriert die Notwendigkeit zur Skalierung ungefähr nach 30 Sekunden.
• Nachdem ein Knoten nicht mehr benötigt wird, wartet CA standardmäßig 10 Minuten, bevor das System skaliert wird.
• Im automatischen Skalierungssystem gibt es das Konzept von Erweiterungen (expanders). Dies sind verschiedene Strategien zur Auswahl der Knoten, zu denen neue hinzugefügt werden.
• Verwenden Sie die Option verantwortungsbewusst cluster-autoscaler.kubernetes.io/safe-to-evict (true). Wenn viele Pods bereitgestellt werden oder wenn viele von ihnen auf mehreren Knoten verteilt sind, verlieren Sie erheblich die Möglichkeit, den Cluster zu verkleinern.
• Verwenden Sie PodDisruptionBudgets, um das Löschen von Pods zu verhindern, wodurch ein Teil Ihrer Anwendung vollständig ausfallen könnte.

Wie Kubernetes automatisierte Skalierungssysteme zusammenspielen

Für eine ideale Harmonie sollte sowohl auf Pod-Ebene (HPA/VPA) als auch auf Cluster-Ebene automatisches Scaling angewendet werden. Sie interagieren relativ einfach miteinander:

1. HPA oder VPA aktualisieren die Replikate von Pods oder die Ressourcen, die für bestehende Pods zugewiesen sind.
2. Wenn für die geplante Skalierung nicht genügend Knoten vorhanden sind, merkt CA, dass Pods im Wartestatus sind.
3. CA weist neue Knoten zu.
4. Module werden auf neuen Knoten verteilt.

Gemeinsames System von Kubernetes-Skalierungssystemen

Typische Fehler bei der automatischen Skalierung von Kubernetes

Es gibt mehrere typische Probleme, auf die DevOps stoßen, wenn sie versuchen, automatische Skalierung anzuwenden.

HPA und VPA hängen von Metriken und bestimmten historischen Daten ab. Wenn nicht genügend Ressourcen zugewiesen sind, werden die Module verkleinert und können keine Metriken generieren. In diesem Fall wird die automatische Skalierung niemals stattfinden.

Der eigentliche Skalierungsvorgang ist zeitkritisch. Wir möchten, dass sich Module und Cluster schnell skalieren – bevor Benutzer Probleme oder Ausfälle bemerken. Daher sollte die durchschnittliche Skalierungszeit von Pods und dem Cluster berücksichtigt werden.

Das ideale Szenario ist 4 Minuten:

1. 30 Sekunden. Aktualisierung der Zielmetriken: 30−60 Sekunden.
2. 30 Sekunden. HPA überprüft die Metrikwerte: 30 Sekunden.
3. Weniger als 2 Sekunden. Pods werden erstellt und gehen in den Wartestatus über: 1 Sekunde.
4. Weniger als 2 Sekunden. CA sieht wartende Module und sendet Anfragen zur Vorbereitung der Knoten: 1 Sekunde.
5. 3 Minuten. Der Cloud-Anbieter weist Knoten zu. K8s wartet, bis sie bereit sind: bis zu 10 Minuten (abhängig von mehreren Faktoren).

Das schlimmste (realistischere) Szenario – 12 Minuten:

1. 30 Sekunden. Aktualisierung der Zielmetriken.
2. 30 Sekunden. HPA überprüft die Metrikwerte.
3. Weniger als 2 Sekunden. Pod-Module werden erstellt und gelangen in den Wartestatus.
4. Weniger als 2 Sekunden. CA sieht die wartenden Module und sendet Anfragen zur Vorbereitung der Knoten.
5. 10 Minuten. Der Cloud-Anbieter weist Knoten zu. K8s wartet, bis sie bereit sind. Die Wartezeit hängt von mehreren Faktoren ab, wie der Lieferverzögerung des Anbieters, der Verzögerung des Betriebssystems und dem Betrieb von Hilfstools.

Verwechseln Sie nicht die Skalierungsmechanismen der Cloud-Anbieter mit unserer CA. Letztere arbeitet innerhalb des Kubernetes-Clusters, während der Mechanismus des Cloud-Anbieters auf der Zuweisung von Knoten basiert. Er weiß nicht, was mit Ihren Pods oder Anwendungen passiert. Diese Systeme arbeiten parallel.

Wie man das Skalieren in Kubernetes verwaltet

1. Kubernetes ist ein Werkzeug zur Verwaltung von Ressourcen und zur Orchestrierung. Die Verwaltung von Pods und Ressourcen im Cluster ist ein wichtiger Meilenstein im Lernen von Kubernetes.
2. Verstehen Sie die Logik der Skalierbarkeit von Pods unter Berücksichtigung von HPA und VPA.
3. CA sollte nur verwendet werden, wenn Sie die Anforderungen Ihrer Pods und Container gut verstehen.
4. Für eine optimale Clusterkonfiguration ist es wichtig zu verstehen, wie verschiedene Skalierungssysteme zusammenarbeiten.
5. Berücksichtigen Sie bei der Bewertung der Skalierungszeiten die schlechtesten und besten Szenarien.

Quelle: habr.com