Wenn automatische Updates fehlschlagen

Automatische Updates mit Renovate sind praktisch, aber was passiert, wenn etwas schiefgeht? In diesem Artikel zeige ich typische Probleme, wie man sie erkennt und welche Strategien es zur Fehlerbehebung gibt.

Fehlgeschlagene Pods und Jobs nach Updates im Kubernetes-Dashboard
Fehlgeschlagene Pods und Jobs nach Updates im Kubernetes-Dashboard

Typische Gründe für fehlgeschlagene Updates

Nicht jedes Update läuft reibungslos. Hier sind einige typische Ursachen für Probleme:

  • Geänderte Konfiguration: Ein neues Release kann Änderungen an den Standardwerten oder neue Konfigurationsoptionen mit sich bringen.
  • Fehlgeschlagene Datenmigration: Manche Updates erfordern Schema-Änderungen in der Datenbank. Falls diese nicht oder nur teilweise durchgeführt werden, startet die Anwendung möglicherweise nicht mehr.
  • Inkompatibilitäten mit anderen Diensten: Falls ein Service mit einer anderen Version nicht mehr kompatibel ist (z. B. API-Änderungen), können Abhängigkeiten nicht mehr richtig interagieren.
  • Fehlerhafte Helm-Charts: Manchmal enthalten Updates im Helm-Chart Fehler oder unvollständige CRD-Anpassungen.
  • Software-Bugs: Es kann immer passieren, dass eine neue Version einfach fehlerhaft ist und unerwartete Probleme verursacht.

Wie erkennt man, dass ein Update fehlgeschlagen ist?

Das offensichtlichste Anzeichen für ein fehlerhaftes Update ist, dass die Anwendung nicht mehr läuft. Doch es gibt verschiedene Symptome:

  • Pods starten nicht: kubectl get pods zeigt an, dass der neue Pod im Status CrashLoopBackOff oder Error hängt.
  • Pod startet, aber die Anwendung funktioniert nicht: Die Logs (kubectl logs <pod>) zeigen Fehler, etwa fehlende Konfigurationen oder unerwartete Datenbankfehler.
  • Andere Dienste sind betroffen: Falls eine Abhängigkeit nicht mehr funktioniert, kann das Auswirkungen auf andere Anwendungen haben. Monitoring-Tools wie Prometheus und Grafana helfen, solche Probleme zu erkennen.
  • Externe Dienste nicht erreichbar: Falls beispielsweise ExternalDNS nicht korrekt arbeitet, können neue DNS-Einträge fehlen oder bestehende Einträge gelöscht werden.

Wie behebt man den fehlerhaften Zustand?

Sobald man das Problem erkannt hat, gibt es verschiedene Ansätze zur Lösung:

  1. Rollback auf eine funktionierende Version
    • Falls das Update eine Fehlfunktion verursacht, kann man mit FluxCD oder Helm einfach zur letzten stabilen Version zurückkehren.
    • Beispiel: helm rollback <release> <revision> oder ein git revert der Änderung in der FluxCD-Konfiguration.
    • Falls das Update einen kritischen Fehler verursacht hat, kann es sinnvoll sein, das Update in Renovate vorübergehend zu ignorieren (ignoreUnstable=true).
    • Falls ein Deployment in Kubernetes fehlschlägt, kann kubectl rollout undo deployment <deployment> helfen, die vorherige Version wiederherzustellen.
  2. Backups nutzen, falls Daten migriert wurden
    • Falls das Update eine fehlerhafte Datenmigration durchgeführt hat, muss man möglicherweise eine Datenbanksicherung einspielen.
    • Regelmäßige Backups helfen, solche Probleme abzufangen.
  3. Roll-forward mit Anpassungen
    • Falls die neue Version zwar prinzipiell funktioniert, aber Änderungen an der Konfiguration erfordert, kann man versuchen, die fehlenden Anpassungen nachzuziehen.
    • Dokumentation und Changelogs der Software helfen oft, die Ursache für Probleme zu finden.
    • Falls eine spezifische Version fehlerhaft ist, kann man eine neuere Version abwarten oder selbst Fixes anwenden.
  4. Manuelles Debugging
    • Falls unklar ist, warum die Anwendung nicht funktioniert, helfen kubectl describe pod und kubectl logs oft weiter.
    • Temporär kann es helfen, den alten und den neuen Container parallel laufen zu lassen, um Unterschiede festzustellen.

Wie kann man fehlerhafte Updates verhindern?

Es gibt einige Strategien, um das Risiko von fehlgeschlagenen Updates zu minimieren:

  1. Testumgebungen nutzen
    • In produktiven Umgebungen empfiehlt sich eine Staging-Umgebung, in der neue Versionen vorab getestet werden können.
    • In meinem Heim-Setup ist das nicht praktikabel, aber in Unternehmensumgebungen ist es sinnvoll.
  2. Ausnahmen für kritische Anwendungen
    • Kritische Anwendungen sollten von automatischen Updates ausgenommen werden.
    • Renovate bietet feingranulare Möglichkeiten, automatische Updates auf Patches und Minor-Versionen zu begrenzen.
  3. Monitoring und Alerting einrichten
    • Tools wie Prometheus und Grafana helfen, Probleme schnell zu erkennen.
    • Alerts können eingerichtet werden, um kritische Dienste im Auge zu behalten.
  4. Gezielt Updates verzögern
    • Falls eine neue Version bekanntermaßen fehlerhaft ist, kann sie in Renovate explizit ausgeschlossen werden.
    • Beispiel: Bei ExternalDNS gab es einmal eine fehlerhafte Version, in der die CRDs nicht aktualisiert wurden. Hier habe ich Renovate so konfiguriert, dass diese Version übersprungen wird, bis ein Fix veröffentlicht wurde. Dies stellt sicher, dass Renovate weiterhin Updates innerhalb der 1.12.x-Serie zulässt, aber Versionen ab 1.13.0 ignoriert.
{
  "packageRules": [
    {
      "matchPackageNames": ["external-dns"],
      "allowedVersions": "< 1.13.0"
    }
  ]
}Code-Sprache: JSON / JSON mit Kommentaren (json)
  1. Changelogs lesen und Breaking Changes beachten
    • Viele Probleme entstehen, weil eine neue Version eine geänderte Konfiguration erfordert.
    • Ein Blick in die Release Notes kann helfen, Überraschungen zu vermeiden.

Mit diesen Strategien lassen sich fehlgeschlagene Updates entweder vermeiden oder schnell beheben. Falls du eigene Erfahrungen mit problematischen Updates hast, teile sie gerne in den Kommentaren!

Weitere Blogposts aus der k3s-Reihe

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert