Kubernetes 1.36 arrives: User Namespaces stable, IPVS gone, Ingress‑NGINX retired

5 min read

Kubernetes 1.36 drops on April 22, 2026, with around 80 enhancements and several changes that will keep operations teams busy in the weeks ahead. User Namespaces reach stable, IPVS mode is removed from kube-proxy, the gitRepo volume plugin is gone. On top of that, the externalIPs field is now throwing deprecation warnings. Teams that don’t update their cluster roadmap today are building toward a wall by v1.43.

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

What Actually Changed in Kubernetes 1.36

The numbers at a glance: 80 enhancements in this release, 18 graduating to stable, 18 to beta, and 26 brand-new alpha features. After several release cycles dominated by AI-focused additions (AI-Optimized Scheduling in 1.35), v1.36 returns to platform fundamentals. User Namespaces are the headline: pods can now run in production with their own user ID range isolated from the host, shrinking the classic container escape surface. For security-sensitive workloads in regulated environments, this was the most frequently cited missing feature for two years.

OCI Volumes (Stable) allow OCI artifacts to be mounted directly as read-only volumes in pods without a dedicated init container. HPA Scale-to-Zero moves to Beta, opening the door to permanently dormant deployments that only scale up on demand. For serverless-style patterns inside traditional Kubernetes clusters, this is a concrete lever worth pulling.

The removals matter just as much. gitRepo volumes are definitively gone after repeated security audits documented supply chain risks. IPVS mode in kube-proxy was deprecated in v1.35 and is now fully removed, making iptables-based proxy configuration the default. externalIPs fields in Service objects now emit deprecation warnings and will disappear entirely in v1.43. Anyone still using externalIPs in their manifests needs to migrate to LoadBalancer or Ingress before then.

Why this matters for DACH teams right now

The operational impact lies less in the new features than in the breaking changes. German enterprise clusters with multi-year evolution frequently carry legacy configurations that survived 1.35 but will break under 1.36. IPVS was the default setting for many teams because its performance advantages at high service counts were well-documented. Its removal forces a review of connection-tracking limits and capacity planning in iptables setups.

The Ingress-NGINX situation is even more pressing. SIG Security officially deprecated the controller on 24 March 2026 because maintainer capacity for the required security reviews was no longer available. Across DACH installations, Ingress-NGINX is by far the most common choice for cluster ingress. The migration path to Gateway API or alternative controllers such as HAProxy, Contour or Traefik is non-trivial. SIG recommends an inventory within 60 days, as new CVEs in Ingress-NGINX will no longer be patched.

At the same time, the graduation of User Namespaces opens a door that German security teams have wanted open for years. Regulated industries — financial services, healthcare, critical infrastructure — now have a platform-native way to harden container isolation without falling back on external projects like gVisor or Kata Containers. For NIS2 audits, this will become a talking point in security reviews over the coming months.

Assessment for cloud architects

This release is less feature-driven than its predecessors, but it brings more work per cluster. Managed Kubernetes providers — EKS, AKS, GKE, IONOS Managed Kubernetes, STACKIT — will roll out 1.36 support over the next four to eight weeks. Self-managed operators have had release day since 22 April. Teams running mid-sized clusters should upgrade at least one staging cluster to 1.36, run manifest scans against the three breaking changes, and in parallel draft a plan for the Ingress-NGINX migration.

Strategically, the most significant item is the Ingress-NGINX exit. Anyone without a roadmap should decide within the next two weeks: stay put with an in-house security-patching commitment, migrate to Gateway API with a different implementation, or switch to a commercial ingress controller with a support contract. The decision has consequences for resource planning and security governance well into Q3 2026.

In practical terms, many teams will need to free up a sprint or two on the planning board. Those who have already experimented with Gateway API are halfway there. Anyone who has never rehearsed an ingress-rules migration should schedule a tabletop walkthrough with SRE and the network team no later than the end of May.

Frequently Asked Questions

Is upgrading to Kubernetes 1.36 strictly necessary?

Kubernetes 1.33 (February 2025) is the first release to receive just one more month of support. From May 2026, Kubernetes 1.34 becomes the oldest supported version. Anyone still running 1.32 or earlier is already out of support. Upgrading to 1.36 isn’t an immediate hard requirement, but skip-to-next-LTS is not a pattern that works well with Kubernetes.

What is a good migration path away from Ingress-NGINX?

SIG Security recommends Gateway API paired with an actively maintained implementation. Realistic candidates include Contour, Traefik, HAProxy, or the commercial offerings from NGINX Inc. and F5. This is not a one-sprint project: Gateway API uses different resource types and all rewrite rules need to be migrated. Teams should budget between four and twelve weeks depending on cluster size.

Should I enable User Namespaces in production right now?

For security-sensitive workloads, yes — but incrementally. The feature gate is stable, though platform maturity in production scenarios warrants another one to two quarters of observation. Running staging tests under representative load is the recommended first step before switching over critical workloads.

More from the MBF Media Network

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