Kubernetes 1.36: GA Features, Removals, and What to Know

Kubernetes 1.36 arrives on April 22, 2026 — eight days away. If you manage production clusters, two hard breaking changes demand attention before your managed service auto-upgrades. The release also advances three features to stable status and introduces 20 new alpha capabilities for platform engineers to evaluate early.

The gitRepo volume plugin disappears permanently, and ingress-nginx — still running in a large share of production clusters — has been unsupported since March 24, 2026. Here is exactly what changes, what breaks, and what to do before April 22.

What Goes Stable (GA) in Kubernetes 1.36?

Three features graduate to General Availability in this release, each removing long-standing operational friction.

MutatingAdmissionPolicy reaches v1 after entering beta in Kubernetes 1.34. It replaces the need for a separate webhook server — TLS certificates, deployment manifests, availability requirements — with declarative mutation rules written in Common Expression Language (CEL). You define a MutatingAdmissionPolicy object, the API server evaluates it inline, and nothing extra runs in your cluster. Fewer components to maintain per admission rule, faster request processing.

OCI VolumeSource is now stable. Teams can push LLM model weights, binary datasets, or static assets as independent OCI images and mount them as pod volumes — no different from a ConfigMap. This separates data from application logic at the image layer, directly useful for AI inference workloads where model weights change independently of the serving code.

User Namespaces for Pods graduates to GA. A process holding root privileges inside a pod maps to an unprivileged UID on the host node. Container escapes that previously implied full node compromise now hit a hard privilege boundary. For platform teams running multi-tenant clusters, this is a meaningful uplift — more on the broader implications in Hubkub’s Security coverage.

Which Beta Features Are Now Enabled by Default?

Two Dynamic Resource Allocation (DRA) features promote to beta in 1.36, meaning they activate automatically in new clusters without any feature flag.

• DRA taints and tolerations — applies the familiar taint/toleration model to hardware devices, not just nodes. A GPU reporting a firmware fault can be tainted to block scheduling until the issue is resolved.
• DRA partitionable devices — a single GPU or hardware accelerator splits into multiple logical units shareable across workloads. For teams paying per-GPU in cloud environments, this reduces underutilization on accelerated nodes and lowers per-workload cost.

What Are the 20 New Alpha Features Targeting?

Kubernetes 1.36 ships 20 new alpha features — all disabled by default, unsupported for production — across three focus areas: workload performance, API scalability, and efficient resource use.

Key highlights for Dev/IT Ops teams evaluating them in staging environments:

• Workload-aware preemption: Related pods are treated as a group when the scheduler must evict. This prevents partial teardowns that leave distributed jobs in broken states — a common pain point for batch and ML workloads.
• Topology-aware workload scheduling: Co-locate pod groups within a topological domain defined by a common label. Useful for latency-sensitive distributed workloads that require physical proximity across failure zones.
• External token signing: Pluggable external components for token lifecycle management, giving platform teams finer control over credential issuance and rotation policies.

Which Breaking Changes Could Affect Your Cluster?

Two removals in 1.36 require pre-upgrade action. Treat this upgrade as architectural rebaselining, not a routine patch.

gitRepo volume plugin — permanently removed. Deprecated since Kubernetes 1.11 in 2018, this plugin cloned external repositories directly into pod volumes with root-level host access. Starting with 1.36, it cannot be re-enabled by any feature flag. Any pod spec that references a gitRepo volume will fail to schedule. Audit before upgrading:

kubectl get pods -A -o json | jq '.items[] | select(.spec.volumes[]?.gitRepo != null) | .metadata.name'

Replace affected specs with an init container using a standard git image. The official Kubernetes volume documentation covers the migration pattern in detail.

ingress-nginx end-of-life. SIG Network retired ingress-nginx on March 24, 2026. Existing installations keep running, but no security patches follow. Ingress sits directly on the request path — it handles TLS termination, routing, and external exposure. An unpatched ingress controller is an expanding attack surface. The recommended path is migration to the Kubernetes Gateway API, which is a superset of Ingress functionality with an active maintainer community.

Common Questions — Kubernetes 1.36

Q: When does Kubernetes 1.36 officially release?

A: Kubernetes 1.36 is scheduled for Wednesday, April 22, 2026. It is the second of four releases in the 2026 Kubernetes release cycle. Managed services like Amazon EKS, Google GKE, and Azure AKS typically follow the upstream release within a few weeks.

Q: What features reach General Availability in Kubernetes 1.36?

A: Three features graduate to GA: MutatingAdmissionPolicy (declarative CEL-based mutation policies with no webhook server required), OCI VolumeSource (mount OCI images as pod volumes for clean data/code separation), and User Namespaces for Pods (maps container root to unprivileged host UIDs for stronger isolation).

Q: Will ingress-nginx deployments stop working after upgrading to 1.36?

A: No — existing ingress-nginx installations continue running. But the project reached end-of-life on March 24, 2026, with no further security patches. As Kubernetes evolves, compatibility will eventually break. Teams should plan migration to the Gateway API or another actively maintained ingress controller before vulnerabilities accumulate.

Q: How do I check if my cluster uses the gitRepo volume plugin before upgrading?

A: Run a JSON query against all pod specs before upgrading. Any pod name returned by that query uses the gitRepo volume and will fail to schedule on Kubernetes 1.36. Replace those volumes with init containers using a standard git image before proceeding with the upgrade.

Conclusion

Kubernetes 1.36 is a stability release that demands pre-upgrade discipline. MutatingAdmissionPolicy, OCI VolumeSource, and User Namespaces GA are production-ready wins worth enabling immediately. The permanent gitRepo removal and ingress-nginx retirement are non-negotiable action items before April 22. Audit your workloads now, plan your ingress migration, and evaluate DRA beta features if your nodes run GPU-accelerated workloads.

Explore more in our Dev/IT Ops section.

Last Updated: April 14, 2026