Workloads skalieren und autoskalieren

Sobald deine App läuft (siehe Deine erste App deployen), lautet die nächste Frage: Kapazität. Wie fängst du mehr Traffic ab, ohne zu überprovisionieren? Kubernetes skaliert Workloads auf zwei Arten – manuell und automatisch.

Von Hand skalieren

Der einfachste Hebel ist die Zahl der Replicas:

kubectl -n demo scale deployment/web --replicas=4
kubectl -n demo get pods

Kubernetes startet neue Pods, und der Service verteilt die Last sofort über alle. Zum Runterskalieren nimmst du denselben Befehl mit einer kleineren Zahl.

Replicas über Nodes verteilen

Mehr Replicas helfen der Verfügbarkeit nur, wenn sie nicht alle auf demselben Node landen. Topology Spread Constraints halten sie im Gleichgewicht:

spec:
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels: { app: web }

Fällt jetzt ein einzelner Node weg, trifft es höchstens einen Teil deiner Pods, und das Deployment plant sie anderswo neu ein.

Autoscaling mit einem HPA

Ein HorizontalPodAutoscaler passt die Zahl der Replicas anhand der gemessenen Last für dich an. Dieser hier zielt auf durchschnittlich 60 % CPU, zwischen 2 und 10 Replicas:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
  namespace: demo
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

kubectl apply -f hpa.yaml
kubectl -n demo get hpa web -w

Der HPA braucht den metrics-server, um CPU und Speicher der Pods auszulesen – auf PaaSbox-Clustern ist er bereits enthalten, der Autoscaler funktioniert also out of the box. Die HPA-Skalierung stützt sich auf die Resource-Requests, die du am Container gesetzt hast – ein Grund mehr, sie immer zu deklarieren.

Pods skalieren in Sekunden, Nodes in Minuten. Wenn der HPA mehr Pods will, als auf deine Nodes passen, holt sich der Cluster Kapazität aus deinem Node-Pool – zuerst aus dem Pool, du bekommst also die Dichte (und die Einsparungen), bevor du für neue Server zahlst.

Last erzeugen und zusehen

kubectl -n demo run load --rm -it --image=busybox --restart=Never -- \
  /bin/sh -c "while true; do wget -q -O- http://web.demo; done"

Beobachte kubectl -n demo get hpa web -w: Du siehst, wie die Ziel-Replica-Zahl mit steigender CPU klettert und sich wieder einpendelt, sobald du die Last stoppst (Strg-C).

Nächste Schritte

• Setze sinnvolle Requests und Limits, damit Autoscaler und Scheduler mit verlässlichen Signalen arbeiten.
• Ergänze ein PodDisruptionBudget, damit geplante Unterbrechungen (Upgrades, Drains) nie zu viele Replicas gleichzeitig treffen.