Kubernetes 1.36 "Haru": User Namespaces Go GA, Ingress NGINX Retired and a Security Hardening Push

Kubernetes 1.36, codenamed "Haru", is the first major release of 2026 — and it sends a clear signal: security by default is getting tougher. On the menu, 70 changes (18 graduating to stable, 25 to beta, 25 new in alpha), built around three themes: security hardening, support for AI/ML workloads, and API scalability at large scale.

But beyond the new features, "Haru" mainly brings removals that will break deployments if you don't plan ahead. Here's an overview of what's changing, and above all what you need to check before you upgrade.

The big security item: User Namespaces go GA

The most important graduation in this release, awaited for several cycles: User Namespaces move to general availability (GA).

The idea is powerful in its simplicity: the feature maps a container's root user to an unprivileged user on the host. The direct consequence: a process that escapes a container (through a runtime flaw, a kernel bug, or a misconfiguration) does not gain administrator rights on the underlying node. That's a massive reduction in the blast radius of a container escape — exactly the kind of defense in depth people have been asking for over many years.

Two other security graduations come along for the ride:

• Mutating Admission Policies (GA) — mutate objects at admission time using CEL, with no external webhook to maintain.
• Fine-Grained Kubelet API Authorization (GA) — far more granular access control over the kubelet API, which has historically been a weak spot.

Taken together, these three GA promotions push Kubernetes toward a secure-by-default model that moves closer to the principles of a Zero Trust architecture.

Resource management: pods resize on the fly

On the operations side, two notable advances move to beta:

• In-Place Vertical Scaling for pod-level resources (beta, enabled by default): you can resize a pod's CPU/memory envelope without restarting its containers. No more rolling restarts just to adjust a memory limit. A new ResizeDeferred event is introduced: if the node lacks immediate capacity, the pod keeps running at its current size and the kubelet retries the resize as soon as capacity frees up.
• Memory QoS via cgroup v2 (beta): multi-tier memory protection that finally aligns kernel controls with pods' requests and limits, reducing contention between workloads sharing a node.

Memory QoS builds directly on cgroup v2 and the Linux kernel's PSI (Pressure Stall Information) — a signal available since 2018 that lets you spot resource saturation before it turns into an outage.

⚠️ What breaks: the removals to plan for

This is where you need to pay attention. "Haru" removes elements that have been deprecated for a long time:

The gitRepo volume plugin is removed (for good)

Deprecated since v1.11, the gitRepo volume plugin is now gone for good. And this isn't just a matter of hygiene: this plugin allowed an attacker to execute code as root on a node. If you still use it, migrate to init containers or an external git-sync tool before upgrading, or your pods will refuse to start.

Ingress NGINX is over

A major networking change: the Ingress NGINX project has been retired by Kubernetes' SIG Network and Security Response Committee on March 24, 2026. As of that date: no more releases, no more bug fixes, no more security patches.

That carries heavy consequences, because Ingress NGINX is one of the most widely deployed ingress controllers in the world. Continuing to use it means exposing the front door of your cluster to vulnerabilities that will never be fixed. Migration paths: Gateway API (the official successor), or an actively maintained controller (Envoy Gateway, Traefik, HAProxy, or managed cloud solutions).

Recommended migration plan

Upgrading to 1.36 deserves a checklist:

1. Inventory the deprecations. Search for gitRepo in your manifests, and identify every Ingress that relies on ingress-nginx.

   # Find gitRepo volumes
   kubectl get pods -A -o json | grep -i gitRepo
   
   # Find the ingress-nginx class
   kubectl get ingress -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,CLASS:.spec.ingressClassName

2. Migrate Ingress NGINX to Gateway API or a maintained controller — on a staging cluster first.
3. Test User Namespaces. Enable them gradually: not all workloads are compatible (mounts, specific capabilities). Validate in pre-prod.
4. Check cgroup v2. Memory QoS assumes nodes running cgroup v2 — verify your node OSes.
5. Upgrade one version at a time. Don't skip versions; respect the supported version skew between the control plane and the kubelets.

For managing secrets in your manifests (and avoiding committing them), our secrets management guide (Vault, External Secrets) is still relevant. And for runtime detection of the container escapes that User Namespaces aim to neutralize, see our article on eBPF, Falco and Cilium.

Building on 1.35

"Haru" extends the trajectory set by the previous release. If you followed our analysis of Kubernetes 1.35 and its Dynamic Resource Allocation for GPUs, you'll recognize the recurring theme: Kubernetes is bulking up on two fronts at once, support for AI workloads (fine-grained accelerator allocation) and security hardening (isolation, least privilege, granular access control).

Conclusion

Kubernetes 1.36 "Haru" is a release about maturity: fewer fireworks, more solid foundations. User Namespaces going GA is a win for anyone who takes container security seriously, and on-the-fly resizing will make life easier for ops teams.

But the real message of this version is in its removals: gitRepo and Ingress NGINX are gone, and ignoring these two points will turn your upgrade into an outage. As always with Kubernetes, a version upgrade is prepared up front, on a test cluster, never live in production. The next step, 1.37, is expected on August 26, 2026 — plenty of time to calmly plan your migration window.