Kubernetes 1.36: What's New and What Breaks

Originally published on DevToolHub.

Kubernetes 1.36 shipped on April 22, 2026, and it's a security-and-hardware release more than a feature release. Eighteen enhancements graduated to stable, 25 moved to beta, and the two changes most teams will actually notice are User Namespaces going GA and Mutating Admission Policies replacing a chunk of what you used to need a webhook for.

Amazon EKS and EKS Distro added support for 1.36 on June 2, 2026, so if you're on AWS you can upgrade now. Here's what changed, what's deprecated, and what to check before you touch a production cluster.

What's New in Kubernetes 1.36

The release is codenamed ハル (Haru) — spring, clear skies. Of the 18 features that reached stable, most fall into two buckets: security isolation and Dynamic Resource Allocation (DRA) for GPU and specialized hardware. Here's the short list of what matters operationally.

Security and isolation:

• User Namespaces for pods — stable
• Fine-Grained Kubelet API Authorization — stable
• API for External Signing of Service Account Tokens — stable
• Mutating Admission Policies — stable

Storage and performance:

• Speed up Recursive SELinux Label Change — stable
• VolumeGroupSnapshot — stable
• OCI VolumeSource — stable
• PSI (Pressure Stall Information) support via cgroupv2 — stable

Hardware and DRA:

• Device Taints & Tolerations for DRA — stable
• DRAAdminAccess for ResourceClaims — stable
• Partitionable Devices — stable

That's not the full list of 18, but it's the set with day-to-day impact. The rest are DRA refinements most teams won't touch unless they're running GPU workloads.

User Namespaces and Fine-Grained Kubelet Authorization Reach Stable

User Namespaces is the headline change. It maps the root user inside a container to an unprivileged user on the host node. So a process that thinks it's root inside the container has no elevated privileges outside it. This has been in alpha or beta since 1.25 — it's now safe to turn on by default for new workloads without waiting on more bug fixes.

Fine-Grained Kubelet API Authorization is the other stable feature worth checking. Before this, RBAC rules for the kubelet API were coarse — you either had access to the node's endpoints or you didn't. Now you can scope permissions down to specific paths like nodes/configz, nodes/healthz, and nodes/pods individually. If you've been granting broad node-level access to monitoring or debugging tools because there wasn't a narrower option, this changes that. You can tighten your RBAC configuration around exactly what each tool needs.

Mutating Admission Policies Replace Simple Webhooks

This is the change most platform teams will actually use. Mutating Admission Policies let you define mutations — like injecting a sidecar, adding a label, or setting a default resource limit — directly as a Kubernetes object using CEL (Common Expression Language), instead of standing up and maintaining a mutating webhook.

The practical upside: no more running a webhook deployment, managing its TLS certs, and worrying about what happens to admission if that pod goes down. The policy lives in the API server's own admission chain.

⚠️ Note: This doesn't replace every use case for webhooks. Complex mutation logic that needs external API calls or stateful lookups still needs a webhook. Mutating Admission Policies work well for anything you can express as a CEL expression against the object being admitted — sidecar injection, label defaulting, resource limit defaults.

What's Moving to Beta in Kubernetes 1.36

The 25 beta graduations are a mixed bag, but a few change daily workflows:

• In-Place Pod-Level Resources Vertical Scaling — beta. You can now adjust a pod's CPU and memory without restarting it, extended from container-level scaling that landed earlier.
• kuberc — beta, enabled by default. This splits kubectl user preferences (aliases, defaults) from cluster connection config in your kubeconfig. If you've ever had a teammate's personal kubectl aliases accidentally end up in a shared kubeconfig file, this is the fix.
• Constrained Impersonation — beta. Impersonation now requires both impersonate and a new impersonate-on permission, so a user with impersonate rights can't impersonate into arbitrary identities without an explicit grant.
• Node Declared Features — beta. Nodes now report which feature-gated capabilities they actually support, so the scheduler can filter on it instead of guessing.

None of these are breaking on their own, but kuberc being on by default means your kubeconfig files may start behaving differently the moment you upgrade kubectl to a 1.36-compatible version.

What Kubernetes 1.36 Deprecates and Removes

Two changes here are worth flagging before you upgrade.

.spec.externalIPs on Services is deprecated. It's being phased out over the next several releases, not removed outright in 1.36. The reason is CVE-2020-8554, a known man-in-the-middle risk where arbitrary external IPs can be claimed on a Service. If you're using externalIPs anywhere, the release notes point you toward LoadBalancer services, NodePort, or the Gateway API as replacements.

The gitRepo volume driver is being removed. It's been deprecated since 1.11, so this shouldn't surprise anyone still paying attention, but it will break any manifest that still references it.

Neither of these is new to 1.36 specifically — they're continuations of deprecation timelines that started earlier. What is specific to this window: Ingress NGINX officially retired on March 24, 2026, with no further releases or security patches. If you haven't already moved off it, the migration path to Gateway API is worth doing before you touch your 1.36 upgrade, not during it. Combining two migrations at once makes rollback harder if something goes wrong.

Upgrading to Kubernetes 1.36

If you're running self-managed clusters, this is a standard kubeadm upgrade — check your CNI and CSI driver compatibility matrices first, since 1.36 introduced schema changes for resources and DRA-related CRDs that older third-party controllers may not handle.

If you're on EKS, Amazon added 1.36 support on June 2, 2026, across all AWS regions including GovCloud. You can upgrade through the EKS console, eksctl, or your existing IaC pipeline. AWS specifically recommends running EKS cluster insights before you kick off the upgrade — it flags compatibility issues with deprecated APIs or add-ons ahead of time instead of surfacing them mid-upgrade.

Before you upgrade anything with active traffic, confirm your resource requests and limits are still accurate. Pod-level vertical scaling moving to beta means some autoscalers may start behaving differently once they detect the new API is available.

Frequently Asked Questions

Q: Is Kubernetes 1.36 a breaking release?
A: Not dramatically. The deprecations (externalIPs, gitRepo volumes) are phased, not immediate removals. The bigger operational risk is combining this upgrade with an overdue Ingress NGINX migration — do those separately.

Q: Do I need to enable User Namespaces manually?
A: Yes. It's stable, meaning it's supported and safe to use, but it's not on by default for existing workloads. You opt in per-pod via the pod spec.

Q: When does EKS support Kubernetes 1.36?
A: Since June 2, 2026, across all AWS regions where EKS is available, including GovCloud.

Q: What replaces Ingress NGINX now that it's retired?
A: The Kubernetes project recommends the Gateway API as the long-term replacement, with Envoy Gateway, Istio Gateway, Traefik, and Kong Gateway as common implementations.

Quick Summary:

• Kubernetes 1.36 released April 22, 2026, with 18 features graduating to stable and 25 to beta
• User Namespaces and Mutating Admission Policies are the two changes most teams will use immediately
• Fine-Grained Kubelet API Authorization lets you scope node access down to specific endpoints
• .spec.externalIPs is being phased out over several releases due to CVE-2020-8554
• EKS supports 1.36 as of June 2, 2026 — upgrade via console, eksctl, or IaC

Run kubectl version and check it against your CNI/CSI vendor's 1.36 compatibility notes before you schedule the upgrade — that's the step most teams skip and regret.