Kubernetes Upgrade: Fahrplan, Support-Ende und Notfallleitfaden

Cluster ohne Support oder Upgrade ohne Plan? WZ-IT hebt Kubernetes-Cluster im Wartungsfenster an, bei Bedarf auch als Einzelauftrag nach Aufwand ohne laufenden Vertrag. Kubernetes Support ansehen oder den dauerhaften Betrieb inklusive Upgrades prüfen.

Stand 28. Oktober 2026: Das Kubernetes-Projekt pflegt die Release-Zweige 1.37, 1.36 und 1.35 (Releases). Kubernetes 1.34 hat am 27.10.2026 das Support-Ende erreicht. Dieser Ratgeber behandelt Release-Zyklus, Versions-Skew, Vorbereitung, die Stolpersteine der letzten Minor-Sprünge, den Ablauf je Distribution und den Weg für Cluster, die bereits ohne Support laufen.

Inhaltsverzeichnis

• Release-Zyklus und Support-Fenster
• Support-Fenster nach Betriebsmodell
• Versions-Skew: was wie weit zurückliegen darf
• Vorbereitung: sechs Prüfungen vor dem Upgrade
• Stolpersteine der letzten Minor-Sprünge
• Ablauf je Distribution
• Rollback: was zurückgeht und was nicht
• Notfall: Cluster ohne Support
• Zeitfenster planen
• Selbst durchführen oder Dienstleister beauftragen
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides
• Stand und Methodik

Release-Zyklus und Support-Fenster

Neue Minor-Versionen erscheinen etwa dreimal im Jahr (Release Cycle). Jede Minor-Version erhält rund 14 Monate Patches: zwölf Monate im Standardzeitraum, danach zwei Monate im Wartungsmodus mit CVE-Fixes, Abhängigkeits-Updates und kritischen Komponentenfehlern (Patch Releases). Gepflegt werden die drei jüngsten Zweige (Version Skew Policy).

Die Zahlen stammen von der Release-Übersicht und den Release-Meldungen (1.37, 1.36, 1.35, 1.34, 1.33, 1.32). Nach dem EOL-Datum erscheinen nur vereinzelt noch Releases (Non-Active Branch History); für 1.34 kam am 28.10.2026 noch 1.34.13. Als Planungsstichtag eignet sich der Beginn des Wartungsmodus: Ein Cluster auf 1.35 sollte bis 28.12.2026 auf 1.36 oder höher stehen.

Support-Fenster nach Betriebsmodell

Das Upstream-Fenster gilt für selbst betriebene Cluster; Managed-Angebote setzen eigene Fristen darauf.

Bei Managed-Angeboten gehört das Ablaufdatum der eigenen Version in den Kalender, nicht das Upstream-Datum.

Versions-Skew: was wie weit zurückliegen darf

Die Version Skew Policy legt fest, wie weit Komponenten gegenüber dem kube-apiserver abweichen dürfen:

Daraus folgt die Reihenfolge: erst kube-apiserver, dann Controller-Manager und Scheduler, danach kubelet und kube-proxy. Der kube-apiserver überspringt keine Minor-Version, auch nicht in einem Cluster mit einer einzelnen Instanz. Vor einem kubelet-Minor-Upgrade wird die Node gedrained; ein In-place-Upgrade ohne Drain wird nicht unterstützt. Wer Nodes dauerhaft drei Versionen zurückhält, muss sie anheben, bevor die Control Plane weiter wandern darf. Die Voraussetzungen der Upgrade-Reihenfolge nennen vor einem API-Server-Schritt kubelets, die höchstens zwei Minor-Versionen hinter der Zielversion liegen; nach zwei Control-Plane-Schritten werden die Nodes daher angehoben, bevor der dritte folgt. Verteilungswerkzeuge können strengere Grenzen setzen.

Vorbereitung: sechs Prüfungen vor dem Upgrade

1. Ist-Stand erfassen. Control Plane, kubelet, Container-Runtime und cgroup-Version je Node:

   kubectl version
   kubectl get nodes -o custom-columns=NAME:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion,RUNTIME:.status.nodeInfo.containerRuntimeVersion
   stat -fc %T /sys/fs/cgroup/   # cgroup2fs = cgroup v2
   

2. Veraltete APIs finden. Seit 1.19 liefert jeder Aufruf einer veralteten API einen Warning-Header, eine Audit-Annotation und die Metrik apiserver_requested_deprecated_apis (Deprecation Policy). Die Abfrage mit der Ziel-Version im Label removed_release zeigt, welche Clients betroffen sind:

   apiserver_requested_deprecated_apis{removed_release="1.37"} * on(group,version,resource,subresource) group_right() apiserver_request_total
   

   Manifeste im Repository migriert das separat zu installierende Plugin kubectl convert; ob eine Zielversion eine API nicht mehr bedient, lässt sich am Staging-API-Server mit --runtime-config=<group>/<version>=false testen (Migrationsleitfaden).

3. Add-ons gegen die Zielversion prüfen. Jede Komponente hat eine eigene Matrix. Argo CD 3.5 ist laut Installationsdokumentation gegen Kubernetes 1.33 bis 1.36 getestet, 1.37 steht dort am 28.10.2026 nicht. Flux führt in der Installationsdokumentation Kubernetes 1.35 und neuer auf und unterstützt ältere Versionen nicht. Talos 1.14 listet Kubernetes 1.33 bis 1.37 (Support-Matrix). Beide GitOps-Werkzeuge vergleicht Argo CD vs Flux. Admission-Webhooks müssen die Daten der neuen API-Server-Version verarbeiten können. Ingress NGINX ist seit dem 24.03.2026 retired, ohne Releases und Sicherheitsfixes (Release 1.36); den Umstieg beschreibt ingress-nginx zu Gateway API.

4. Release-Notes jeder Zwischenversion lesen. Die wichtigsten Punkte der letzten Sprünge stehen im nächsten Abschnitt.

5. Sichern. Ein etcd-Snapshot ist die Grundlage jeder Wiederherstellung und wird verschlüsselt abgelegt (etcd-Betrieb). kubeadm legt zusätzlich Backups von etcd-Daten (bei externem etcd bleibt dieser Ordner leer) und Manifesten unter /etc/kubernetes/tmp an, diese bleiben nach dem Upgrade liegen (kubeadm upgrade). Ressourcen, Volumes und Datenbanken sichert das Konzept aus Kubernetes-Backup: die vier Ebenen.

6. Kapazität und Drain prüfen. Beim Drain respektiert Kubernetes die PodDisruptionBudgets; empfohlen ist in den PodDisruptionBudgets die Unhealthy Pod Eviction Policy AlwaysAllow, damit defekte Anwendungen den Drain nicht blockieren (Safely Drain a Node). Anwendungen mit einem Replikat fallen beim Drain kurz aus; ein Staging-Cluster mit dem Add-on-Stand der Produktion macht den Lauf aussagekräftig.

Stolpersteine der letzten Minor-Sprünge

Ein Cluster, der drei Zweige zurückliegt, durchläuft alle diese Punkte nacheinander.

Ablauf je Distribution

Rollback: was zurückgeht und was nicht

Die Upgrade-Anleitungen von RKE2 und k3s halten fest, dass Kubernetes Downgrades von Control-Plane-Komponenten nicht unterstützt. Die Deprecation Policy (Rule 4b) verlangt dagegen, dass nach einem Upgrade der Weg zur vorherigen Release ohne Konvertierung gespeicherter Objekte offen bleibt, solange keine neuen Funktionen genutzt wurden. Planbar ist deshalb die Wiederherstellung, nicht ein Downgrade-Befehl.

Mit einem Snapshot unmittelbar vor dem Upgrade und einem Änderungsstopp im Fenster beschränkt sich der Verlust eines Restores auf Änderungen aus dem Fenster.

Notfall: Cluster ohne Support

Ein Cluster auf einer nicht mehr gepflegten Version läuft weiter, erhält aber keine Sicherheits-Patches. Mehrere Minor-Versionen in einem Schritt zu überspringen ist für die Control Plane nicht vorgesehen. Der Weg führt über jede Zwischenversion:

Von 1.32 aus läuft die Control Plane also über 1.33 und 1.34 auf 1.35.

Vorgehen:

1. Zugriff begrenzen. Die Kubernetes-API und Verwaltungsdienste gehören nicht ins offene Netz; Kubernetes privat über NetBird erreichen beschreibt den Weg.
2. Bestand und Sicherung. Versionen, Add-ons, CRDs und Operatoren erfassen, etcd-Snapshot und Volume-Backups prüfen. Die Checkliste dazu steht in Kubernetes-Cluster übernehmen.
3. Schrittplan je Minor-Version. Für jeden Zwischenstand: Add-on-Matrix, entfernte APIs, Release-Notes, Control Plane, Nodes, Smoke-Tests. Nodes dürfen drei Minor-Versionen hinter dem API-Server liegen, die Voraussetzungen der Upgrade-Reihenfolge lassen vor einem API-Server-Schritt aber nur zwei Minor-Versionen Abstand zur Zielversion zu. Wo die Distribution es erlaubt, folgen die Nodes deshalb nach höchstens zwei Control-Plane-Schritten gebündelt.
4. Alternative prüfen. Bei vielen Schritten, undokumentierten Operatoren oder vielen Stateful-Workloads ist ein neuer Cluster auf aktueller Version mit Migration der Workloads per GitOps und Velero oft besser planbar als eine Kette von In-place-Schritten. Das ist unsere Einschätzung, keine Projektvorgabe.
5. Managed-Fristen beachten. Bei AKS, EKS und Hostern mit Pflicht-Updates bestimmt der Anbieter, wann angehoben wird; das Datum steht in der Anbieter-Dokumentation.

Zeitfenster planen

Die Länge eines Fensters ergibt sich aus Messwerten, nicht aus Faustregeln: Dauer je Control-Plane-Schritt, Dauer je Node-Drain und die Zahl der Nodes, die PodDisruptionBudgets gleichzeitig zulassen. Diese Werte liefert der Lauf im Staging-Cluster.

• Reihenfolge: Staging, danach Produktion; bei mehreren Clustern ein Cluster mit geringer Kritikalität zuerst.
• Getrennte Fenster: Control Plane, Nodes und Add-ons als eigene Schritte, jeder mit Abbruchkriterium und Rückweg.
• Rhythmus: Patch-Releases erscheinen typischerweise monatlich, Minor-Versionen etwa dreimal im Jahr. Ein Cluster, der nur einmal pro Jahr angehoben wird, durchläuft je Durchlauf etwa drei Minor-Schritte hintereinander.

Selbst durchführen oder Dienstleister beauftragen

Unsere Einschätzung: Eigenständig machbar sind ein bis zwei Minor-Schritte, wenn das Team auf genau diesem Cluster schon ein Minor-Upgrade gefahren hat und Staging der Produktion entspricht. Bei drei oder mehr Schritten, fehlendem Staging, undokumentierten Operatoren oder Wissen bei einer einzigen Person steht eine Bestandsaufnahme am Anfang; danach fällt die Entscheidung zwischen externer Unterstützung und Neuaufbau. Ein Upgrade-Angebot sollte Bestand, Schrittplan, Rückweg und Abnahmekriterien schriftlich nennen; der Rückweg wird vor dem Produktionsfenster im Staging geprobt.

Unser Vorgehen bei WZ-IT

Upgrades im Wartungsfenster sind Teil des Managed Kubernetes Betriebs ab 590 € netto je Cluster und Monat inklusive 3 Worker-Nodes; jeder weitere Worker-Node kostet 129,90 € (Stand Oktober 2026). Monitoring erfolgt 24/7, die Reaktion auf P1-Incidents erfolgt entsprechend Service Level. Vor der Übernahme eines Clusters ohne Support erfasst das Cluster-Audit ab 1.490 € netto einmalig Versionen, Add-ons, Backups und Restore. Es ist kein Penetrationstest und auf den ersten Betriebsmonat anrechenbar.

Einzelne Upgrade-Aufgaben ohne laufenden Vertrag übernimmt Kubernetes Support nach Aufwand zu 120 € netto je Stunde in der Servicezeit (Montag bis Freitag, 08:00 bis 17:00 Uhr), außerhalb davon zu 240 €. Umfang und Aufwandsrahmen liegen vor Arbeitsbeginn schriftlich vor. Zugesicherte Reaktionszeiten gibt es mit Managed Kubernetes und Service Level, nicht im Support nach Aufwand.

Weiterführende Guides

• Kubernetes-Backup: die vier Ebenen: etcd, Ressourcen, Volumes und Datenbanken zuerst sichern
• Kubernetes-Cluster übernehmen: Audit-Checkliste: Bestandsaufnahme eines fremden Clusters
• Von ingress-nginx zu Gateway API migrieren: Add-on nach Support-Ende ersetzen
• Helm 3 auf Helm 4 migrieren: Fristen beim Paketmanager
• k3s vs. RKE2 vs. Talos: die Distributionen im Vergleich
• Argo CD vs Flux: GitOps-Werkzeug wählen und dessen Kubernetes-Matrix prüfen

Stand und Methodik

• Erhebung: 28.10.2026. Die Termine stammen von den Release-Seiten und Release-Meldungen des Kubernetes-Projekts, die Anbieterangaben aus der jeweiligen Dokumentation mit Abruf am selben Tag.
• Rechnung: Restlaufzeit = Support-Ende minus 28.10.2026 in Tagen; Schritte = Zielversion minus Ist-Version in Minor-Einheiten, weil der kube-apiserver keine Minor-Version überspringt.
• Wartungsmodus: zwei Monate vor dem Support-Ende, so von der Patch-Release-Seite für 1.34 bis 1.37 angegeben.
• Nicht enthalten: OpenShift und weitere herstellerspezifische Lebenszyklen. Maßgeblich ist die verlinkte Dokumentation.

Die Tabellen dürfen mit Quellenangabe und Link auf diesen Ratgeber weiterverwendet werden.

Cluster auf 1.34 oder älter? Ein Einzelauftrag oder der laufende Betrieb mit Upgrades im Wartungsfenster: Kubernetes Support oder Managed Kubernetes.

Angebot zum Thema: Kubernetes-Upgrade und Versionsende