Kubernetes 1.32 und 1.33 im Rückblick: die Features, die in der Praxis zählen

Zwei Kubernetes-Releases haben den Betrieb von Clustern in den vergangenen Monaten spürbar verändert, auch wenn die meisten Release-Notes das nicht hergeben: 1.32 („Penelope“, Dezember 2024) und 1.33 („Octarine“, April 2025). Beide sind inzwischen in vielen Umgebungen angekommen oder stehen auf dem Upgrade-Plan. Der Rückblick sortiert, welche Features für kleine und mittlere Cluster wirklich zählen, und welche Ankündigungen wir für Rauschen halten.

1.32: Stabilität in den Details

Kubernetes 1.32 erschien am 11. Dezember 2024 mit insgesamt 44 Enhancements, davon 13 neu stabil. Auf den ersten Blick eine unauffällige Version, in der Praxis brachte sie mehrere Dinge, die den Alltagsbetrieb erleichtern:

• Structured Authorization Configuration ist stabil: Am API-Server lassen sich jetzt mehrere Authorizer sauber konfigurieren, inklusive CEL-Bedingungen für Webhooks. Wer eigene Autorisierungslogik betreibt, hat damit eine echte Alternative zu einem einzelnen konfigurierten Webhook.

• StatefulSets können von ihnen erstellte PVCs automatisch aufräumen. Das klingt klein, eliminiert aber eine der häufigsten Lieferanten für verwaiste Volumes in kleinen Clustern, und damit echte Kosten.

• Der Scheduler nutzt jetzt durchgehend per-plugin Callbacks (QueueingHints) für Retry-Entscheidungen. Das verbessert den Durchsatz, weil unnötige erneute Scheduling-Versuche entfallen. In kleinen Clustern spürt man das selten, in größeren schon.

• DRA (Dynamic Resource Allocation) hat mit der strukturierten Parameterunterstützung einen Beta-Schritt gemacht. Für GPU- und Spezialhardware-Szenarien ist das die Richtung, aber es bleibt Beta: Produktionsplanung darauf aufbauen, wäre voreilig.

• Am Node-Side wurde der systemd-Watchdog für den Kubelet-Restart verfeinert und die Fehlermeldungen bei Image-Pull-Problemen wurden deutlich aussagekräftiger. Ersteres erhöht die Selbstheilung, letzteres verkürzt Diagnosezeiten. Beides honoriert man erst, wenn man es vermisst.

• Der Memory Manager ist stabil. Wer NUMA-sensible Workloads auf Multi-Socket-Maschinen fährt, bekommt damit ein verlässliches Werkzeug für Memory-Zuordnung; im Standard-Cluster bleibt das ein Randthema, im Spezialfall ein wichtiger.

• Auch die Bound-Service-Account-Token-Verbesserungen (Node-Name in den Token-Claims) und die Custom-Resource-Field-Selectors sind stabil. Beide sind eher für Plattform- und Werkzeugbauern relevant als für Betreiber kleiner Cluster, zeigen aber die Richtung: mehr Prüfbarkeit und weniger Spezial-APIs.

Wichtig für die Planung: Die Sidecar-Container, die seit einiger Zeit als Beta laufen, waren in 1.32 bereits als Ziel für die Stabilisierung in 1.33 angekündigt. Wer darauf gewartet hat, richtig gewartet.

1.33: Sidecars und das Ende der Restarts für Resizing

Kubernetes 1.33 erschien am 23. April 2025 nach einem 15-wöchigen Release-Zyklus mit 64 Enhancements, davon 18 stabil. Zwei davon sind für den praktischen Betrieb die Headline:

• Sidecar-Container sind stabil. Init-Container mit restartPolicy: Always sind damit ein tragfähiges Muster für Log-Shipping, Service-Mesh-Proxies und Secrets-Sync. Der praktische Gewinn: Sidecars starten vor den eigentlichen Containern und enden erst, wenn diese beendet sind. Wer bisher mit Init-Tricks oder postStart-Workarounds gearbeitet hat, kann das vereinfachen.

• In-Place Pod Resize ist Beta und standardmäßig aktiviert. Die Funktion (als Alpha seit 1.27 in Entwicklung) erlaubt es, CPU- und Memory-Limits laufender Pods zu ändern, ohne den Pod neu zu erstellen. Für Stateful-Workloads und alles, was lästig neu startet, ist das ein echter Operationssieg. Die Grenzen im Blick behalten: Die Ressourcen müssen am Node tatsächlich verfügbar sein, und Requests lassen sich nicht in jede Richtung frei verschieben.

Was wir als Rauschen einstufen

Ehrlich gesagt: Der Großteil der Release-Hype-Zeilen betrifft kleine Cluster nicht. Alpha-Features wie Teile des DRA-Stacks, neue API-Erweiterungen oder Observability-Feinschliff sind interessant zu lesen, ändern aber den Betrieb erst Monate später, wenn sie stabil sind. Die Frage, die wir an jede Neuerung stellen, ist deshalb nicht „was kann es“, sondern „wann ist es stabil, und welcher konkrete Betriebsaufwand sinkt dadurch“. Wenn keine überzeugende Antwort darauf folgt, ist die Funktion für unsere Umgebungen erst einmal irrelevant, egal wie gut die Vorstellung auf der Konferenz klingt. Unsere Haltung ist unverändert: Ein Release-Upgrade rechtfertigt sich über Stabilitäts- und Sicherheitsgewinne, nicht über Alpha-Features in den Release-Notes.

Upgrade-Empfehlung aus der Praxis

Für selbst betriebene Cluster gilt der bewährte Rhythmus: ein Minor-Schritt pro Upgrade, kontrolliert, mit Backup und Rollback-Plan, und dazwischen genug Zeit, um die eigenen Workloads unter der neuen Version zu beobachten. Wer von 1.31 kommt, fährt also erst 1.32, dann 1.33. Reihenfolge und Skew zwischen Control-Plane und Worker-Nodes gehören ins Upgrade-Protokoll, genauso wie ein Blick in die Deprecation-Listen vor dem Sprung: Was in 1.32 nur gewarnt wurde, verschwindet irgendwann ganz, und ein Minor-Upgrade ist der richtige Moment, um Konfigurationen aufzuräumen, statt sie mitzuschleppen. In unseren Betriebsprojekten hat sich bewährt, die Upgrade-Fenster als Wiederholungsprozedur zu behandeln: dieselbe Checkliste, dasselbe Backup-Verfahren, derselbe Beobachtungszeitraum. Damit wird aus zwei Releases kein zweimal Ad-hoc-Projekt, sondern ein wiederholbarer Prozess.

Die Stabilisierungen aus beiden Releases sind genau die, die day-2-Operationen leichter machen, und deshalb lohnt der Weg, auch wenn keine einzelne Funktion ein „Must-Have“ im Marketing-Sinne ist.

Wie man Cluster und andere Infrastruktur sauber aufsetzt, ohne dass der Betrieb zum Zufallsprodukt wird, beschreiben wir laufend im Blog. Wer den Betrieb lieber abgeben möchte, findet auf unserer Service-Support-Seite die Beschreibung, wie wir Kubernetes und Umgebung als betreutes Umfeld anbieten.

Quellen

• Kubernetes: „Kubernetes v1.32: Penelope“, 11.12.2024, https://kubernetes.io/blog/2024/12/11/kubernetes-v1-32-release/ (abgerufen 2026-11-01)

• Kubernetes: „Kubernetes v1.33: Octarine“, 23.04.2025, https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/ (abgerufen 2026-11-01)

• Kubernetes: „In-Place Pod Resize Graduated to Beta“, 16.05.2025, https://kubernetes.io/blog/2025/05/16/kubernetes-v1-33-in-place-pod-resize-beta/ (abgerufen 2026-11-01)