Das Cluster Autoscaler Helm Chart ist eine Möglichkeit, den Kubernetes Cluster Autoscaler zu installieren. Dieser fügt Worker Nodes hinzu, wenn Ihre Pods nicht eingeplant werden können, und entfernt Nodes, sobald sie nicht mehr benötigt werden. Die Installation gelingt mit einem einzigen helm install-Befehl – ob der Autoscaler aber gut funktioniert, hängt vor allem von zwei Dingen ab: den von Ihnen konfigurierten Einstellungen und den Resource Requests Ihrer Pods.
Dieser Leitfaden behandelt beides und erklärt außerdem, wie der Cluster Autoscaler seine Skalierungsentscheidungen trifft. Sie erfahren, wie der Cluster Autoscaler entscheidet, wann Nodes hinzugefügt oder entfernt werden, welches Chart Sie installieren sollten, wie Sie es auf EKS, AKS und GKE installieren und überprüfen, welche Helm Values sein Verhalten steuern, wie Sie es für große Cluster optimieren und wie Sie typische Skalierungsprobleme beheben.
Was ist das Cluster Autoscaler Helm Chart?
Der Cluster Autoscaler passt die Anzahl der Nodes in Ihrem Cluster daran an, was Ihre Pods benötigen. Er fügt Nodes hinzu, wenn Pods mangels Kapazität nicht eingeplant werden können, und entfernt nicht mehr benötigte Nodes, sobald deren Pods auf anderen Nodes laufen können.
Dazu verändert er die Größe der Node-Gruppen Ihres Cloud-Anbieters, etwa AWS Auto Scaling Groups (ASGs), Azure Virtual Machine Scale Sets (VMSS) oder Google Compute Engine Managed Instance Groups (MIGs).
Das Helm Chart bündelt das Cluster-Autoscaler-Deployment, seine RBAC-Berechtigungen und die Konfiguration in einer Installation. Das erleichtert Installation, Verwaltung und Upgrades. Der Cluster Autoscaler skaliert Nodes, während der HPA und KEDA Pods skalieren.
Wie entscheidet der Cluster Autoscaler, wann Nodes hinzugefügt oder entfernt werden?
Die folgenden Faktoren sind für den Cluster Autoscaler bei der Entscheidung über das Hinzufügen oder Entfernen von Nodes maßgeblich:
Pending Pods lösen das Scale-up aus
Alle 10 Sekunden – gesteuert über die Einstellung --scan-interval – sucht der Autoscaler nach Pods, die im Status Pending feststecken, weil sie auf den vorhandenen Nodes keinen Platz finden. Er prüft, ob ein neuer Node aus den einzelnen Node-Gruppen diese Pods aufnehmen könnte, wählt eine passende Gruppe aus und erhöht deren gewünschte Größe, damit der Cloud-Anbieter einen Node hinzufügen kann. Gibt es keine nicht einplanbaren Pods, fügt der Cluster Autoscaler keine Nodes hinzu.
Geringe Auslastung plus Wartezeit lösen das Scale-down aus
Wenn keine Nodes hinzugefügt werden müssen, prüft der Autoscaler, ob Nodes entfernt werden können. Ein Node wird zum Kandidaten, wenn die CPU- und Speicher-Requests seiner Pods unter dem --scale-down-utilization-threshold liegen, der standardmäßig 0.5 (50 %) beträgt. Der Node muss für die mit --scale-down-unneeded-time festgelegte Zeit (Standard: 10 Minuten) unterausgelastet bleiben. Außerdem wartet der Autoscaler nach einem Scale-up, bevor er Nodes entfernt – gesteuert über --scale-down-delay-after-add, ebenfalls standardmäßig 10 Minuten. Deshalb läuft das Scale-down in der Regel langsamer ab als das Scale-up.
Node-Gruppen und Expander bestimmen, woher neue Nodes kommen
Der Autoscaler muss wissen, welche Node-Gruppen er verwalten soll. Er kann sie automatisch erkennen oder eine explizite Liste verwenden. Können mehrere Node-Gruppen die wartenden Pods aufnehmen, entscheidet die Einstellung --expander, welche Gruppe vergrößert wird. Zur Auswahl stehen random, most-pods, least-waste, price und priority.
Resource Requests steuern die Skalierungsentscheidungen
Das ist einer der wichtigsten Punkte überhaupt. Der Cluster Autoscaler verwendet die Resource Requests der Pods, nicht die tatsächliche CPU- und Speichernutzung. Er fügt Nodes hinzu, wenn die angeforderten Ressourcen nicht mehr passen, und bewertet die Auslastung eines Nodes anhand der Requests seiner Pods. Fordern Pods beispielsweise 80 % der Kapazität eines Nodes an, nutzen aber nur 20 %, sieht der Autoscaler den Node weiterhin als zu 80 % ausgelastet an und entfernt ihn unter Umständen nicht. Überdimensionierte Requests können daher überflüssige Nodes am Laufen halten und Ihre Cloud-Kosten in die Höhe treiben.
Welches Cluster Autoscaler Chart sollten Sie installieren?
Verwenden Sie für neue Installationen das offizielle autoscaler/cluster-autoscaler Chart aus dem kubernetes/autoscaler-Repository.
Möglicherweise stoßen Sie noch auf die alten Charts stable/aws-cluster-autoscaler und stable/cluster-autoscaler. Diese sind veraltet und werden nicht mehr gepflegt – verzichten Sie daher darauf.
Helm ist nicht die einzige Option. Verwaltete Kubernetes-Dienste stellen den Cluster Autoscaler teilweise über eigene Tools bereit, und manche Teams verwalten ihn mit Terraform. Die richtige Wahl hängt davon ab, wie Sie Ihr Cluster betreiben.
Voraussetzungen und Versionskompatibilität
Prüfen Sie vor der Installation die folgenden zwei Punkte:
Cluster-Autoscaler-Version an die Kubernetes-Version anpassen
Verwenden Sie Cluster Autoscaler v1.30.x mit Kubernetes 1.30, v1.31.x mit Kubernetes 1.31 und so weiter. Der Autoscaler nutzt eine eigene Scheduling-Logik, um zu prüfen, ob ein Pod auf einen neuen Node passt. Eine nicht passende Version kann daher zu fehlerhaften Skalierungsentscheidungen führen. Prüfen Sie den Standard-Image-Tag des Charts und pinnen Sie ihn bei Bedarf auf die korrekte Version.
Dem Cluster Autoscaler Zugriff auf Ihren Cloud-Anbieter geben
Der Autoscaler benötigt die Berechtigung, die Größe Ihrer Node-Gruppen zu ändern, und muss wissen, welche Node-Gruppen er verwaltet. Auf AWS bedeutet das: die erforderlichen IAM-Berechtigungen und korrekt getaggte Auto Scaling Groups (ASGs). Auf Azure und GCE brauchen Sie die entsprechenden Berechtigungen sowie korrekt konfigurierte VM Scale Sets (VMSS) bzw. Managed Instance Groups (MIGs).
Stellen Sie sicher, dass diese Berechtigungen und Node-Gruppen-Einstellungen stimmen, bevor Sie installieren. Das Chart kann auch bei fehlerhafter Konfiguration erfolgreich starten, der Cluster Autoscaler kann die Nodes dann aber nicht skalieren.
Installation des Charts in einem laufenden Cluster
Fügen Sie zunächst das offizielle Repository hinzu:
helm repo add autoscaler https://kubernetes.github.io/autoscalerhelm repo updateVor der Installation müssen Sie dem Cluster Autoscaler mitteilen, welche Node-Gruppen er verwalten soll. Das Setup hängt von Ihrem Cloud-Anbieter ab.
Bei verwalteten AKS- und GKE-Clustern ist das Node-Autoscaling bereits als integrierte Funktion verfügbar, die Sie auf Node-Pool-Ebene aktivieren – dort brauchen Sie dieses Helm Chart in der Regel nicht. Das Chart ist vor allem für Amazon EKS und selbstverwaltete Cluster nützlich.
Installation auf EKS
Auf EKS ist Auto-Discovery der einfachste Weg. Taggen Sie zunächst jede Auto Scaling Group (ASG), die der Cluster Autoscaler verwalten soll, mit k8s.io/cluster-autoscaler/enabled und k8s.io/cluster-autoscaler/<your-cluster-name>.
Installieren Sie anschließend das Chart:
helm install cluster-autoscaler autoscaler/cluster-autoscaler \ --namespace kube-system \ --set cloudProvider=aws \ --set autoDiscovery.clusterName=<your-cluster-name> \ --set awsRegion=<your-region>Installation auf selbstverwaltetem Azure oder GCE
Setzen Sie für ein selbstverwaltetes Azure- oder GCE-Cluster cloudProvider=azure bzw. cloudProvider=gce und geben Sie die Details der Scale Sets oder Instance Groups an, die der Cluster Autoscaler verwalten soll.
Die konkreten Einstellungen unterscheiden sich je nach Cloud-Anbieter, das Grundprinzip ist aber dasselbe: Geben Sie Cloud-Anbieter, Node-Gruppen sowie die Anmeldedaten oder Identität an, die der Cluster Autoscaler verwenden soll.
Prüfen Sie nach der Installation, ob der Cluster-Autoscaler-Pod läuft:
kubectl get pods -n kube-system -l app.kubernetes.io/instance=cluster-autoscalerPrüfen Sie anschließend seinen Status:
kubectl describe configmap cluster-autoscaler-status -n kube-systemDie Status-ConfigMap zeigt die Größe jeder Node-Gruppe sowie die jüngsten Scale-up- und Scale-down-Aktivitäten. So sehen Sie auf einen Blick, ob der Cluster Autoscaler läuft und Skalierungsentscheidungen trifft.
Helm Values, die das Verhalten des Autoscalers verändern
Die wichtigsten Values im Überblick:
cloudProvider und autoDiscovery
Diese Werte teilen dem Cluster Autoscaler mit, welchen Cloud-Anbieter Sie verwenden und wie er die zu verwaltenden Node-Gruppen findet. Sind sie falsch, hat der Autoscaler keine Node-Gruppen zum Skalieren.
Service-Account-Annotationen für den Cloud-Zugriff
Sie können dem Cluster Autoscaler über seinen Service Account eigene Cloud-Berechtigungen geben, statt allen Nodes weitreichende Rechte einzuräumen. Auf EKS geschieht das üblicherweise mit IAM Roles for Service Accounts (IRSA). Auf Azure und GCE lässt sich Workload Identity verwenden. Die Service-Account-Annotationen werden über rbac.serviceAccount.annotations konfiguriert.
extraArgs für das Skalierungsverhalten
Über extraArgs setzen Sie Cluster-Autoscaler-Optionen wie scan-interval, scale-down-utilization-threshold, scale-down-unneeded-time und expander. Mit expendable-pods-priority-cutoff legen Sie zudem die Priorität fest, unterhalb derer Pods als entbehrlich behandelt werden können. Diese Einstellungen steuern, wie oft der Autoscaler das Cluster prüft und wie er Nodes zum Hinzufügen oder Entfernen auswählt.
Replica-Anzahl, Leader Election und Ressourcen
Für Hochverfügbarkeit können Sie mehr als ein Replica betreiben. Der Cluster Autoscaler nutzt Leader Election, sodass immer nur ein Replica aktiv ist, während die anderen bereitstehen, um zu übernehmen. Setzen Sie außerdem CPU- und Speicher-Requests und -Limits für den Autoscaler. Große Cluster brauchen unter Umständen mehr Speicher, da der Autoscaler den Zustand des Clusters im Speicher hält.
Diese Werte können Sie in einer values.yaml-Datei definieren und das Chart mit -f installieren:
cloudProvider: awsautoDiscovery: clusterName: my-clusterawsRegion: us-east-1replicaCount: 2extraArgs: scan-interval: 10s scale-down-utilization-threshold: "0.5" expander: least-waste balance-similar-node-groups: "true"resources: requests: cpu: 100m memory: 300Mi limits: cpu: 200m memory: 500MiTuning des Charts für große oder Multi-Tenant-Cluster
Große Cluster erfordern zusätzliches Tuning, weil der Cluster Autoscaler bei jedem Scan mehr Pods, Nodes und Node-Gruppen prüfen muss. Einige Einstellungen und Muster helfen dabei, ihn auch bei wachsendem Cluster stabil und performant zu halten:
Anzahl der Node-Gruppen reduzieren
Je mehr Node-Gruppen der Autoscaler verwaltet, desto mehr Arbeit fällt bei jedem Scan an. Halten Sie die Zahl der Node-Gruppen nach Möglichkeit klein und nutzen Sie Auto-Discovery-Tags, um nur die Gruppen einzubeziehen, die Autoscaling benötigen.
Sharding für sehr große Cluster nutzen
Sie können mehrere Cluster-Autoscaler-Instanzen betreiben, von denen jede einen anderen Satz Node-Gruppen verwaltet. So verteilt sich die Arbeit auf mehrere Autoscaler-Instanzen. Der Nachteil: Diese Instanzen stimmen sich nicht untereinander ab, sodass zwei von ihnen auf denselben Pending Pod reagieren und vorübergehend mehr Nodes hinzufügen können als nötig. Diese überzähligen Nodes können später beim Scale-down wieder entfernt werden.
Spot-Nodes mit dem Priority Expander kombinieren
Für kostenorientierte Cluster können Sie Spot-Node-Gruppen mit dem Priority Expander kombinieren. So bevorzugt der Autoscaler günstigere Spot-Kapazität und weicht bei Bedarf auf On-Demand-Nodes aus.
Overprovisioning für schnelleres Skalieren nutzen
Beim Overprovisioning reservieren Platzhalter-Pods mit niedriger Priorität zusätzliche Kapazität im Cluster. Treffen echte Workloads ein, werden diese Platzhalter-Pods entfernt, um Platz zu schaffen, während der Autoscaler neue Nodes hinzufügt.
Node-Gruppen von null skalieren
Eine Node-Gruppe kann auf null herunterskalieren, wenn sie nicht genutzt wird. Das ist besonders bei teuren GPU-Node-Gruppen nützlich. Stellen Sie auf EKS sicher, dass die Node-Gruppe die erforderlichen Labels und Taints in ihren Autoscaler-Tags enthält, damit der Cluster Autoscaler auch bei null Nodes weiß, was die Nodes bereitstellen können.
Diagnose einer Installation, die nicht skaliert
Wenn der Cluster Autoscaler nicht wie erwartet skaliert, sind die Status-ConfigMap und die Pod-Logs die besten Ausgangspunkte. Die häufigsten Fälle:
Pods bleiben Pending, aber keine Nodes werden hinzugefügt
Beginnen Sie mit kubectl describe pod <pod-name> und prüfen Sie die Pod-Events. Sehen Sie sich anschließend die Logs des Cluster Autoscalers an. Häufige Ursachen: Die Node-Gruppe hat bereits ihre maximale Größe erreicht, keine Node-Gruppe bietet genug Kapazität für die Resource Requests des Pods, oder der Node Selector bzw. die Affinity des Pods passt zu keiner verfügbaren Node-Gruppe. Auch fehlende Cloud-Berechtigungen oder Node-Gruppen-Tags können verhindern, dass der Autoscaler die Node-Gruppe findet oder verändert.
Nodes bleiben unterausgelastet und werden nicht entfernt
Der Cluster Autoscaler überspringt manche Nodes standardmäßig. Beispielsweise überspringt er Nodes mit kube-system-Pods, wenn --skip-nodes-with-system-pods aktiviert ist, sowie Nodes mit Pods, die lokalen Speicher nutzen, wenn --skip-nodes-with-local-storage aktiviert ist. Außerdem wartet er die Scale-down-Verzögerung ab. Noch wichtiger: Denken Sie daran, dass der Cluster Autoscaler Resource Requests verwendet, nicht die tatsächliche Nutzung. Halten die Requests einen Node über dem Auslastungsschwellenwert, kommt er nicht als Kandidat für die Entfernung infrage – selbst wenn die tatsächliche CPU- und Speichernutzung niedrig ist.
Annotationen und PodDisruptionBudgets blockieren das Entfernen von Nodes
Der Cluster Autoscaler entfernt keinen Node, wenn dadurch ein PodDisruptionBudget (PDB) verletzt würde. Er überspringt außerdem Pods mit cluster-autoscaler.kubernetes.io/safe-to-evict: "false" sowie Nodes mit der scale-down-disabled-Annotation. Diese Einstellungen schützen Workloads vor ungewollter Verdrängung – eine veraltete oder überflüssige Einstellung kann einen Node aber länger als erwartet am Laufen halten. Prüfen Sie mit kubectl describe configmap cluster-autoscaler-status -n kube-system, welche Nodes nicht entfernt werden können und warum.
Tools, die den Cluster Autoscaler ergänzen
Der Cluster Autoscaler verwaltet die Anzahl der Nodes – die folgenden Tools unterstützen Sie beim Dimensionieren von Pods und beim Bereitstellen von Nodes.
PerfectScale
Der Cluster Autoscaler trifft Skalierungsentscheidungen auf Basis der Resource Requests der Pods, nicht der tatsächlichen CPU- und Speichernutzung. Sind die Requests zu hoch, kann er Nodes hinzufügen, die Sie nicht brauchen, und Nodes behalten, die sonst entfernt werden könnten. PerfectScale überwacht die tatsächliche Nutzung Ihrer Workloads und liefert automatisierte Right-Sizing-Empfehlungen, um CPU- und Speicher-Requests näher an den realen Bedarf zu bringen. So kann der Cluster Autoscaler bessere Skalierungsentscheidungen treffen. Probieren Sie es aus oder buchen Sie eine technische Session.
Vertical Pod Autoscaler (VPA) und Goldilocks
Der VPA passt die Resource Requests von Pods auf Basis der beobachteten Nutzung an. Goldilocks stellt ein Dashboard für VPA-Empfehlungen bereit. Beide helfen dabei, Resource Requests näher an der tatsächlichen Nutzung zu halten – das liefert dem Cluster Autoscaler bessere Informationen für seine Skalierungsentscheidungen.
Karpenter
Karpenter verfolgt einen anderen Ansatz beim Skalieren von Nodes. Statt feste Node-Gruppen zu vergrößern oder zu verkleinern, kann es Nodes passgenau auf Basis der Anforderungen wartender Pods bereitstellen.
Best Practices für den Cluster Autoscaler in Produktion
Die folgenden Praktiken helfen, das Node-Autoscaling effizient und sicher zu halten:
1. Pod-Requests richtig dimensionieren, bevor Sie Autoscaler-Einstellungen anpassen
Der Cluster Autoscaler entscheidet auf Basis der Resource Requests der Pods – korrekte Requests sind daher wichtiger als Änderungen an den Autoscaler-Einstellungen. Bringen Sie zuerst die Resource Requests in Ordnung und passen Sie erst dann Timer und Expander an.
2. Node-Gruppen bei CPU, Speicher und Availability Zone ähnlich halten
Nodes innerhalb derselben Node-Gruppe sollten ähnlich sein. Unterschiedliche Instanztypen oder Availability Zones können die Scheduling-Simulation des Autoscalers ungenauer machen. Ähnliche Node-Gruppen lassen sich mit balance-similar-node-groups ausbalancieren.
3. PodDisruptionBudgets für Workloads setzen, die nicht unterbrochen werden dürfen
Ein PodDisruptionBudget (PDB) legt fest, wie viele Pods gleichzeitig nicht verfügbar sein dürfen. So kann der Cluster Autoscaler Nodes entfernen und gleichzeitig genügend Replicas für den Workload verfügbar halten.
4. Chart-Version pinnen und Upgrades testen
Die Cluster-Autoscaler-Version sollte zu Ihrer Kubernetes-Version passen. Ein Kubernetes-Upgrade sollte daher mit der passenden Autoscaler-Version getestet werden, bevor die Änderung in Produktion geht.
5. Autoscaler-Metriken nach Prometheus exportieren und Alerts für fehlgeschlagene Scale-ups einrichten
Der Cluster Autoscaler stellt Prometheus-Metriken bereit, die Skalierungsaktivitäten und Fehler zeigen. Alerts für fehlgeschlagene Scale-ups und dauerhaft im Status Pending verbleibende Pods helfen, Probleme zu erkennen, bevor sie Workloads über längere Zeit beeinträchtigen.
6. Scale-down-Schwellenwerte an den tatsächlichen Einsparungen messen
Aggressives Scale-down kann Kosten senken, aber Workloads mit plötzlichen Lastspitzen skalieren dann unter Umständen zu häufig hoch und wieder herunter. Passen Sie den scale-down-utilization-threshold und die Scale-down-Timer an Ihre realen Traffic-Muster an, statt sie nur auf eine möglichst geringe Node-Anzahl zu optimieren.