Zum Hauptinhalt springen

Versionen

Kubernetes​

Kubernetes folgt Semantic Versioning: Jede Version besteht aus drei Zahlen – Major.Minor.Patch (z. B. 1.33.10).

SegmentBeispielWas ändert sich?Release-Rhythmus
Minor1.33.xNeue Features, neue API-Versionen, veraltete APIs können entfernt werden~ alle 4 Monate
Patch1.33.10Bugfixes, Security-Patches – keine neuen FeaturesLaufend

Ein Minor-Update erfordert deshalb mehr Aufmerksamkeit: Veraltete APIs, Flags oder Verhalten können wegfallen. Die Kubernetes API-Deprecation-Policy legt fest, wie lange alte APIs noch unterstützt werden.

OS-Updates (Gardenlinux)​

Die Worker Nodes laufen unter Gardenlinux, einer für Kubernetes optimierten Linux-Distribution. OS-Updates sind unabhängig von der Kubernetes-Version: Sie bringen keine neuen Kubernetes-Features, verbessern aber Stabilität und schließen Sicherheitslücken.

Auto-Updates und Wartungsfenster​

Im Dashboard lassen sich Auto-Updates pro Cluster aktivieren. Damit werden folgende Updates automatisch eingespielt:

  • OS-Updates (Gardenlinux)
  • Kubernetes Patch-Updates (z. B. 1.33.9 → 1.33.10)

Dafür wird ein Wartungsfenster (Maintenance window) festgelegt: mindestens 30 Minuten, an einem frei wählbaren Wochentag und zu einer frei wählbaren Uhrzeit.

Minor-Updates (z. B. 1.32 → 1.33) werden nicht automatisch eingespielt und müssen manuell angestoßen werden. So bleibt Zeit, Changelogs zu prüfen und Anwendungen auf Kompatibilität zu testen.

Abgekündigte Versionen / End of Life​

Veraltete Kubernetes-Versionen werden von uns abgekündigt:

  • Wenn die Minor-Version (z. B. 1.29) ihr End of Life erreicht hat
  • Wenn eine neuere Patchversion der jeweiligen Minor-Version bereit steht (z. B. 1.33.9 → 1.33.10)

Eine Abgekündigte Version erkennen Sie im Dashboard am Hinweis "Deprecated". Sollte ihr Cluster eine solche Version verwenden wird die Version Orange umrandet dargestellt, mit dem Hinweis "Kubernetes version is deprecated".

Kubernetes Update​

  • Klicken Sie im Dashboard auf den Button "Update Cluster", rechts neben der angezeigten Version
  • Wählen Sie aus der Liste die gewünschte Version
  • Bestätigen Sie das Update, indem Sie den Clusternamen eintragen und auf UPDATE klicken

Was passiert beim Update?​

Sowohl OS- als auch Kubernetes Minor-Update ersetzen die Worker Nodes. Der Ablauf:

  1. Neue Nodes (Worker) werden hochgefahren
  2. Workloads werden von den alten Nodes auf die neuen verschoben (drain).
  3. Die alten Nodes werden entfernt.

Bei Kubernetes Update wird zusätzlich die Control Plane mit allen Komponenten aktualisiert. Ist diese nicht als hochverfügbare (HA) Variante realisiert kann es während des Updates zu kurzen Unterbrechungen der API kommen.

Dabei werden die Cluster-Einstellungen maxSurge und minUnavailable berücksichtigt, sodass nicht alle Nodes gleichzeitig ausgetauscht werden. Für die meisten Workloads läuft dieser Prozess unterbrechungsfrei ab.

⚠ Bekannte Probleme beim Update / Drain​

  • HashiCorp Vault: Wird Vault ohne Auto-Unseal betrieben, ist Vault nach dem Austausch der Worker Nodes versiegelt (sealed) und muss manuell wieder geöffnet werden. Dieser Schritt sollte bei Maintenance-Fenstern eingeplant werden.
  • Cloudnative-PG: Bei CNPG kann es zu kurzzeitigen Problemen mit Pod disruption budgets (PDBs) kommen, wenn die primäre Datenbank (Pod) evicted wird. Das Problem löst sich in aller Regel innerhalb weniger Minuten.