Veröffentlicht am

Cluster Autoscaler einrichten: Nodes automatisch skalieren

Teilen:
Authors

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 Pending weil 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:

ExpanderVerhaltenWann sinnvoll
randomZufaellige AuswahlEinfache Setups
most-podsMaximale Pod-KapazitaetBatch-Workloads
least-wasteWenigste ungenutzte RessourcenKostenoptimierung (empfohlen)
priorityFeste PrioritaetslisteSpot-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.

KriteriumCluster AutoscalerKarpenter
Node-AuswahlVordefinierte Node GroupsDynamisch pro Pod
Geschwindigkeit30-60 SekundenUnter 10 Sekunden
Bin PackingEinfache LogikFortgeschritten mit Consolidation
Spot-HandlingSeparate Node GroupsNative Integration mit Fallback
Scale from ZeroErfordert spezielle TagsNativ unterstuetzt
Cloud-SupportAWS, GCP, AzureAWS (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

PraxisEmpfehlung
Resource RequestsImmer korrekt setzen -- Autoscaler braucht sie
Node GroupsMehrere mit verschiedenen Instanzgroessen
Expanderleast-waste fuer Kostenoptimierung
PDBsFuer alle produktiven Workloads definieren
MonitoringPrometheus-Metriken und Alerts einrichten
Spot InstancesFuer nicht-kritische Workloads mit Termination Handler
KarpenterBevorzugen, wenn AWS genutzt wird

Verwandte Artikel


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