Workloads skalieren und autoskalieren

Sobald deine App läuft (siehe Ein Image mit kubectl deployen), lautet die nächste Frage: Kapazität. Wie fängst du mehr Traffic ab, ohne für ungenutzte Kapazität zu zahlen? Kubernetes skaliert Workloads auf zwei Arten, von Hand und automatisch.

Von Hand skalieren

Die einfachste Einstellung 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 Anfragen sofort über alle. Zum Herunterskalieren nimmst du denselben Befehl mit einer kleineren Zahl.

Replicas über Nodes verteilen

Dieser Abschnitt ist für Cluster mit mehr als einem Node. Mehr Replicas helfen der Verfügbarkeit nur, wenn sie nicht alle auf demselben Node landen. Topology Spread Constraints halten sie auseinander:

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 startet sie anderswo.

Ein PaaSbox-Cluster hat einen Node, also gibt es nichts zu verteilen: Jede Replica läuft auf demselben Server. Replicas helfen dort trotzdem. Ein abgestürzter Pod ist einer von mehreren, und ein Rollout ersetzt sie einen nach dem anderen. Sie helfen nicht, wenn der Server selbst wegfällt.

Autoscaling mit einem HPA

Ein HorizontalPodAutoscaler setzt die Zahl der Replicas anhand der gemessenen Last. Dieser hier zielt auf durchschnittlich 60 % CPU, zwischen 2 und 10 Replicas. Speichere ihn als hpa.yaml:

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. k3s installiert ihn standardmäßig, er läuft also auf jedem PaaSbox-Cluster von Anfang an, und der Autoscaler funktioniert ohne weitere Einrichtung. Der HPA misst gegen die Resource-Requests, die du am Container gesetzt hast, ein Grund mehr, sie immer anzugeben.

Der HPA fügt Pods hinzu, keine Server. Will er mehr Pods, als auf die Nodes passen, bleiben die zusätzlichen Pods Pending. Auf einem Cluster mit Cluster-Autoscaler kommt innerhalb von Minuten ein neuer Node dazu. Ein PaaSbox-Cluster hat einen Server und keinen Autoscaler: Setz maxReplicas so, dass die Requests der Replicas neben allem anderen auf diesen Server passen.

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: Die Ziel-Replica-Zahl steigt mit der CPU und fällt wieder, sobald du die Last stoppst (Strg-C).

Nächste Schritte

• Setz Requests und Limits, die zu dem passen, was die App braucht, damit Autoscaler und Scheduler mit genauen Zahlen arbeiten.
• Ergänze ein PodDisruptionBudget, wo es mehrere Nodes gibt, damit ein Drain nie zu viele Replicas gleichzeitig trifft. Auf einem einzelnen Node trägt es keine Pods durch ein Upgrade: Ein Upgrade bei PaaSbox startet den Server neu, und jeder Pod steht, bis der Server wieder da ist (Einen Cluster upgraden).