Wenn ein Rollout nicht mehr weiterkommt

Signal

Ein Deployment überschreitet seine Fortschrittsfrist, oder neue Pods bleiben unbereit, während das bisherige ReplicaSet weiter Anfragen bedient. Dies ist ein allgemeines Runbook. Namen, Namespaces und Eskalationswege an die eigene Umgebung anpassen.

Umfang feststellen

Vor der Untersuchung Cluster-Kontext und Namespace bestätigen. Diese Befehle lesen den Zustand und ändern das Deployment nicht.

kubectl config current-context
kubectl -n <namespace> rollout status deployment/<app> --timeout=30s
kubectl -n <namespace> describe deployment <app>
kubectl -n <namespace> get pods -l app=<app> -o wide

Diagnose

1. Pod-Events auf Image-Pull-Fehler, fehlende Ressourcen und Mount-Probleme prüfen.
2. Readiness-Fehler und Anwendungslogs untersuchen. Beim Teilen von Logs keine Zugangsdaten offenlegen.
3. Image-Digest und Konfiguration mit dem letzten gesunden Release vergleichen.
4. Fehlerrate und Latenz bestehender Nutzer prüfen. Ein blockierter Rollout ist nicht automatisch ein Ausfall.

Wiederherstellung

Bei GitOps den gewünschten Image-Digest in Git zurücksetzen. Ein imperativer Rollback kann durch den Abgleich sofort überschrieben werden. Wenn Git oder der Controller ausfällt, den Notfallprozess des Teams befolgen.

Prüfung und Abschluss

Bestätigen, dass alle vorgesehenen Replikate bereit sind, der Controller den synchronisierten Zustand meldet und nutzerrelevante Signale wieder normal sind. Änderung, Fehlerursache und fehlende Vorabprüfung dokumentieren.