Möglichkeiten der K8s-Autoskalierung im Überblick Was leistet Autoscaling in Kubernetes?

Skalierbarkeit ist eines der zentralen Leistungsversprechen von Kubernetes, kurz K8s. Neben Horizontal Pod Autoscaler und Vertical Pod Autoscaler findet sich der Cluster Autoscaler als dritte Autoscaling-Funktionalität in Kubernetes.

Rund ein Drittel der Webshop-Berucherinnen und -Besucher bricht hierzulande Online-Käufe ab, wenn die gewünschte Seite nach drei Sekunden nicht lädt. Weltweit sind es sogar zwei Drittel. Mithilfe von Autoscaling-Funktionen sind Online-Händler in der Lage, bei erhöhten Nutzeranfragen die Cloud-Ressourcen in einer Kubernetes-Infrastruktur dynamisch anzupassen, damit die Seite stabil bleibt.

Gleichzeitig hilft eine automatische Skalierung dabei, die Kosten zu optimieren, indem ein Cluster je nach aktuellem Bedarf dynamisch aufwärts und abwärts skaliert werden kann. Autoscaling wird in Kubernetes nach drei Funktionalitäten unterschieden: horizontale Pod-Autoscaler (HPA), vertikale Pod-Autoscaler (VPA) und Cluster-Autoscaler (CA). Alle drei Arten von K8s-Autoscalern dienen jeweils einem anderen Zweck.

Horizontales Pod-Autoscaling

HPA (auch: scaling out) skaliert die Anzahl der Pods in einem Replikations-Controller, einer Bereitstellung, einem Replikatsatz oder einem zustandsbehafteten Satz basierend auf der CPU-Auslastung. Das heißt, mit dem Controller ist es möglich, die Anzahl der Replikate in einem Bereitstellungs- oder Replikationscontroller regelmäßig anzupassen, um die beobachtete durchschnittliche CPU-Auslastung an das, vom Anwender angegebene Ziel anzugleichen.

Horizontale Pod-Autoscaler arbeiten kontinuierlich in einer Schleife von „prüfen, aktualisieren, erneut prüfen“ mit folgenden Schritten:

• 1. HPA überwacht Metrik-Server auf Ressourcennutzung.

• 2. Berechnung durch HPA der erforderlichen Anzahl von Replikaten auf der Grundlage des gesammelten Ressourcen-Verbrauchs.

• 3. Hochskalieren der Anwendung auf die erforderliche Anzahl von Replikaten.

• 4. Prozess wiederholt sich.

Wenn also eine Anwendung mehr Datenverkehr erhält, wird die Anzahl der Replikate vom Autoscaler automatisch reguliert, um mehr Anforderungen zu verarbeiten. Der Horizontal Pod Autoscaler (HPA) überprüft in regelmäßigen Abständen Metriken wie Arbeitsspeicher und CPU.

Es stehen die beiden HPA-Versionen v1 und v2 zur Verfügung. Die erste HPA-Version (autoscaling/v1) verfügt über eine sehr begrenzte Konfigurationsmöglichkeit und basiert ausschließlich auf einer durchschnittlichen CPU-Auslastung. Die zweite Version (autoscaling/V2) unterstützt die Verwendung von mehreren Metriken. Diese Metriken können auch vom Anwender definiert oder aus externen Quellen stammen.

Vertikales Pod-Autoscaling

VPA (auch: scaling up) eignet sich, wenn weitere Kopien der Pods nicht erstellbar sind, aber dennoch mehr Datenverkehr verarbeitet werden muss. So ist es nicht durch weiteres Hinzufügen von Pods möglich, eine Datenbank zu skalieren. Datenbanken erfordern beispielsweise Sharding oder das Konfigurieren von schreibgeschützten Replikaten.

Es wäre allerdings möglich, Datenbanken dazu zu verhelfen, mehr Verbindungen verarbeiten zu können, indem der Anwender ihnen mehr Arbeitsspeicher und CPU zur Verfügung stellt. Dies ist genau der Zweck eines vertikalen Autoscalers – das Hinzufügen oder Entfernen von Ressourcen (beispielsweise CPU oder Arbeitsspeicher) zu einem Pod.

Der Vertical Pod Autoscaler überwacht ständig die CPU- und Speicherauslastung der laufenden Anwendungen. Dadurch erhält der User Empfehlungen für die ideale Anzahl von Ressourcen, die einer bestimmten Anwendung zugeordnet werden sollten, und skaliert die Anwendung vertikal nach Bedarf.

Das heißt, mit der Kubernetes-Funktionalität VPA lassen sich die bereitgestellten Pods richtig dimensionieren und Probleme bei der Nutzung der Ressourcen im Cluster vermeiden. Somit bezieht sich das vertikale Pod-Autoscaling mehr auf die Kapazitätsplanung als andere Funktionalitäten der automatischen Skalierung von Kubernetes.

Horizontale vs. vertikale Skalierung

In der Folge einige wesentliche Vor- und Nachteile von HPA und VPA:

Vorteile des horizontalen Pod-Autoscaling:

• Für das Hinzufügen von zusätzlichen Ressourcen ist keine Ausschaltung von VMs notwendig.

• Mehrere VMs für den gleichen Workload erhöhen die Ausfallsicherheit.

• Nicht benötigte VMs werden je nach Bedarf ausgeschaltet, wodurch die Kosteneffizienz zunimmt.

• Lastspitzen lassen sich durch eine vollständige Automatisierung reduzieren.

Nachteile des horizontalen Pod-Autoscaling:

• Die Nachteile sind von der Situation des Anwenders wie beispielsweise Sicherung, Lizenzierung und hoher Komplexität abhängig.

Vorteile des vertikalen Pod-Autoscaling

• Reduzierte Wartungsintensität.

• Geringerer Bedarf an Lizenzen, da die Anzahl der ausgeführten Instanzen gleich bleibt.

Nachteile des vertikalen Pod-Autoscaling (VPA)

• Im Falle einer Fehlfunktion sind gleich mehrere User davon betroffen.

• Sehr unflexibel.

Cluster Autoscaler

Während die Autoscaling-Funktionalitäten HPA und VPA von Kubernetes auf Pod-Ebene arbeiten, ist der Cluster Autoscaler – wie der Name schon verrät – auf Cluster-Ebene aktiv. Dabei passt er die Anzahl der Knoten im Cluster an, wenn Pods nicht geplant werden können, Knoten nicht ausgelastet sind oder Pods ausfallen oder auf andere Knoten verlagert werden müssen.

Cluster Autoscaler weist jedoch auch einige Nachteile auf, die bei der Planung einer Implementierung beachtet werden sollten:

• CA trifft keine Skalierungsentscheidungen anhand der CPU- oder Speicherauslastung. Er überprüft nur die Anforderungen und Limits eines Pods für CPU- und Speicherressourcen. Diese Einschränkung bedeutet, dass die von den Anwendern angeforderten ungenutzten Rechenressourcen von dem CA nicht erkannt werden, was zu einem Cluster mit Verschwendung und geringer Nutzungseffizienz führt.

• Immer wenn eine Anforderung zum Hochskalieren eines Clusters vorliegt, sendet CA innerhalb von 30 bis 60 Sekunden eine Hochskalierungsanforderung an einen Cloud-Anbieter. Die tatsächliche Zeit, die der Cloud-Anbieter zum Erstellen eines Knotens benötigt, kann mehrere Minuten oder länger betragen. Diese Verzögerung bedeutet, dass die jeweilige Anwendungsleistung beeinträchtigt werden kann, während der User auf die erweiterte Clusterkapazität wartet.

(ID:49026441)