Kubernetes v1.37: Upgrade ohne Ausfall

Kubernetes v1.37 ist am 26. August 2026 erschienen. Drei Änderungen brechen laufende Cluster beim Upgrade: Static Pods dürfen keine Secrets oder ConfigMaps mehr referenzieren, das kubelet startet nicht mehr, wenn veraltete cAdvisor-Flags gesetzt sind, und SELinuxMount ist neu standardmässig aktiv. Die oft zitierte containerd-1.x-Frist dagegen wurde erneut verschoben.

Die vollständigen Release Notes stehen in CHANGELOG-1.37.md im Repo kubernetes/kubernetes, die Feature-Übersicht im Sneak Peek vom 31. Juli 2026. Wer zwei bis zwanzig produktive Cluster betreibt, braucht davon nur den Teil, der wehtut: eine Reihenfolge und ein paar Prüfbefehle. Genau das steht unten.

Static Pods dürfen keine Secrets und ConfigMaps mehr referenzieren

Kubernetes v1.37 entfernt das Feature Gate PreventStaticPodAPIReferences. Static Pods, die configMapRef oder secretRef verwenden, starten nach dem Upgrade nicht mehr. Betroffen sind vor allem Bare-Metal-Installationen und selbstverwaltete Control Planes, nicht von kubeadm verwaltete Standardkomponenten.

Das ist ein Bugfix, keine Schikane. Static Pods werden vom kubelet direkt aus /etc/kubernetes/manifests/ gelesen und laufen nicht über den API-Server. Dass sie trotzdem API-Objekte referenzieren konnten, war ein Fehler. Laut Release-Eintrag wurde das Gate entfernt und kann nicht mehr deaktiviert werden.

Die Prüfung dauert eine Minute pro Node:

# Auf jedem Control-Plane- und Worker-Node
grep -rlE 'configMapRef|secretRef' /etc/kubernetes/manifests/

Jede Ausgabezeile ist ein Manifest, das ihr vor dem Upgrade umbauen müsst. Der Ersatz ist unspektakulär: Werte als Literal in die Pod-Spec schreiben, Dateien über hostPath einhängen, oder die Komponente aus dem Static-Pod-Verzeichnis in ein echtes DaemonSet überführen.

Das kubelet startet nicht mehr, wenn alte cAdvisor-Flags gesetzt sind

Das kubelet in v1.37 verweigert den Start, sobald eine veraltete cAdvisor-Option in seiner Konfiguration steht. Das eingebettete cAdvisor nutzt neu das schlankere Modul github.com/google/cadvisor/lib, und von den alten Flags überlebt nur --housekeeping-interval.

Diese Änderung ist in den Release Notes als Deprecation geführt, wirkt in der Praxis aber wie ein harter Breaking Change: Ein Node mit --containerd, --boot-id-file, --machine-id-file, --container-hints, --global-housekeeping-interval, --event-storage-age-limit oder einem der --storage-driver-*-Flags kommt nach dem Neustart schlicht nicht zurück.

# Auf jedem Node: verbotene cAdvisor-Flags in der kubelet-Unit finden
systemctl cat kubelet | grep -E -- \
  '--(application-metrics-count-limit|boot-id-file|container-hints|containerd|enable-load-reader|event-storage-|global-housekeeping-interval|log-cadvisor-usage|machine-id-file|storage-driver-)'

Exit-Code 1 und keine Ausgabe heisst: sauber. Zusätzlich verschwinden die Metriken container_cpu_load_average_10s, container_cpu_load_d_average_10s und container_tasks_state aus /metrics/cadvisor. Wer davon ein Grafana-Panel oder eine Alerting-Regel abhängig gemacht hat, sieht nach dem Upgrade eine stumme Lücke statt eines Fehlers. Das ist die unangenehmere Variante. Mehr dazu in unserem Beitrag über Observability, die man liest.

containerd 2.0 unter Kubernetes: ist der Wechsel für v1.37 Pflicht?

Nein, containerd 2.0 ist auch mit Kubernetes v1.37 nicht Pflicht. Die Behauptung kursiert seit dem v1.36-Zyklus in Upgrade-Guides und stimmt nicht. Die Entfernung der veralteten kubelet-Konfigurationsflags samt CRI-Fallback wurde zweimal verschoben: in CHANGELOG-1.36.md von v1.36 auf v1.37, und in CHANGELOG-1.37.md erneut von v1.37 auf v1.38 (PR #139121, gemergt am 22. Mai 2026), ausdrücklich „to align with containerd v1.7 support“.

Entspannt euch trotzdem nicht. Laut containerd RELEASES.md endet der verlängerte Support für containerd 1.7 im September 2026, und er ist explizit auf Kubernetes 1.30 bis 1.32 auf GKE beschränkt. Für alles andere ist 1.7 bereits jetzt unbetreut.

Das kubelet sagt euch selbst, wann Schluss ist:

# Node-Inventar: kubelet-Version, Runtime, OS-Image
kubectl get nodes -o custom-columns='NODE:.metadata.name,\
KUBELET:.status.nodeInfo.kubeletVersion,\
RUNTIME:.status.nodeInfo.containerRuntimeVersion,\
OS:.status.nodeInfo.osImage'

# kubelet-Metriken: cgroup-Version und Support-Ende der Runtime
kubectl get --raw "/api/v1/nodes/<NODE>/proxy/metrics" \
  | grep -E '^kubelet_(cgroup_version|cri_losing_support)'

kubelet_cri_losing_support ist ein Gauge mit dem Label version und meldet, in welcher Kubernetes-Version die aktuell laufende CRI-Implementierung ihren Support verliert. Alpha-Stabilität, aber genau die Zahl, die man beim Planen braucht.

Was der Sprung von 1.7 auf 2.x konkret bedeutet:

Punkt	containerd 1.7	containerd 2.x
Support	verlängert bis September 2026, nur für K8s 1.30 bis 1.32 auf GKE	2.3 als LTS bis 30.04.2028
CRI-API	`v1` und `v1alpha2`	nur `v1`, `v1alpha2` entfernt
`config.toml`	Version 2	Version 3 empfohlen, Version 2 läuft weiter
Docker-Schema-1-Images	Pull möglich, deprecated	in 2.0 deaktiviert, in 2.1 entfernt
Runtime-Plugins als `*.so`	unterstützt	in 2.1 entfernt, externe Plugins nutzen

Wenn ihr migriert, geht auf containerd 2.3: LTS bis 30. April 2028. containerd 2.2 läuft schon am 6. November 2026 aus, 2.1 ist seit dem 3. Juli 2026 EOL. Die Config muss dabei nicht sofort mitwandern, Version 2 wird von containerd 2.x weiterhin gelesen.

Wer nicht sicher ist, ob seine Nodes nach dem kubelet-Neustart zurückkommen, findet das in etwa einer Stunde heraus: Node-Inventar, kubelet-Unit-Diff, Static-Pod-Scan. Wir schauen uns das gemeinsam an, wenn ihr das nicht selbst durchgehen wollt.

cgroup v1 ist seit v1.35 erledigt, nicht erst jetzt

Das kubelet startet seit Kubernetes v1.35 auf cgroup-v1-Nodes nicht mehr, weil failCgroupV1 dort standardmässig auf true steht. Der Sneak Peek zu v1.37 führt das als laufende Änderung, nicht als Neuerung.

Praktisch heisst das: Wer heute noch auf v1.34 sitzt, trifft cgroup v1 nicht beim Sprung auf v1.37, sondern schon beim Zwischenschritt auf v1.35. Betroffen sind ältere Node-Images und On-Prem-Bestände, typischerweise CentOS 7, RHEL 7 und Ubuntu 18.04. Die Metrik kubelet_cgroup_version aus dem Block oben beantwortet das pro Node, ohne dass jemand sich einloggen muss.

kube-proxy IPVS: die Uhr läuft, aber langsam

Der IPVS-Modus von kube-proxy verschwindet über vier Releases, nicht in diesem. KEP-5495 legt den Pfad fest: v1.35 Warnungen, v1.37 neues Feature Gate KubeProxyIPVS (standardmässig aktiv), v1.40 Gate standardmässig aus, v1.43 Code entfernt, v1.46 Gate entfernt.

Die Begründung ist ehrlich und im KEP nachlesbar: „sig-network currently lacks maintainers who are familiar with the ipvs backend code.“ Dazu kommt, dass IPVS unter der Haube weiterhin iptables benutzt. Migrationsziel ist nftables, GA seit v1.33.

kubectl -n kube-system get configmap kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep 'mode:'

Ein leeres mode: ist ab v1.37 ebenfalls eine Warnung wert: kube-proxy meldet neu, wenn kein Modus explizit gesetzt ist, weil der Linux-Default künftig von iptables auf nftables wechselt. Setzt den Wert explizit, auch wenn ihr beim aktuellen Verhalten bleiben wollt.

Welche Kubernetes-Version noch Support hat

Kubernetes pflegt die drei jüngsten Minor-Releases, das ergibt rund ein Jahr Patch-Support pro Version. Stand kubernetes.io/releases vom 18. August 2026:

Version	Release	End of Life	Was zu tun ist
v1.34	27.08.2025	27.10.2026	Akut. Zwei Monate Rest, drei Minor-Sprünge bis v1.37
v1.35	17.12.2025	28.02.2027	cgroup v1 bereits scharf, IPVS-Warnungen aktiv
v1.36	22.04.2026	28.06.2027	Komfortabelste Ausgangslage, ein Sprung auf v1.37
v1.37	26.08.2026	ca. Oktober 2027 *	Neu, anfangs .0-Patchstand

* EOL für v1.37 ist noch nicht publiziert. Der Wert ist aus dem 14-Monats-Muster der drei Vorgänger extrapoliert und als Planungsgrösse zu behandeln, nicht als Zusage.

Für Schweizer Teams auf Exoscale SKS kommt ein zweiter Takt dazu: Minor-Versionen werden dort rund 14 Monate unterstützt, Upgrades müssen sequenziell durch jede Minor-Version laufen, und der Control Plane wird zuerst gehoben, danach werden die NodePools durchgetauscht. Von v1.34 auf v1.37 sind das drei Runden, nicht eine.

Die Upgrade-Reihenfolge, die wir empfehlen

Ein Upgrade ohne Ausfall folgt der offiziellen Version Skew Policy: Control Plane vor Nodes, keine übersprungenen Minor-Versionen beim kube-apiserver.

Prüfen, bevor irgendetwas angefasst wird. Static-Pod-Scan, cAdvisor-Flag-Scan, kubelet_cgroup_version, kubelet_cri_losing_support, kube-proxy-Modus. Alle fünf Befehle stehen oben.
scheduling.k8s.io/v1alpha2 aus etcd räumen. v1.37 entfernt die Version vollständig zugunsten von v1alpha3. Bestehende Objekte müssen vor dem Update weg.
kube-apiserver hochziehen, danach kube-controller-manager, kube-scheduler und cloud-controller-manager. Diese drei dürfen höchstens eine Minor-Version älter sein als der API-Server.
Einen Worker-Node exemplarisch heben. kubelet und kube-proxy dürfen bis zu drei Minor-Versionen älter sein als der kube-apiserver. Ihr habt also Zeit, und ihr braucht sie: Der erste Node ist der Test.
Restliche NodePools rollen, mit PodDisruptionBudgets, die den Namen verdienen. Ein PDB mit minAvailable: 1 bei zwei Replicas blockiert kein Drain, er verzögert es nur.

Ein Punkt, der gern untergeht: SELinuxMount ist in v1.37 GA und standardmässig aktiv. Auf Clustern mit aktiviertem SELinux, also praktisch jedem RHEL- und OpenShift-Bestand, kann das laufende Workloads brechen. Kubernetes hat dazu am 22. April 2026 einen eigenen Blogbeitrag publiziert, der die betroffenen Muster im v1.36-Cluster identifizierbar macht. Ohne SELinux ändert sich nichts.

Wann ihr nicht upgraden solltet

Upgradet nicht auf v1.37.0. Wartet auf v1.37.1 oder v1.37.2, ausser ihr habt einen konkreten Grund. Ein .0-Release ist am Erscheinungstag der am wenigsten in Produktion gelaufene Stand einer Version, und die Historie der Urgent Upgrade Notes gibt einem wenig Anlass zu Optimismus.

Der Trade-off ist real und geht in beide Richtungen: Wer wartet, sammelt Distanz zu v1.34, dessen Support am 27. Oktober 2026 endet. Weil kube-apiserver keine Minor-Versionen überspringen darf, sind das drei sequenzielle Upgrades. Wer erst im Oktober anfängt, macht drei Sprünge unter Zeitdruck statt einen entspannt.

Unsere Linie: Wer auf v1.36 sitzt, hat bis Juni 2027 Ruhe und kann auf .2 warten. Wer auf v1.34 sitzt, fängt diese Woche an, und zwar mit v1.35, nicht mit v1.37. Und wer mitten im Quartalsabschluss steckt oder ein Release-Freeze fährt, verschiebt das Ganze bewusst und schriftlich, statt es zu vergessen.

Packt ausserdem nicht alles in dasselbe Wartungsfenster. Ingress NGINX wurde im März 2026 retired, ohne weitere Security-Patches, laut interner Datadog-Recherche mit rund der Hälfte aller Cloud-Native-Umgebungen im Rücken. Der Wechsel auf die Gateway API ist ein eigenes Projekt mit eigenem Risiko, kein Nebenschauplatz eines Minor-Upgrades.

Ein Cluster ist ohnehin kein Selbstzweck. Bevor ihr drei Upgrade-Runden plant, lohnt die Frage, ob ein Cluster überhaupt die richtige Antwort ist.

Häufige Fragen

Wie funktioniert ein Kubernetes-Cluster-Upgrade ohne Ausfall?

Ein ausfallfreies Upgrade hebt zuerst den Control Plane, dann die Nodes. Der kube-apiserver kommt zuerst, danach controller-manager und scheduler, zuletzt kubelet und kube-proxy. Workloads bleiben verfügbar, wenn jede Anwendung mindestens zwei Replicas, ein sinnvolles PodDisruptionBudget und funktionierende Readiness-Probes hat. Nodes werden einzeln gedraint, nicht parallel.

Welche Kubernetes-Version wird noch unterstützt?

Unterstützt sind v1.35, v1.36 und v1.37, sobald v1.37 veröffentlicht ist. v1.34 erreicht am 27. Oktober 2026 sein End of Life. Kubernetes pflegt grundsätzlich die drei jüngsten Minor-Releases, was rund ein Jahr Patch-Support pro Version ergibt. Managed-Anbieter weichen ab: Exoscale SKS gibt rund 14 Monate.

Wie prüfe ich, welchen kube-proxy-Modus mein Cluster nutzt?

Der Befehl kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:' liest den Modus aus der ConfigMap. Ein leerer Wert bedeutet Default, aktuell iptables auf Linux. Steht dort ipvs, plant die Migration auf nftables ein: ab v1.40 ist IPVS standardmässig deaktiviert, ab v1.43 entfernt.

Muss ich für Kubernetes v1.37 auf containerd 2.x wechseln?

Nein, nicht zwingend. Die Entfernung des kubelet-CRI-Fallbacks wurde auf v1.38 verschoben. Der verlängerte Support für containerd 1.7 endet aber im September 2026 und deckt nur Kubernetes 1.30 bis 1.32 auf GKE ab. Praktisch heisst das: Plant den Wechsel auf containerd 2.3 jetzt, aber nicht im selben Wartungsfenster wie das v1.37-Upgrade.

Upgrade-Pfad besprechen. 30 Minuten mit einem unserer Platform-Engineers über euren konkreten Cluster: welche Version, welche Runtime, welche Reihenfolge, welches Fenster. Kein Verkaufsgespräch, kein Vorbereitungsaufwand auf eurer Seite.

Termin buchen · Kontakt aufnehmen · Mehr zu Kubernetes und Infrastruktur