Azure Kubernetes Service (AKS) Cluster Autoscaler unter der Lupe

Der Cluster Autoscaler für Azure Kubernetes Service (AKS) ist bereits seit geraumer Zeit verfügbar. Ich habe ihn bereits für mehrere Projekte verwendet. Dieser Beitrag erklärt alle Details des AKS Cluster Autoscalers. Er beschreibt, wie Sie ihn sowohl für neue als auch für vorhandene AKS Cluster aktivieren können, und zeigt ein Beispiel für die Verwendung einer benutzerdefinierten Autoscaler-Profileinstellung.

In diesem Artikel:

Was ist der AKS Cluster Autoscaler?

Mit dem Cluster Autoscaler wird die tatsächliche Arbeitslast Ihrer Worker Nodes aktiv überwacht. Durch das Hinzufügen und Entfernen von Worker Nodes im Cluster wird sichergestellt, dass ausreichend Ressourcen verfügbar sind, um die Anwendung fehlerfrei und reaktionsschnell betreiben zu können. Im Gegensatz dazu werden Worker Nodes aus dem AKS Cluster entfernt, um somit die Ressourcennutzung zu optimieren und so kostengünstig wie möglich zu arbeiten.

Die AKS Cluster Autoscaler-Komponente prüft, ob Pods vorhanden sind, die aufgrund von Ressourceneinschränkungen nicht im Cluster bereitgestellt werden können. Ist dies der Fall, skaliert der Cluster Autoscaler den Cluster (er fügt dem AKS Cluster Worker Nodes hinzu).

Wenn die Gesamtauslastung der Ressourcen sinkt und die Worker Nodes über einen längeren Zeitpunkt geringer ausgelastet sind, wird der Cluster zurück skaliert (Worker Nodes werden aus AKS entfernt).

Vielleicht sind Sie mit Kubernetes Horizontal Pod Autoscaling (HPA) vertraut. Es erlaubt, die Pods auf der Grundlage ihrer tatsächlichen Ressourcennutzung ein- oder auszuskalieren. Konzeptionell ist dies zwar sehr ähnlich, jedoch auf einer anderen architektonischen Ebene. Sie können HPA und Cluster Autoscaler auch kombinieren, um ein wirklich elastisches Kubernetes-Cluster in Microsoft Azure zu erstellen.

Warum sollten Sie den Cluster Autoscaler verwenden?

Eine grundsolide Prognose hinsichtlich der Skalierbarkeit für Cloud-Native Anwendungen oder SaaS-Projekte zu erstellen, kann schwierig sein. Die unerwartete Last kann jederzeit auftreten. Stellen Sie sich vor, Ihre Lösung wird in einer der bedeutendsten Online-Communities vorgestellt, oder denken Sie über das Gegenteil nach. Oder Ihr aktuelles Produkt, das bereits in AKS läuft, hilft Teams dabei, während der Arbeit von zu Hause aus in Verbindung zu bleiben. An Wochenenden sinkt die Gesamtnutzung Ihrer Anwendung dann um bspw. 90 %.

Es gibt Hunderte von Szenarien und Aspekten, die die Arbeitslast Ihrer Infrastruktur innerhalb von Stunden, Minuten oder sogar Sekunden dramatisch beeinflussen können. (Wetter, Tageszeit, Ferienzeit, …).

Der AKS Cluster Autoscaler ermöglicht es Ihnen, Ihre Anwendung reaktionsschnell und fehlerfrei zu halten, indem Sie das Risiko von Ressourcenengpässen minimieren. Darüber hinaus minimiert der Cluster Autoscaler Ihre Betriebskosten (OpEx), indem er den AKS skaliert, wenn der Cluster mit geringerer Arbeitslast zurechtkommen muss.

Das automatisierte Skalierungsverhalten des gesamten Clusters macht den AKS Cluster Autoscaler zu einem obligatorischen und wesentlichen Feature, das jeder AKS-Kunde kennen sollte.

Aktivieren des Azure Kubernetes Service Cluster Autoscalers

Um die Aktivierung der automatischen AKS Cluster-Skalierung beim Erstellen eines neuen AKS Clusters mit Azure CLI vorzunehmen, hängen Sie einfach --enable-cluster-autoscaler in Kombination mit --min-count und --max-count (die die äußeren Grenzen für die automatische Skalierung definieren) an das az-Kommando.

				
					AKS_NAME=aks-scaling-demo
RESOURCE_GROUP_NAME=aks-scaling-demo

# Eine Ressourcengruppe erstellen
az group create -n $RESOURCE_GROUP_NAME -l westeurope

# Einen AKS Cluster mit aktiviertem Autoscaler erstellen
az aks create -g $RESOURCE_GROUP_NAME \
   -n $AKS_NAME \
   --node-count 1 \
   --enable-cluster-autoscaler \
   --min-count 1 \
   --max-count 4
				
			

Azure wird nun eine neue AKS-Instanz bereitstellen und die automatische Skalierung des Clusters aktivieren. Das kann einige Minuten dauern, um alles aufzurufen und die automatische Skalierung des Clusters zu aktivieren. Dies könnte der richtige Zeitpunkt sein, um eine gute Tasse Kaffee zu genießen… ☕️.

Wenn Sie jedoch bereits über einen AKS Cluster verfügen, können Sie mittels dem az aks nodepool update-Kommando den Cluster Autoscaler aktivieren. Ich bin immer etwas vorsichtig, wenn ich den Autoscaler bei bereits vorhandenen AKS Clustern aktiviere. Dabei überprüfe ich die tatsächliche Anzahl der Worker Nodes, bevor ich ihn aktiviere, und verwende die Anzahl der derzeit zugewiesenen Worker Nodes als min-count, um die untere Grenze des Autoscalers festzulegen.

				
					AKS_NAME=aks-scaling-demo
RESOURCE_GROUP_NAME=aks-scaling-demo

# Aktuelle Knotenzahl ermitteln
kubectl get nodes --no-headers | wc -l
# 1

# Gewünschten Node-Pool-Namen ermitteln
az aks nodepool list -g $RESOURCE_GROUP_NAME --cluster-name $AKS_NAME \
  -o table --query [].name

# Node-Pool-Name in der temporären Variable (AKS_NODE_POOL_NAME) speichern

# Cluster Autoscaler bei bereits vorhandenem AKS Cluster aktivieren
az aks nodepool update -n $AKS_NODE_POOL_NAME --cluster-name $AKS_NAME \
  -g $RESOURCE_GROUP_NAME \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 3
				
			

Die Grenzen des Autoscalers ändern

Vielleicht waren Sie zunächst ebenfalls ein bisschen defensiv, als Sie die anfänglichen Auto-Scaler-Grenzen angegeben haben. Wenn Sie sehen, dass Ihre Anwendung wächst und immer beliebter wird, sollten Sie die äußeren Grenzen ändern. Um dies zu erreichen, verwenden Sie auch hier az aks update:

				
					# Ändern der AKS Cluster Autoscaler-Grenzen
az aks update -g $RESOURCE_GROUP_NAME \
  -n $AKS_NAME \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 10

				
			

Deaktivieren des Cluster Autoscalers

Natürlich können Sie auch den Cluster Autoscaler mittels az aks update deaktivieren:

				
					# Cluster Autoscaler deaktivieren
az aks update -g $RESOURCE_GROUP_NAME \
  -n $AKS_NAME \
  --disable-cluster-autoscaler
				
			

Nach der Deaktivierung verwenden Sie den bekannten Befehl az aks scale, um die Anzahl der Worker Nodes im Cluster manuell zu steuern:

				
					# AKS Cluster manuell skalieren
az aks scale -g $RESOURCE_GROUP_NAME \
  -n $AKS_NAME --node-count 4
				
			

Automatische Skalierung des AKS Clusters prüfen

Zur Überprüfung der automatischen Skalierung verwenden Sie das bereitgestellte Beispiel mit explizit definierten Ressourcenanforderungen und -grenzen. Nach dem initialen Deployment im Cluster wird das Deployment kontinuierlich skaliert, um die Gesamtauslastung der Ressourcen zu erhöhen. Sobald die Auslastung den Schwellenwert überschreitet und AKS das Hochfahren neuer Pods verhindert, beginnt Azure mit dem Hinzufügen neuer Nodes zum AKS Cluster.

Andererseits wird der AKS Cluster zurück skaliert, sobald sich die Anzahl der Deployment-Replikate wieder reduziert. (Mit etwas Verzögerung – mehr dazu später). Ich habe ein neues Cluster für dieses Beispiel mit der folgenden Konfiguration erstellt:

				
					# Die Ressourcengruppe erstellen
az group create -n aks-scaling-demo -l westeurope

# Einen AKS Cluster erstellen
az aks create -g aks-scaling-demo -n aks-scaling-demo \
  --node-count 1 \
  --node-vm-size Standard_B2s \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 4

# Anmeldeinformationen herunterladen und kubectl-Kontext wechseln
az aks get-credentials -n aks-scaling-demo -g aks-scaling-demo

# Aktuellen kubectl-Kontext überprüfen
kubectl config get-contexts

				
			

Bereitstellen der Beispielanwendung

Die Demo-Anwendung wurde auf Docker Hub veröffentlicht. Es handelt sich um eine in .NET Core geschriebene API, die nur zwei einfache Endpunkte offenlegt:

  • GET: status/health – Wird für Kubernetes Health Probe verwendet
  • GET: status/ready – Wird für Kubernetes Readiness Probe verwendet

Der Code für die API befindet sich in diesem Repository auf GitHub. Sie enthält auch die entsprechenden YAML-Definitionsdateien, die Sie für den Einsatz in Kubernetes verwenden können.

				
					# Dedizierten Namespace erstellen
kubectl create namespace scaling-demo

# Anwendung in AKS bereitstellen
kubectl apply -f https://raw.githubusercontent.com/ThorstenHans/aks-cluster-scaling-demo/master/kubernetes/scaling-demo.yaml -n scaling-demo
				
			

Bevor Sie mit der Skalierung des Deployments beginnen, müssen Sie überprüfen, aus wie vielen Worker Nodes der AKS Cluster derzeit besteht:

				
					# Anzahl der AKS Cluster Nodes überprüfen
kubectl get nodes --no-headers | wc -l
1
				
			

Zunächst erstellt das Deployment demo im Namespace scaling-demo 2 Replikate. Dies können Sie mittels kubectl get pods -n scaling-demo oder mittels kubectl get deploy -n scaling-demo überprüfen.

Lassen Sie uns die Bereitstellung auf 40 Replikationen skalieren, indem wir dies ausführen:

				
					# Die Demobereitstellung auf 40 Replikate skalieren
kubectl scale deploy/demo -n scaling-demo --replicas 40

# Die Erstellung der Pods überprüfen
kubectl get po -n scaling-demo -w
				
			

Starten Sie dann eine neue Terminal-Instanz, und beobachten Sie Ihre Cluster Worker Nodes:

				
					# AKS Worker Nodes beobachten
kubectl get nodes -w
NAME                                STATUS       ROLES     AGE.            VERSION
aks-nodepool1-11111111-vmss000000   Ready        agent     35m             v1.15.10
				
			

Nach einigen Sekunden oder Minuten werden neue Worker Nodes angezeigt. Um die Ressourcenauslastung pro Worker Node aufzurufen, verwenden Sie den Befehl kubectl top nodes:

				
					# AKS Worker Nodes aufrufen
kubectl get nodes
NAME                                STATUS   ROLES   AGE     VERSION
aks-nodepool1-11111111-vmss000000   Ready    agent   7h46m   v1.15.10
aks-nodepool1-11111111-vmss000001   Ready    agent   2m22s   v1.15.10

# Auslastung der AKS Worker Nodes aufrufen
kubectl top nodes
NAME                                CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
aks-nodepool1-11111111-vmss000000   257m         13%    1796Mi          83%
aks-nodepool1-11111111-vmss000001   98m          5%     883Mi           41%
				
			

Es ist nun möglich, die Kubernetes-Bereitstellung mittels kubectl scale deploy/demo -n scaling-demo --replicas 2 nochmals zu skalieren. Kubernetes wird sofort mit der Beendigung von Pods beginnen. Allerdings nimmt die Skalierung in den Worker Nodes einige Zeit in Anspruch. Aufgrund des standardmäßigen Cluster-Autoskalierungsprofils und seinen Einstellungen, die wir uns später anschauen werden, dauert dies einige Zeit.

Löschen der Beispielanwendung

Um die Beispielanwendung wieder zu entfernen, können Sie ganz einfach den gesamten Namespace mit dem Befehl kubectl delete namespace löschen.

				
					# Den gesamten Beispiel-Namespace löschen
kubectl delete ns aks-scaling-demo
				
			

Benutzerdefinierte Cluster-Skalierung

Das zuvor gezeigte Skalierungsverhalten basiert auf einer von Microsoft bereitgestellten Standardkonfiguration. Dieses Verhalten ist ausgezeichnet und eignet sich für gängige Szenarien. Aber vielleicht möchten Sie von Zeit zu Zeit mehr Kontrolle. In diesem Fall bevorzuge ich den Autoscaler, um aggressiver zurück zu skalieren. Vielleicht möchten Sie aber auch früher ausskalieren. Dies wird erreicht, indem Sie eine benutzerdefinierte AKS Cluster-Profileinstellung für den Autoscaler bereitstellen.

Microsoft stellt zahlreiche verschiedene Einstellungen bereit, die angepasst werden können, um das automatische Skalieren anzupassen. Um das Verhalten der Rückskalierung aggressiver zu gestalten, müssen Sie die Werte von zwei Einstellungen ändern.

Sowohl scale-down-unneeded-time als auch scale-down-after-add verfügen über einen Standardwert von 10 minutes, den Sie heruntersetzen müssen, damit der Cluster früher einskaliert. Sehen Sie sich gerne die offizielle Dokumentation an, um die vollständige Liste der verfügbaren Einstellungen aufzurufen. 

Benutzerdefinierte Autoscaler-Profile beeinflussen alle Node Pools in einem AKS Cluster

Zu diesem Zeitpunkt gibt es keine Möglichkeit, individuelle Auto-Scaler-Einstellungen pro Node Pool bereitzustellen. Um die Profileinstellungen für den Autoscaler benutzerdefiniert einzustellen, müssen Sie die AKS-Preview-Erweiterung für Azure CLI installieren.

				
					# Erweiterung installieren
az extension add -n aks-preview

# Erweiterung aktualisieren, um sicherzustellen, dass die neueste Version installiert ist
az extension update -n aks-preview
				
			

Benutzerdefinierte Scale-Profile bestimmen

Sobald Sie die AKS-Preview-Erweiterung installiert haben, können Sie az aks update anwenden, um das Autoscale-Profil zu ändern.

				
					# Profileinstellungen auf 3 Minuten festlegen
az aks update -g $RESOURCE_GROUP_NAME \
  -n $AKS_NAME \
  --cluster-autoscaler-profile scale-down-after-add=3m scale-down-unneeded-time=3m

				
			

Wenn diese Anpassungen auf dem Cluster angewendet werden sollen, können Sie obigen Demoprozess noch einmal durchlaufen und werden ein aggressiveres Rückskalierungsverhalten feststellen.

Cluster Autoscaler in Kombination mit mehreren AKS Node Pools

Wenn Ihr AKS Cluster mit verschiedenen Node Pools betrieben wird, können Sie den Cluster Autoscaler unabhängig für jeden Node Pool mit den Befehlen az aks nodepool konfigurieren.

Sie können zum Beispiel den Cluster Autoscaler für einen bestimmten Node Pool mit dem folgenden Befehl aktivieren:

				
					# Autoscaler für den Node Pool aktivieren
az aks nodepool update -g $RESOURCE_GROUP_NAME
  --cluster-name aks-scaling-demo \
  -n gpunodepool \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

				
			

Sie können die Grenzen aktualisieren oder den Cluster Autoscaler entsprechend deaktivieren:

				
					# Autoscaler-Grenzen im Node Pool aktualisieren
az aks nodepool update -g $RESOURCE_GROUP_NAME
  --cluster-name aks-scaling-demo \
  -n gpunodepool \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

# Cluster Autoscaler im Node Pool deaktivieren
az aks nodepool update -g $RESOURCE_GROUP_NAME
  --cluster-name aks-scaling-demo \
  -n gpunodepool \
  --disable-cluster-autoscaler
				
			

Zusammenfassung

Aus meiner Sicht ist der Cluster Autoscaler in AKS geschäftskritisch und eine der Funktionalitäten, die ich mir seit der Veröffentlichung von AKS gewünscht habe. Worker Nodes werden je nach tatsächlicher Arbeitslast aus- und zurück skaliert. Der Cluster Autoscaler funktioniert auch in Kombination mit Horizontal Pod Auto Scaling (HPA) ausgezeichnet.

Wenn Sie beides verwenden, können Sie Ihre Anwendungen effizient ausführen, unabhängig davon, ob Sie mit einer unerwartet hohen oder niedrigen Nutzung konfrontiert sind. Zusätzlich wirkt sich die Optimierung der Hardware-Auslastung direkt auf Ihre monatliche Azure-Rechnung aus.

Verwenden Sie Azure Kubernetes Service und haben Probleme beim Implementieren des richtigen Cluster-Verhaltens für den Autoscaler? Wenn ja, lassen Sie es mich gerne wissen.

Mehr Artikel zu Azure, AKS, Cloud Native
Kostenloser
Newsletter

Aktuelle Artikel, Screencasts, Webinare und Interviews unserer Experten für Sie

Verpassen Sie keine Inhalte zu Angular, .NET Core, Blazor, Azure und Kubernetes und melden Sie sich zu unserem kostenlosen monatlichen Dev-Newsletter an.

Newsletter Anmeldung
Diese Artikel könnten Sie interessieren
Cloud Native
favicon

Cloud Security: The 4C’s Of Cloud-Native Security – Part 5

In the last part of the article series on the 4C's of cloud-native security, we will look at securing the cloud environment itself. Although actual steps to harden your cloud infrastructure differ based on the cloud vendor and the services used to architecture your cloud-native application, many concepts and methodologies are quite similar.
14.04.2022
Cloud Native
favicon

Code Security: The 4C’s Of Cloud-Native Security – Part 4

In this part of the article series on the 4C's of cloud-native security, we will take a closer look at code security. We will briefly inspect why code security is essential, why it should be addressed from the beginning, and why trends such as shift-left security are important aspects of overall security considerations.
18.03.2022
Cloud Native
favicon

Cluster Security: The 4C’s Of Cloud-Native Security – Part 3

Securing the Kubernetes cluster (which may act as a runtime platform for several components of typical cloud-native applications) addresses one of the 4C's in cloud-native security. If you haven't heard about the 4C's of cloud-native security yet or want a quick refresher, you should read my corresponding introduction article.
04.03.2022
Cloud Native
favicon

Container Security: The 4C’s Of Cloud-Native Security – Part 2

Securing the container images of your cloud-native application building blocks addresses one of the 4C's in cloud-native security. If you haven't heard about the 4C's of cloud-native security yet or want a quick refresher, you should read my corresponding introduction post.
24.02.2022
Cloud Native
favicon

Code, Container, Cluster, Cloud: The 4C’s Of Cloud-Native Security – Part 1

Containers and cloud-native design patterns gained popularity over the past years. More and more organizations use containers in production and adopt cloud-native practices and methodologies to get even more value from existing containerized applications and underlying technologies such as container orchestrators like Kubernetes.
15.02.2022
Cloud Native
favicon

Ausführen von Containern in Azure Container Instances (ACI) direkt über die Docker CLI

Vor einigen Monaten haben sowohl Microsoft als auch Docker eine nahtlose Integration von Azure Container Instances (ACI) und Docker CLI angekündigt. Als Container-Enthusiast musste ich mich natürlich mit dieser Integration befassen. Ich habe es in verschiedenen Szenarien getestet, um zu sehen, wie es mich unterstützen und meine Produktivität steigern könnte.
05.11.2021