Kubernetes 1.36, codenamed Haru (spring, clear skies), shipped on April 22, 2026. With 70 enhancements across the board — 18 graduating to Stable, 25 entering Beta, and 25 debuting in Alpha — this is one of the more feature-packed releases in recent memory. If you run Kubernetes in production, several of these changes will affect how you manage security, resource allocation, and observability going forward. Here’s a practical breakdown of what matters most.
User Namespaces Are Finally GA
This is arguably the biggest security milestone in the release. User Namespaces (KEP-127) allow you to map a container’s root user to an unprivileged user on the host. If a process somehow breaks out of its container, it holds zero administrative power over the node. For multi-tenant clusters and anyone running untrusted workloads, this is a meaningful defense-in-depth layer that doesn’t require application changes.
Enabling it is straightforward — set pod.spec.hostUsers: false to opt into user namespace isolation. The feature has been in beta since v1.33, so most Kubernetes distributions should already support it. If you haven’t tested it yet, now is the time.
Mutating Admission Policies Reach Stable
MutatingAdmissionPolicies (KEP-3962) give you a native, performant way to mutate incoming API requests using CEL expressions — no external webhook infrastructure needed. If you’re currently running admission webhooks to inject labels, set default resource limits, or enforce naming conventions, you can replace many of those with a declarative policy that runs directly in the API server.
Here’s an example that injects a sidecar container into every newly created Pod that doesn’t already have one:
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
name: inject-sidecar
spec:
failurePolicy: Fail
reinvocationPolicy: IfNeeded
matchConstraints:
resourceRules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE"]
resources: ["pods"]
matchConditions:
- name: does-not-have-sidecar
expression: '!object.spec.initContainers.exists(ic, ic.name == "mesh-proxy")'
mutations:
- patchType: "ApplyConfiguration"
applyConfiguration:
expression: >
Object{
spec: Object.spec{
initContainers: [
Object.spec.initContainers{
name: "mesh-proxy",
image: "mesh/proxy:v1.0.0",
args: ["proxy", "sidecar"],
restartPolicy: "Always"
}
]
}
}With this stable, you get long-term API compatibility guarantees — something webhook-based solutions can’t offer. The reduced network hop and eliminated webhook service dependency also means faster admission decisions.
DRA Continues Its March Toward Production Readiness
Dynamic Resource Allocation (DRA) keeps evolving rapidly in v1.36. Several core features graduated to Stable — DRA admin access (KEP-5018) and prioritized alternatives in device requests (KEP-4816) — giving cluster administrators a permanent, secure framework for managing hardware resources globally. Meanwhile, beta-level features like partitionable devices, consumable capacity, device taints and tolerations, and ResourceClaim device status make DRA increasingly practical for GPU-heavy AI workloads and HPC clusters.
On the alpha side, native ResourceClaim support for workloads and DRA-native resources for CPU management signal that DRA is positioning itself as a replacement for the legacy device plugin framework. If your organization runs GPU clusters or has specialized hardware, this is the framework to start investing in.
Volume Group Snapshots Go GA
VolumeGroupSnapshot (KEP-3476) lets you take crash-consistent snapshots across multiple PersistentVolumeClaims simultaneously. This is a game-changer for databases that spread data across multiple volumes — you can now snapshot all related volumes at once and restore them as a consistent set, rather than trying to coordinate individual volume snapshots.
apiVersion: groupsnapshot.storage.k8s.io/v1
kind: VolumeGroupSnapshot
metadata:
name: my-db-consistent-snapshot
spec:
volumeGroupSnapshotClassName: csi-group-snapclass
source:
selector:
matchLabels:
app: my-database
snapshot-group: primaryNote that this requires your CSI driver to support group snapshots. Check your storage provider’s documentation for compatibility.
Deprecations You Need to Act On
Kubernetes 1.36 carries two deprecations that deserve immediate attention:
Service .spec.externalIPs is now deprecated. This field has been a security headache for years, enabling man-in-the-middle attacks (CVE-2020-8554). From v1.36 onward, you’ll see deprecation warnings when using it, with full removal planned for v1.43. Replace externalIPs with LoadBalancer services, NodePort, or Gateway API.
The gitRepo volume driver has been permanently disabled. Deprecated since v1.11, it contained a critical security issue that allowed code execution as root on the node. If you still have workloads using gitRepo, migrate to init containers or git-sync sidecars now.
Other Notable Stable Features
Fine-grained Kubelet API authorization (KEP-2862) — Replaces the overly broad nodes/proxy permission with precise access controls for monitoring and observability tools. Your Prometheus exporters and metrics scrapers should use this instead of blanket proxy access.
Node log query (KEP-2258) — View kubelet and kube-proxy logs via kubectl without SSH-ing into nodes. Enabled through the NodeLogQuery feature gate and enableSystemLogQuery kubelet config option. A small quality-of-life improvement that simplifies debugging in production.
PSI-based metrics (KEP-4205) — The kubelet now exports Pressure Stall Information for CPU, memory, and I/O. Unlike utilization metrics, PSI tells you when workloads are actually stalling — making it far more useful for vertical autoscaling decisions and detecting noisy neighbor effects.
OCI volume sources (KEP-4639) — Mount content directly from OCI registries (container images or artifact repos) as volumes. Useful for distributing configuration files, ML models, or static assets through the same delivery pipeline as your container images.
SELinux volume label changes (KEP-1710) — Mount-time SELinux labeling replaces recursive relabeling, significantly reducing Pod startup times on SELinux-enforcing systems. Defaults to all volumes in v1.36, but be aware this may cause breaking changes in v1.37 if you share volumes between privileged and unprivileged Pods. Audit your clusters now.
What to Watch in Beta
Several beta features are worth tracking for production adoption in upcoming releases:
Staleness mitigation for controllers (KEP-5647) — Helps controllers avoid making decisions based on stale cached data, preventing conflicting updates and data corruption. If you’ve ever debugged mysterious controller behavior during cluster upgrades, this addresses a root cause.
Mutable pod resources for suspended Jobs (KEP-5440) — Allows updating CPU, memory, and GPU requests/limits on suspended Jobs. This enables queue controllers to adjust resource requirements before unsuspending batch workloads — a practical feature for cost-conscious HPC and AI training pipelines.
Memory QoS with tiered protection (KEP-2570) — Smarter memory protection using cgroup v2 that better aligns kernel controls with pod requests and limits, reducing interference between co-located workloads.
Constrained impersonation (KEP-5284) — Prevents impersonation from being used to gain broader access than the impersonator themselves has. A meaningful improvement for clusters where controllers or node agents impersonate service accounts.
Preparing for the Upgrade
Before upgrading to v1.36, run through this checklist:
Audit externalIPs usage: Search your manifests and Helm values for externalIPs and plan migration to LoadBalancer or Gateway API.
Check for gitRepo volumes: Any remaining gitRepo volumes will stop working after upgrade. Replace with init containers.
Review SELinux volume sharing: If you share volumes between Pods with different privilege levels, explicitly set seLinuxChangePolicy to avoid breakage when the default changes in v1.37.
Test User Namespaces: Enable hostUsers: false on non-critical workloads first. Verify that your applications don’t depend on running as a specific UID on the host.
Evaluate MutatingAdmissionPolicies: Identify admission webhooks that perform simple mutations and plan migration to CEL-based policies for better performance and reliability.
Final Thoughts
Kubernetes 1.36 continues the project’s trajectory toward stronger security defaults, better observability, and more native support for complex workloads like AI/ML training. User Namespaces reaching GA is a landmark moment for container isolation. Mutating Admission Policies going stable means you can finally replace many webhooks with declarative, in-process policies. And DRA’s continued maturation signals that Kubernetes is serious about becoming the standard platform for hardware-accelerated workloads.
Full release notes are available on the Kubernetes blog. If you’re running an older release, now is a good time to start planning your upgrade path.