5 Min. Lesezeit

Kubernetes 1.36 kommt am 22. April 2026 raus, mit rund 80 Enhancements und einigen Änderungen, die Operations-Teams in den kommenden Wochen konkret beschäftigen werden. User Namespaces werden stabil, IPVS-Mode verschwindet aus kube-proxy, das gitRepo-Volume-Plugin ist weg. Parallel wirft der externalIPs-Feld Deprecation-Warnings. Wer jetzt nicht seine Cluster-Roadmap aktualisiert, baut für v1.43 gegen eine Wand.

VerwandtFinOps im Maturity-Check 2026  /  Opus 4.7 vs GPT-5.4: EU-Cloud-Inference 2026

Was ist bei Kubernetes 1.36 tatsächlich passiert

Die Zahlen im Überblick: 80 Enhancements im Release, 18 davon graduieren auf stable, 18 auf beta, 26 sind neue alpha-Features. Nach mehreren Release-Zyklen mit KI-fokussierten Ergänzungen (AI-Optimized Scheduling in 1.35) rückt 1.36 zurück auf Plattform-Grundlagen. User Namespaces sind der Kopfpunkt: Pods können jetzt produktiv mit einer eigenen User-ID-Range gegenüber dem Host laufen, was die klassische Container-Escape-Fläche verkleinert. Für security-sensitive Workloads in regulierten Umgebungen war das zwei Jahre lang das am häufigsten genannte fehlende Feature.

OCI Volumes (Stable) erlauben es, OCI-Artefakte direkt als Read-only-Volume in Pods zu mounten, ohne einen eigenen Init-Container. HPA Scale-to-Zero geht in Beta und öffnet den Weg für dauerhaft schlafende Deployments, die nur on-demand hochskaliert werden. Für serverless-ähnliche Muster innerhalb klassischer Kubernetes-Cluster ist das ein konkreter Hebel.

Die Entfernungen sind ebenfalls wichtig. gitRepo-Volumes sind endgültig raus, weil der Security-Audit wiederholt Supply-Chain-Risiken dokumentiert hat. IPVS-Mode im kube-proxy wurde in v1.35 deprecated und ist nun komplett entfernt, was iptables-basierte Proxy-Konfiguration zum Default macht. externalIPs-Fields in Service-Objekten werfen jetzt Deprecation-Warnings und verschwinden endgültig in v1.43. Wer in seinen Manifests noch externalIPs nutzt, muss bis dahin auf LoadBalancer oder Ingress migrieren.

Warum das für DACH-Teams jetzt relevant ist

Die operative Konsequenz liegt weniger bei den neuen Features als bei den Breaking Changes. Deutsche Enterprise-Cluster mit mehrjähriger Evolution haben oft historische Konfigurationen, die in 1.35 noch mitgingen und in 1.36 kippen. IPVS war bei vielen Teams die Default-Einstellung, weil die Performance-Vorteile bei großen Services-Mengen dokumentiert waren. Der Wegfall zwingt zur Überprüfung der Connection-Tracking-Limits und zur Kapazitätsplanung in iptables-Setups.

Noch deutlicher ist der Ingress-NGINX-Punkt. Die SIG Security hat den Controller am 24. März 2026 offiziell zurückgezogen, weil die Maintainer-Kapazität für die erforderlichen Security-Reviews nicht mehr gegeben war. In DACH-Installationen ist Ingress-NGINX die mit Abstand häufigste Wahl für Cluster-Ingress. Der Migrationspfad auf Gateway API oder alternative Controller wie HAProxy, Contour oder Traefik ist nicht trivial. Die SIG empfiehlt eine Bestandsaufnahme binnen 60 Tagen, weil neue CVEs in Ingress-NGINX nicht mehr gepatcht werden.

Die User-Namespaces-Graduation öffnet gleichzeitig eine Tür, die deutsche Security-Teams seit Jahren offen haben wollten. Regulierte Branchen (Finanzdienstleister, Gesundheit, kritische Infrastruktur) bekommen damit ein Plattform-natives Mittel, um Container-Isolation zu härten, ohne auf externe Projekte wie gVisor oder Kata Containers zurückzugreifen. Für NIS2-Audits wird das in den kommenden Monaten zum Gesprächsthema in Security-Reviews.

Einschätzung für Cloud-Architekten

Das Release ist weniger feature-getrieben als die vorangegangenen, aber es bringt mehr Arbeit pro Cluster mit sich. Managed-Kubernetes-Anbieter (EKS, AKS, GKE, IONOS Managed Kubernetes, STACKIT) werden die 1.36-Unterstützung über die nächsten vier bis acht Wochen ausrollen. Wer selbst betreibt, hat den Release-Day ab 22. April. Teams mit mittlerer Cluster-Größe sollten mindestens ein Staging-Cluster auf 1.36 hochziehen, die Manifest-Scans auf die drei Breaking Changes laufen lassen und parallel einen Plan für die Ingress-NGINX-Migration erstellen.

Der strategisch wichtigste Punkt ist der Ingress-NGINX-Exit. Wer dort noch keine Roadmap hat, sollte in den nächsten zwei Wochen entscheiden: bleiben mit eigenem Security-Patching-Commitment, Migration auf Gateway API mit einem anderen Implementierer, oder Wechsel auf einen kommerziellen Ingress-Controller mit Support-Vertrag. Die Entscheidung hat Konsequenzen für Ressourcenplanung und Security-Governance bis ins Q3 2026 hinein.

Praktisch heißt das für viele Teams, einen Sprint oder zwei in der Planungstafel freizuschalten. Wer bereits mit Gateway API experimentiert hat, hat den halben Weg hinter sich. Wer noch nie eine Migration der Ingress-Regeln durchgespielt hat, sollte spätestens Ende Mai einen Tabletop-Walkthrough mit SRE und Netzwerk-Team ansetzen.

Häufige Fragen

Ist das Upgrade auf Kubernetes 1.36 zwingend notwendig?

Kubernetes 1.33 (Februar 2025) ist das erste Release, das noch einen Monat Support erhält. Ab Mai 2026 gilt Kubernetes 1.34 als älteste supported Version. Wer 1.32 oder älter fährt, hat keinen Support mehr. Das Upgrade auf 1.36 ist nicht zwingend sofort, aber der Skip-to-Next-LTS ist bei Kubernetes kein Muster, das gut funktioniert.

Was ist ein guter Migrationspfad weg von Ingress-NGINX?

Die SIG Security empfiehlt Gateway API mit einem aktiv gewarteten Implementierer. Realistische Kandidaten sind Contour, Traefik, HAProxy oder die kommerziellen Varianten von NGINX Inc. und F5. Die Migration ist kein Ein-Sprint-Projekt, weil Gateway API andere Ressourcen-Typen nutzt und die Rewrite-Regeln migriert werden müssen. Einplanen sollten Teams zwischen vier und zwölf Wochen, je nach Cluster-Größe.

Sollte ich User Namespaces direkt produktiv nutzen?

Für security-sensitive Workloads ja, aber schrittweise. Der Feature-Gate ist stable, die Plattform-Reife in produktiven Szenarien braucht aber noch ein bis zwei Quartale Beobachtung. Staging-Tests mit repräsentativer Last sind der empfohlene erste Schritt, bevor kritische Workloads umgeschaltet werden.

Mehr aus dem MBF Media Netzwerk

Quelle Titelbild: Pexels / Wolfgang Weiser (px:33512156)