Kubernetes-Upgrades ohne Downtime durchführen

TL;DR

Kubernetes-Cluster lassen sich ohne Downtime upgraden, wenn die richtige Reihenfolge eingehalten wird: erst Control Plane, dann Worker Nodes einzeln per kubectl drain. PodDisruptionBudgets schützen dabei die Anwendungsverfügbarkeit. Bei Managed Services wie EKS, AKS und GKE übernimmt der Provider den Control-Plane-Upgrade automatisch.

Upgrade-Reihenfolge verstehen

Die goldene Regel bei Kubernetes-Upgrades: immer nur eine Minor-Version nach oben. Ein Sprung von 1.28 auf 1.30 ist nicht unterstützt. Die korrekte Reihenfolge:

# Aktuelle Version prüfen
kubectl version --short

# Verfügbare Versionen anzeigen (kubeadm)
kubeadm upgrade plan

# Control Plane upgraden (Master Node)
sudo kubeadm upgrade apply v1.30.2

# kubelet und kubectl auf dem Master aktualisieren
sudo apt-get update && sudo apt-get install -y kubelet=1.30.2-1.1 kubectl=1.30.2-1.1
sudo systemctl daemon-reload && sudo systemctl restart kubelet

Der API-Server bleibt während des Control-Plane-Upgrades erreichbar, weil Kubernetes eine Version Skew zwischen Control Plane und Worker Nodes toleriert. Worker Nodes dürfen bis zu zwei Minor-Versionen hinter dem API-Server liegen.

PodDisruptionBudgets konfigurieren

Bevor Nodes drainiert werden, müssen PodDisruptionBudgets (PDBs) existieren. Sie verhindern, dass zu viele Pods gleichzeitig offline gehen:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-app-pdb
  namespace: production
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web-app
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
  namespace: production
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: api-service

minAvailable und maxUnavailable schließen sich gegenseitig aus. Für Deployments mit wenigen Replicas ist maxUnavailable: 1 meist die bessere Wahl.

Rolling Node Upgrades

Worker Nodes werden einzeln aktualisiert. Der Ablauf pro Node:

# 1. Node als nicht-schedulbar markieren
kubectl cordon worker-node-01

# 2. Alle Pods vom Node evakuieren
kubectl drain worker-node-01 \
  --ignore-daemonsets \
  --delete-emptydir-data \
  --grace-period=120 \
  --timeout=300s

# 3. Node upgraden (OS-Pakete)
ssh worker-node-01
sudo apt-get update
sudo apt-get install -y kubelet=1.30.2-1.1 kubectl=1.30.2-1.1
sudo kubeadm upgrade node
sudo systemctl daemon-reload && sudo systemctl restart kubelet
exit

# 4. Node wieder freigeben
kubectl uncordon worker-node-01

# 5. Prüfen ob Pods korrekt gestartet sind
kubectl get pods -o wide | grep worker-node-01

Wichtig: --grace-period=120 gibt Pods zwei Minuten für ein sauberes Herunterfahren. Das verhindert abgebrochene Requests.

Pre-Upgrade-Checkliste

Vor jedem Upgrade diese Punkte prüfen:

API-Deprecations sind der häufigste Grund für Probleme nach einem Upgrade. Das Tool kubent (Kube No Trouble) findet veraltete API-Versionen:

# kubent installieren und ausführen
kubent

# Ausgabe zeigt betroffene Ressourcen:
# >>> Deprecated APIs removed in 1.30 <<<
# Ingress found in networking.k8s.io/v1beta1

Managed vs. Self-Managed Upgrades

Bei Managed Kubernetes sieht der Upgrade-Prozess anders aus:

EKS (AWS): Control Plane wird über die AWS Console oder eksctl aktualisiert. Node Groups können als Managed Node Groups automatisch gerollt werden. Der Prozess dauert 20-30 Minuten pro Node Group.

AKS (Azure): az aks upgrade aktualisiert Control Plane und Node Pools. Surge Upgrades erlauben zusätzliche Nodes während des Upgrades, sodass keine Kapazitätsengpässe entstehen.

GKE (Google): Bietet Release Channels (Rapid, Regular, Stable) mit automatischen Upgrades. Maintenance Windows definieren, wann Upgrades stattfinden dürfen.

Der Vorteil von Managed Services: kein etcd-Backup nötig, kein manuelles Certificate-Renewal, kein kubeadm. Der Nachteil: weniger Kontrolle über den genauen Zeitpunkt und die Upgrade-Geschwindigkeit.

Rollback-Strategie

Falls nach dem Upgrade Probleme auftreten:

# Node-Status prüfen
kubectl get nodes -o wide

# Pods mit Fehlern finden
kubectl get pods -A | grep -E "Error|CrashLoop|Pending"

# Im Worst Case: Node auf alte Version zurücksetzen
# (nur bei Self-Managed möglich)
sudo apt-get install -y kubelet=1.29.8-1.1
sudo systemctl restart kubelet

Bei Managed Services gibt es kein Control-Plane-Rollback. Deshalb: immer zuerst in einem Staging-Cluster testen.

FAQ

Wie lange dauert ein Kubernetes-Upgrade?

Ein Control-Plane-Upgrade dauert bei Self-Managed 5-15 Minuten. Worker Nodes brauchen je nach Pod-Anzahl 3-10 Minuten pro Node. Bei einem 10-Node-Cluster sollte man mit 1-2 Stunden rechnen.

Kann ich Minor-Versionen überspringen?

Nein. Kubernetes unterstützt nur sequenzielle Minor-Version-Upgrades (z.B. 1.28 auf 1.29, dann 1.29 auf 1.30). Patch-Versionen innerhalb einer Minor-Version können übersprungen werden.

Was passiert wenn ein Drain hängt?

Meist blockiert ein Pod ohne PDB oder mit terminationGracePeriodSeconds auf einem hohen Wert. Mit --timeout=300s und notfalls --force lässt sich der Drain erzwingen. Vorher prüfen, welcher Pod blockiert: kubectl get pods --field-selector spec.nodeName=<node>.

Sind Upgrades bei Managed Kubernetes sicherer?

Grundsätzlich ja, weil der Provider den Control-Plane-Upgrade testet und etcd-Backups automatisch erstellt. Aber auch bei Managed Services können Workloads durch API-Deprecations oder inkompatible Addons brechen.