# Kubernetes v1.36 Released: User Namespaces Go GA, Workload Scheduling Gets Smarter

- Link: https://thestackobserver.com/kubernetes-v1-36-released-user-namespaces-go-ga-workload-scheduling-gets-smarter/
- Published: 2026-05-01T08:11:51-04:00
- Author: Stackxx

Kubernetes v1.36, codenamed **ハル (Haru)** — meaning “spring” or “clear skies” 
in Japanese — has arrived with 70 enhancements, marking one of the most substantial
releases in recent cycles. Released in late April 2026, this version brings 18 features
to General Availability, 25 to Beta, and introduces 25 new Alpha capabilities. But
beyond the numbers, v1.36 represents something more significant: a maturation of
Kubernetes’ security posture, scheduling intelligence, and operational resilience.

## User Namespaces Finally Reach GA: The Rootless Revolution

After six years of development spanning multiple alpha and beta cycles, **User Namespaces
support has graduated to General Availability** — arguably the most impactful security
improvement in this release. This Linux-only feature fundamentally changes how Kubernetes
handles privilege isolation.

The core problem User Namespaces solve is deceptively simple but critically important:
historically, a process running as root inside a container was also root on the 
host kernel. If an attacker broke out through a kernel vulnerability or misconfigured
mount, they gained root access to the underlying node. User Namespaces change this
by remapping container UIDs to non-privileged ranges on the host.

The key technical enabler was **ID-mapped mounts**, introduced in Linux 5.12. Previously,
enabling User Namespaces required the Kubelet to recursively chown every file in
attached volumes — an O(n) operation that destroyed startup performance for large
datasets. ID-mapped mounts perform this translation at mount time, making it an 
O(1) operation where the kernel transparently remaps UIDs without changing on-disk
ownership.

Using it requires only setting `hostUsers: false` in the Pod spec. Critically, this
enables new patterns like running workloads with `CAP_NET_ADMIN` privileges that
are namespaced — granting container-local administrative power without host exposure.
This bridges the gap between security requirements and operational flexibility that
previously forced teams to choose between over-privileged containers or broken applications.

## Memory QoS Tiered Protection: Smarter Resource Guarantees

Kubernetes v1.36 introduces significant refinements to the Memory QoS feature, adding**
opt-in memory reservation with tiered protection by QoS class**. This alpha feature
uses cgroup v2’s memory controller to provide more nuanced memory management than
the traditional hard limits.

The new `memoryReservationPolicy` configuration separates throttling from reservation:

 * **TieredReservation mode:** Guaranteed Pods receive hard protection via `memory.
   min` — memory the kernel will never reclaim. Burstable Pods get soft protection
   via `memory.low` — memory protected under normal pressure but reclaimable during
   extreme scenarios. BestEffort Pods receive no protection.
 * `None` (default): Only memory.high throttling is active, without reservation 
   guarantees.

This tiered approach solves a real operational problem. In earlier implementations,
enabling Memory QoS immediately set `memory.min` for every container with a memory
request. On an 8 GiB node with Burstable Pods requesting 7 GiB total, nearly all
memory became hard-reserved, leaving insufficient headroom for system daemons and
increasing OOM risk. The v1.36 model keeps hard reservation lower by mapping only
Guaranteed Pods to `memory.min`, while Burstable workloads use the more flexible`
memory.low`.

New observability metrics — `kubelet_memory_qos_node_memory_min_bytes` and `kubelet_memory_qos_node_memory_low_bytes`—
enable capacity planning by exposing total reserved memory per QoS class.

## Workload Aware Scheduling: Treating Pods as Logical Groups

One of the most ambitious additions in v1.36 is the **Workload Aware Scheduling (
WAS)** feature suite, introducing alpha-level support for treating related Pods 
as single logical entities rather than independent scheduling units.

Building on the gang scheduling foundation from v1.35 — which required a minimum
number of Pods to be schedulable before binding any — v1.36 adds a new PodGroup 
scheduling cycle that evaluates groups atomically. Either all Pods in a group bind
together, or none do. This is crucial for distributed workloads like MPI jobs, machine
learning training, or distributed databases where partial scheduling creates stranded
resources and failed runs.

The implementation spans multiple KEPs (4671, 5547, 5832, 5732, and 5710) and involves:

 * A revised Workload API integrating the Job controller
 * A new decoupled PodGroup API
 * Workload-aware preemption that treats PodGroups as single entities for both scheduling
   and eviction decisions

This represents a fundamental shift in Kubernetes’ scheduling philosophy — from 
individual Pod optimization to workload-level resource management.

## Gateway API v1.5: Six Features Graduate to Standard

While technically a separate project, Gateway API v1.5 released in February 2026
brings six major features to the Standard (GA) channel — the project’s biggest release
yet:

 * **ListenerSet:** Allows defining listeners independently and merging them onto
   Gateways, enabling delegation between platform and application teams. Critical
   for large-scale deployments, it supports attaching more than 64 listeners to 
   a single Gateway.
 * **TLSRoute:** Routes requests by SNI during TLS handshake, supporting both Passthrough
   and Terminate modes.
 * **HTTPRoute CORS Filter:** Native CORS handling without backend configuration.
 * **Client Certificate Validation:** Backend mTLS support for service-to-service
   authentication.
 * **Certificate Selection for Gateway TLS Origination:** Dynamic certificate selection
   based on client SNI.
 * **ReferenceGrant:** Cross-namespace resource references with explicit permission
   grants.

Gateway API has also moved to a release train model, shipping features when ready
rather than on fixed dates — aligning with Kubernetes’ own proven release cadence.

## Additional Graduations: Fine-Grained Auth and Resource Health

**Fine-grained Kubelet API authorization** (KEP-2862) graduates to GA, enabling 
least-privilege access control over the Kubelet’s HTTPS API. Previously, monitoring
and observability use cases required the overly broad `nodes/proxy` permission. 
The new model allows precise permissions for specific endpoints, reducing blast 
radius from compromised credentials.

**Resource health status** moves to Beta, building on the Device Plugin framework
to provide unified health reporting for specialized hardware. The `allocatedResourcesStatus`
field in Pod status now exposes whether allocated devices are healthy, unhealthy,
or unknown — visible via `kubectl describe pod`. This addresses a long-standing 
operational pain point where hardware failures caused cryptic Pod crashes with no
clear root cause.

**Volume group snapshots** also reach GA, enabling crash-consistent snapshots across
multiple PersistentVolumeClaims simultaneously — critical for stateful applications
spanning multiple volumes.

## The AI Security Angle: Sandboxing Meets Kubernetes

Coinciding with the v1.36 release cycle, the CNCF published thought leadership on
AI sandboxing that contextualizes Kubernetes’ evolving security model. As AI labs
deploy autonomous agents capable of discovering zero-day vulnerabilities — Anthropic’s
Mythos model recently found and exploited vulnerabilities including a 27-year-old
bug — the infrastructure layer’s security guarantees become paramount.

The User Namespaces GA in v1.36 directly addresses this threat model. When AI agents
run in Kubernetes workloads that might legitimately need elevated privileges for
package installation, file writes, or network calls, User Namespaces provide structural
isolation where policy-based controls fail. A compromised workload with namespaced
root cannot escape to host root — the capability is confined to the namespace boundary.

This represents a shift from “prevent every breach” to “contain every breach” — 
mirroring how Kubernetes handles pod failures as expected events rather than catastrophes.
The architectural principle is sound: shared kernels create single points of failure,
while distributed isolation limits blast radius.

## Upgrading and Getting Started

Kubernetes v1.36 is available now through cloud provider managed services (EKS, 
AKS, GKE) and self-managed installations. Key prerequisites for new features:

 * **User Namespaces:** Linux kernel 5.12+ (for ID-mapped mounts), containerd 1.6
   + or CRI-O 1.22+
 * **Memory QoS:** cgroup v2 enabled, kernel 5.9+ recommended
 * **WAS features:** Enable relevant feature gates on kube-apiserver and kube-scheduler

As always, review the [full release notes](https://kubernetes.io/docs/setup/release/notes/)
and deprecation warnings before upgrading production clusters.

## Sources

 * [Kubernetes v1.36: ハル (Haru) — Official Release Blog](https://kubernetes.io/blog/2026/04/22/kubernetes-v1-36-release/)
 * [User Namespaces in Kubernetes are finally GA](https://kubernetes.io/blog/2026/04/23/kubernetes-v1-36-userns-ga/)
 * [Tiered Memory Protection with Memory QoS](https://kubernetes.io/blog/2026/04/29/kubernetes-v1-36-memory-qos-tiered-protection/)
 * [Gateway API v1.5: Moving features to Stable](https://kubernetes.io/blog/2026/04/21/gateway-api-v1-5/)
 * [AI sandboxing is having its Kubernetes moment (CNCF)](https://www.cncf.io/blog/2026/04/30/ai-sandboxing-is-having-its-kubernetes-moment/)