- Authors

- Name
- Phillip Pham
- @ddppham
Kubernetes Cluster Autoscaler: Automatische Node-Skalierung einrichten
TL;DR
- Der Kubernetes Cluster Autoscaler skaliert Nodes automatisch hoch, wenn Pods im Pending-Status haengen, und runter, wenn Nodes unterausgelastet sind.
- Installation erfolgt per Helm Chart -- fuer AWS, GCP und Azure gibt es jeweils spezifische Cloud-Provider-Konfigurationen.
- Karpenter ist die modernere Alternative zum klassischen Cluster Autoscaler: schneller, flexibler und mit besserer Bin-Packing-Logik.
- Spot- und Preemptible-Instances koennen die Node-Kosten um 60-80% senken, erfordern aber robuste Eviction-Strategien.
- Monitoring der Autoscaler-Entscheidungen via Prometheus ist Pflicht, um unerwartetes Verhalten fruehzeitig zu erkennen.
Warum Node-Autoscaling unverzichtbar ist
Kubernetes skaliert Pods automatisch per HPA -- aber was passiert, wenn der Cluster keine Kapazitaet mehr hat? Neue Pods landen im Status Pending, weil kein Node genuegend CPU oder Memory bereitstellen kann. Ohne Node-Autoscaling bleiben diese Pods haengen, bis jemand manuell Nodes hinzufuegt.
Das ist das Problem, das der Kubernetes Cluster Autoscaler loest. Er ueberwacht den Scheduler und reagiert auf zwei Situationen:
- Scale Up: Pods sind
Pendingweil kein passender Node existiert. Der Autoscaler fuegt neue Nodes hinzu. - Scale Down: Nodes sind unterausgelastet (unter dem konfigurierten Schwellenwert). Der Autoscaler entfernt sie nach einer Wartezeit.
Fuer eine umfassende Einfuehrung in alle Autoscaling-Mechanismen lesen Sie unseren Autoscaling-Guide mit HPA, VPA und Cluster Autoscaler.
Installation per Helm Chart (AWS EKS)
Der Cluster Autoscaler benoetigt Zugriff auf die Cloud-Provider-API. Fuer AWS mit IRSA:
# Helm Repository hinzufuegen
helm repo add autoscaler https://kubernetes.github.io/autoscaler
helm repo update
# Cluster Autoscaler installieren (AWS)
helm install cluster-autoscaler autoscaler/cluster-autoscaler \
--namespace kube-system \
--set autoDiscovery.clusterName=mein-cluster \
--set awsRegion=eu-central-1 \
--set rbac.serviceAccount.create=false \
--set rbac.serviceAccount.name=cluster-autoscaler \
--set extraArgs.balance-similar-node-groups=true \
--set extraArgs.skip-nodes-with-system-pods=false \
--set extraArgs.expander=least-waste
Fuer GKE ist der Autoscaler nativ integriert:
gcloud container node-pools create standard-pool \
--cluster=mein-cluster \
--zone=europe-west3-a \
--enable-autoscaling \
--min-nodes=2 \
--max-nodes=20 \
--machine-type=e2-standard-4
# Aggressiveres Scale-Down aktivieren
gcloud container clusters update mein-cluster \
--zone=europe-west3-a \
--autoscaling-profile=optimize-utilization
Fuer Azure AKS:
az aks nodepool add \
--resource-group meine-rg \
--cluster-name mein-cluster \
--name standardpool \
--node-count 3 \
--min-count 2 \
--max-count 20 \
--enable-cluster-autoscaler \
--node-vm-size Standard_D4s_v3
Konfigurationsparameter im Detail
Die wichtigsten Parameter als Helm-Values-Datei:
# values-cluster-autoscaler.yaml
replicaCount: 2
extraArgs:
scale-down-delay-after-add: "10m"
scale-down-unneeded-time: "10m"
scale-down-utilization-threshold: "0.5"
max-node-provision-time: "15m"
max-nodes-total: "100"
expander: "least-waste"
balance-similar-node-groups: "true"
skip-nodes-with-local-storage: "false"
scan-interval: "10s"
resources:
requests:
cpu: 100m
memory: 300Mi
limits:
cpu: 500m
memory: 600Mi
Expander-Strategien
Der Expander bestimmt, welche Node Group gewaehlt wird, wenn mehrere in Frage kommen:
| Expander | Verhalten | Wann sinnvoll |
|---|---|---|
random | Zufaellige Auswahl | Einfache Setups |
most-pods | Maximale Pod-Kapazitaet | Batch-Workloads |
least-waste | Wenigste ungenutzte Ressourcen | Kostenoptimierung (empfohlen) |
priority | Feste Prioritaetsliste | Spot-First mit On-Demand-Fallback |
Priority-Expander Konfiguration:
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-autoscaler-priority-expander
namespace: kube-system
data:
priorities: |
50:
- .*spot.*
30:
- .*standard.*
10:
- .*ondemand.*
Karpenter vs. Cluster Autoscaler
Karpenter ist ein von AWS entwickelter Node-Autoscaler, der mittlerweile als CNCF-Projekt auch auf anderen Clouds laeuft. Der Unterschied ist fundamental.
| Kriterium | Cluster Autoscaler | Karpenter |
|---|---|---|
| Node-Auswahl | Vordefinierte Node Groups | Dynamisch pro Pod |
| Geschwindigkeit | 30-60 Sekunden | Unter 10 Sekunden |
| Bin Packing | Einfache Logik | Fortgeschritten mit Consolidation |
| Spot-Handling | Separate Node Groups | Native Integration mit Fallback |
| Scale from Zero | Erfordert spezielle Tags | Nativ unterstuetzt |
| Cloud-Support | AWS, GCP, Azure | AWS (GA), Azure (Beta) |
Karpenter NodePool konfigurieren
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: general-purpose
spec:
template:
spec:
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ["spot", "on-demand"]
- key: karpenter.k8s.aws/instance-category
operator: In
values: ["m", "c", "r"]
- key: karpenter.k8s.aws/instance-generation
operator: Gt
values: ["5"]
- key: karpenter.k8s.aws/instance-size
operator: In
values: ["large", "xlarge", "2xlarge"]
limits:
cpu: "200"
memory: 800Gi
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 60s
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
name: default
spec:
role: KarpenterNodeRole-mein-cluster
amiSelectorTerms:
- alias: al2023@latest
subnetSelectorTerms:
- tags:
karpenter.sh/discovery: mein-cluster
securityGroupSelectorTerms:
- tags:
karpenter.sh/discovery: mein-cluster
blockDeviceMappings:
- deviceName: /dev/xvda
ebs:
volumeSize: 100Gi
volumeType: gp3
encrypted: true
Wenn Sie mehr ueber Kostenoptimierung erfahren moechten, lesen Sie unseren Praxis-Guide zur Kubernetes-Kostenoptimierung.
Spot-Instances und Pod Disruption Budgets
Spot-Instances senken Node-Kosten um 60-80%, koennen aber jederzeit entzogen werden:
apiVersion: apps/v1
kind: Deployment
metadata:
name: batch-processor
spec:
replicas: 5
template:
spec:
nodeSelector:
capacity-type: spot
tolerations:
- key: "spot"
operator: "Equal"
value: "true"
effect: "NoSchedule"
terminationGracePeriodSeconds: 120
containers:
- name: processor
image: myregistry/batch-processor:v2.1
resources:
requests:
cpu: "500m"
memory: "512Mi"
Pod Disruption Budgets schuetzen Ihre Anwendungen beim Scale-Down:
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: web-api-pdb
namespace: production
spec:
minAvailable: 2
selector:
matchLabels:
app: web-api
Mehr zu PDBs in unserem Artikel zu Pod Disruption Budgets.
Monitoring der Autoscaler-Entscheidungen
Der Cluster Autoscaler exponiert Prometheus-Metriken. Richten Sie Alerts fuer die wichtigsten Szenarien ein:
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: cluster-autoscaler-alerts
namespace: monitoring
spec:
groups:
- name: cluster-autoscaler
rules:
- alert: ClusterAutoscalerUnschedulablePods
expr: cluster_autoscaler_unschedulable_pods_count > 0
for: 10m
labels:
severity: warning
annotations:
summary: "Pods koennen seit 10 Minuten nicht geschedult werden"
- alert: ClusterAutoscalerScaleUpFailed
expr: increase(cluster_autoscaler_errors_total{errorType="scaleUpError"}[5m]) > 0
for: 5m
labels:
severity: critical
annotations:
summary: "Scale-Up fehlgeschlagen -- Cloud-API-Limits pruefen"
Fuer ein vollstaendiges Monitoring-Setup empfehlen wir unseren Guide zu Kubernetes Monitoring und Observability.
Troubleshooting
Pods bleiben Pending trotz Autoscaler
# Autoscaler-Logs pruefen
kubectl logs -n kube-system -l app.kubernetes.io/name=cluster-autoscaler --tail=100
# Haeufige Ursachen: Max Nodes erreicht oder keine passende Node Group
kubectl describe pod mein-pending-pod | grep -A 5 "Events"
Nodes werden nicht herunterskaliert
# Welche Pods blockieren das Scale-Down?
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=mein-node
# Pod als safe-to-evict markieren
kubectl annotate pod mein-pod cluster-autoscaler.kubernetes.io/safe-to-evict="true"
Best Practices
| Praxis | Empfehlung |
|---|---|
| Resource Requests | Immer korrekt setzen -- Autoscaler braucht sie |
| Node Groups | Mehrere mit verschiedenen Instanzgroessen |
| Expander | least-waste fuer Kostenoptimierung |
| PDBs | Fuer alle produktiven Workloads definieren |
| Monitoring | Prometheus-Metriken und Alerts einrichten |
| Spot Instances | Fuer nicht-kritische Workloads mit Termination Handler |
| Karpenter | Bevorzugen, wenn AWS genutzt wird |
Verwandte Artikel
- Kubernetes Autoscaling: HPA, VPA und Cluster Autoscaler kombinieren
- Kubernetes Kostenoptimierung: Praxis-Guide
- Kubernetes Capacity Planning: Richtig dimensionieren
- Kubernetes Resource Management: Requests und Limits
- Kubernetes Pod Disruption Budgets korrekt einsetzen
Sie moechten Ihr Cluster-Autoscaling optimieren oder auf Karpenter migrieren? Wir helfen Ihnen bei der Konfiguration, dem Monitoring und der Kostenoptimierung -- Kontakt aufnehmen.
Kubernetes-Beratung gesucht?
Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.
📖 Verwandte Artikel
Weitere interessante Beiträge zu ähnlichen Themen
Cluster Autoscaler: Kubernetes-Nodes optimal skalieren
Cluster Autoscaler optimieren mit Expander-Strategien, Scale-Down-Tuning und Priority-Konfiguration für kosteneffiziente Node-Skalierung.
Karpenter Autoscaling: 60% schnellere Nodes auf AWS
Karpenter statt Cluster Autoscaler: 60% schnellere Node-Provisionierung, dynamische Instance-Auswahl, Spot-Integration und Consolidation auf AWS EKS.
Capacity Planning: Kubernetes-Autoscaling richtig nutzen
HPA, VPA, Cluster Autoscaler und KEDA kombinieren für Capacity Planning in Kubernetes. Mit Praxisbeispielen und Entscheidungshilfe.
Kubernetes Cluster Autoscaler: Setup und Tuning-Guide
Cluster Autoscaler auf Kubernetes einrichten und tunen: Node-Gruppen-Strategie, Expander-Wahl, Scale-Down-Konfiguration und Spot-Instance-Integration.
Kubernetes Autoscaling: HPA, VPA und Cluster Autoscaler Guide
HPA, VPA und Cluster Autoscaler richtig kombinieren. Wann welchen Autoscaler nutzen, Konfiguration mit YAML-Beispielen und typische Fallstricke vermeiden.