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 viamemory.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 and deprecation warnings before upgrading production clusters.