Pod Disruption Budget: Wartung ohne Ausfall

Ein Pod Disruption Budget (PDB) legt fest, wie viele Instanzen einer Anwendung gleichzeitig ausfallen dürfen, wenn ein freiwilliger Eingriff stattfindet – etwa eine Knotenwartung, ein Cluster-Upgrade oder das Entfernen eines Knotens. Es ist damit das Gegenstück zu den Ressourcengrenzen: Statt den Verbrauch zu begrenzen, schützt es die Verfügbarkeit.

Freiwillig gegen unfreiwillig

Diese Unterscheidung ist der Kern der Sache:

Unfreiwillige Unterbrechungen – ein Knoten stirbt, ein Prozess stürzt ab, der Strom fällt aus. Dagegen hilft nur Redundanz: mehrere Replikate auf verschiedenen Knoten.
Freiwillige Unterbrechungen – jemand führt kubectl drain aus, ein Autoscaler entfernt einen Knoten, ein Upgrade läuft. Hier fragt Kubernetes vorher nach und berücksichtigt das PDB.

Ein PDB gilt also nicht bei einem Hardwareausfall. Wer das verwechselt, baut auf falscher Grundlage: Verfügbarkeit bei Ausfällen kommt aus Replikaten und Verteilungsregeln, Verfügbarkeit bei Wartung aus dem PDB.

Schreibweise

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: webapp-pdb
spec:
  minAvailable: 2              # ODER: maxUnavailable: 1
  selector:
    matchLabels:
      app: webapp

Von den beiden Feldern darf nur eines gesetzt sein. Sie sind unterschiedlich praktisch:

minAvailable: absolute Zahl oder Prozent. Schützt zuverlässig gegen zu viele gleichzeitige Ausfälle, muss aber angepasst werden, wenn sich die Replikatzahl ändert.
maxUnavailable: wie viele Instanzen gleichzeitig wegfallen dürfen. Skaliert besser mit der Replikatzahl, weil die Grenze relativ formuliert ist.

Verhalten prüfen

kubectl get pdb -A
kubectl describe pdb webapp-pdb -n default

# Ausgabe zeigt:
#   ALLOWED DISRUPTIONS   1
# Sinkt dieser Wert auf 0, blockiert jede weitere Eviction.

# Probe: Knoten leeren (im Trockenlauf)
kubectl drain node-2 --ignore-daemonsets --dry-run=client

# Wenn ALLOWED DISRUPTIONS 0 ist und ein Drain nötig ist,
# meldet kubectl eine blockierte Eviction. Dann ist die Bereinigung
# per --force und --disable-eviction möglich - oder man wartet,
# bis sich die Anwendung erholt hat.

Häufige Fehler

PDB ohne Replikate. Setzt man minAvailable: 1 auf ein Deployment mit einem Replikat, ist die Zahl der erlaubten Unterbrechungen dauerhaft 0. Kein Knoten lässt sich mehr warten, ohne die Regel zu umgehen. Für Einzelinstanzen ist ein PDB meist der falsche Weg.
PDB und Autoscaler im Konflikt. Ein horizontaler Autoscaler, der bis auf ein Replikat herunterskaliert, während das PDB zwei fordert, erzeugt eine dauerhafte Blockade.
Selektor zu breit. Ein PDB mit einem Selektor, der viele verschiedene Workloads trifft, ist schwer vorherzusagen. Der Selektor sollte genau eine Anwendung treffen.
PDB ohne Verteilungsregeln. Ein PDB schützt nur die Anzahl gleichzeitig laufender Instanzen. Liegen alle Replikate auf demselben Knoten, ist selbst ein perfekt gesetztes PDB nutzlos. Dafür braucht es Topology Spread Constraints oder Anti-Affinität.

Ein sinnvolles Muster

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: api
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 4
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels: {app: api}

Die Kombination ist der eigentliche Gewinn: Das PDB verhindert, dass bei einer Wartung mehr als eine Instanz gleichzeitig verschwindet; die Verteilungsregel stellt sicher, dass die verbleibenden Instanzen nicht alle auf demselben Knoten liegen. Erst beide zusammen ergeben echte Wartungsfähigkeit.