Released: April 22, 2026 | Codename: ハル (Haru) | Enhancements: 70 total — 18 GA, 25 Beta, 25 Alpha
Kubernetes v1.36 is the first major release of 2026, and it lands with a Japanese name that carries three meanings: 春 (spring), 晴れ (clear skies), and 遥か (far-off horizons). Fitting, because this release is less about dramatic new directions and more about making the platform genuinely safer, more operational, and honest about how real workloads behave. Previous release Kubernetes 1.35 brought a lot of new features and enhancements. Kubernetes v1.36 is here to make Kubernetes more stable and secure.
There are around 70 enhancements in this release and it's a big one. Here's what actually matters for teams running Kubernetes in production.
What's new in Kubernetes v1.36: stable (GA) features
These are production-ready. You can rely on them.
User namespaces for pods — finally GA
After years in alpha and beta, user namespaces for pods are now stable in v1.36. You can enable it with hostUsers: false in your pod spec. Without user namespaces, a container running as root maps directly to root on the node — a containment failure can mean full node compromise. With user namespaces enabled natively, containers get their own UID/GID space. A process that's root inside the container is unprivileged on the host. No gVisor, no Kata, no third-party workaround needed.
This is a meaningful security milestone. Kernel and runtime support still matters, so test this in staging before rolling it out everywhere. But "experimental" is no longer a valid reason to avoid it.
Mutating admission policies — GA and enabled by default
Running a mutating admission webhook today means maintaining a TLS-secured HTTP server, managing certificate rotation, worrying about webhook latency, and dealing with failure modes that can cascade into API server problems. That's a lot of infrastructure just to inject default labels or cap resource requests.
Mutating Admission Policies bring CEL-based mutation directly into Kubernetes objects. No external server. No webhook to babysit. Define your mutation logic as native Kubernetes objects, version-control them alongside your other configs in Git, and ship them through your normal GitOps workflow. This is the same model that made Validating Admission Policies popular — now it covers mutations too.
For platform teams running lean, this removes a whole category of operational overhead.
OCI volumes — GA
Getting non-code artifacts into a container has always been awkward. Bloat the main image, use an init container to pull things in, fight ConfigMap size limits, or build custom distribution pipelines. OCI VolumeSource lets you reference any OCI image as a volume. Kubernetes pulls the image and mounts its contents into the pod just like a regular volume.
This matters most for AI/ML workloads. Package model weights, config files, datasets, or binary tools as standalone OCI artifacts and distribute them through your existing image registry, completely independent of your application image. In v1.36 this graduates to stable after progressing from alpha in v1.31.
Fine-grained kubelet API authorization — GA
Previously, anything allowed to reach the kubelet API got broad access. Now, authorization can be scoped to specific kubelet endpoints — /metrics, /healthz, /pods, individual node log endpoints — using standard Kubernetes RBAC. Cluster operators can grant monitoring tools access to metrics without also giving them access to node logs or exec endpoints. This is exactly the kind of least-privilege improvement that regulated environments and compliance teams have been waiting for.
SELinux volume mounting — GA
On SELinux-enforcing nodes, Kubernetes used to recursively relabel volume contents at mount time. For large volumes, this could cause significant pod startup delays. v1.36 replaces recursive relabeling with mount -o context=XYZ, applying the SELinux label at mount rather than file by file. Faster pod starts, more consistent behavior. This was beta since v1.28 for ReadWriteOncePod volumes.
Mutable scheduling directives for suspended jobs — GA and enabled by default
Before v1.36, a suspended Job was locked into its original scheduling configuration. If you wanted to change node affinity, tolerations, or resource requests — you had to delete and recreate it. That's painful for batch pipelines, ML training jobs, and anything that needs to be rescheduled across different node pools.
Now, while a Job is suspended, you can update its pod template's scheduling fields and resource requests. Resume the job and it picks up the new configuration. A small change with real operational impact for anyone running data or ML workloads.
What's moving to beta in Kubernetes v1.36
Beta features are on the GA track and worth testing in staging environments.
Workload-aware scheduling (WAS) — alpha, but watch this closely
This one is alpha in v1.36, but it deserves attention from anyone running distributed AI/ML training, batch jobs, or anything that needs coordinated pod placement. WAS introduces a native Workload API and a decoupled PodGroup API, letting the scheduler treat related pods as a single logical unit.
Practically, this means Gang Scheduling: a minimum number of pods must be ready before any are scheduled to a node. Alongside this come topology-aware placement and preemption policies. For distributed training workloads — where partial scheduling causes resource waste and deadlocks — this is the infrastructure that has previously required custom schedulers like Volcano or Yunikorn. Native support changes the calculus for teams who've avoided third-party schedulers.
HPA scale to zero — beta (was alpha since v1.16)
HPAScaleToZero has been sitting in alpha since Kubernetes v1.16. In v1.36 it enters beta and is enabled by default. The Horizontal Pod Autoscaler can now scale workloads down to zero replicas when there's no load. For staging environments, cost-optimized batch workloads, or event-driven services that genuinely have quiet periods, this eliminates idle pod costs without any external tooling.
In-place pod-level resource scaling — beta
Building on in-place pod resize (which hit GA in v1.35), v1.36 extends it to pod-level aggregate resource specifications. Previously, in-place resize was limited to container-level adjustments. Now you can dynamically scale the CPU and memory envelope at the pod level without restarting. Designed for cgroups v2 environments. Significant for teams optimizing cluster utilization without workload disruption.
Ephemeral service account tokens for image pulls — beta
Instead of static image pull secrets, the kubelet can now use short-lived, auto-rotating tokens scoped to the pod's identity. Secrets that don't rotate are a persistent attack surface. This approach removes that concern. This builds on work from v1.33 and is reaching maturity in v1.36.
HPA external metrics fallback — alpha
A new alpha feature lets HPAs fall back gracefully when external metric APIs (Datadog, cloud-provider queues, etc.) are unavailable. Previously, a metric API outage could lead to uncontrolled scaling behavior. Now you can define fallback behavior explicitly. Worth testing if your autoscaling relies on external metrics.
What's new in alpha
Alpha features are experimental. Don't run them in production, but understand what's coming.
Per-pod DRA metrics — Platform operators can now access per-pod metrics for Dynamic Resource Allocation managed hardware (GPUs, accelerators, specialized devices). This is essential groundwork for accurate billing and troubleshooting in AI/ML infrastructure.
CSI driver requirement enforcement — Prevents pods from scheduling to nodes that don't have the required CSI drivers available. Reduces a whole class of storage-related pod failures for stateful workloads.
PVC last-used timestamps — Reports when a PersistentVolumeClaim was last accessed in pvc.Status. Simple, but useful for identifying orphaned volumes and managing storage costs.
IP/CIDR validation improvements — Better input validation for IP addresses and CIDR blocks across the API. Small but reduces a category of misconfigurations that cause subtle network issues.
Deprecations and removals in Kubernetes v1.36
This section matters before you upgrade.
gitRepo volume plugin — permanently disabled
The gitRepo volume type has been deprecated since v1.11. In v1.36, the plugin is permanently disabled and cannot be re-enabled. The security problem is concrete: gitRepo could allow an attacker to run code as root on the node. If any of your workloads still use gitRepo volumes, they will fail after upgrading. Migrate to init containers with standard git tooling, or git-sync sidecar containers, before upgrading.
IPVS mode in kube-proxy — removed
IPVS mode in kube-proxy was deprecated in v1.35. It's removed in v1.36. If you're running IPVS-based kube-proxy, you need to migrate to iptables or nftables mode before upgrading to v1.36. Check your kube-proxy configuration explicitly — this isn't always obvious if the cluster was set up years ago.
Service externalIPs field — deprecated (removal in v1.43)
The externalIPs field in Service spec is now deprecated. This field has been a documented security risk since CVE-2020-8554, enabling man-in-the-middle attacks on cluster traffic. From v1.36, you'll see deprecation warnings. Full removal is planned for v1.43, so you have time — but start auditing which services use this field and plan the migration to proper load balancer configurations or Gateway API.
Ingress NGINX — retired (not a Kubernetes removal, but affects almost every cluster)
On March 24, 2026, Kubernetes SIG Network and the Security Response Committee officially retired Ingress NGINX. No further releases, no bug fixes, no security patches. Existing deployments continue to function and artifacts remain available — but you're now running unsupported software.
If you're still on Ingress NGINX, this is the time to plan your migration to Gateway API. Gateway API offers structured routing, cross-namespace references, and production-grade traffic management. The Ingress2Gateway project (which hit 1.0 in March 2026) provides tooling to help with the migration.
If you are still on Ingress NGINX, you should start planning your migration to Gateway API. Read more about various API Gateway comparison here to understand the differences between the options.
What to check before upgrading to Kubernetes v1.36
This is not an exhaustive checklist, but it covers the things most likely to break.
Audit for gitRepo volumes. Run a scan across all namespaces: kubectl get pods -A -o json | jq '.items[].spec.volumes[]? | select(.gitRepo != null)'. Any pods using gitRepo need to be migrated before the upgrade.
Check kube-proxy mode. Look at your kube-proxy DaemonSet configuration or the kube-proxy ConfigMap. If mode: ipvs is set, plan the migration to iptables or nftables first.
Audit Service externalIPs. Run kubectl get services -A -o json | jq '.items[] | select(.spec.externalIPs != null) | {namespace: .metadata.namespace, name: .metadata.name}'. You'll start seeing deprecation warnings in logs, but better to know now.
Review Ingress NGINX exposure. If you're running Ingress NGINX, assess your migration timeline. No security patches means active CVEs won't be addressed.
Test MutatingAdmissionPolicies in staging. If you're running mutation webhooks today, understand what the CEL-based alternative looks like. You don't have to migrate immediately, but you should evaluate the path.
Kernel and runtime compatibility for user namespaces. If you plan to enable hostUsers: false, verify kernel version (5.15+ recommended) and that your container runtime supports it.
Upgrade sequentially. Kubernetes supports N-2 version skew. If you're on v1.33 or earlier, step through versions. Skipping multiple versions is unsupported and tends to cause subtle problems that are hard to diagnose.
Frequently asked questions about Kubernetes v1.36
Q: Is v1.36 a good release to upgrade to in production?
Yes, with caveats. The GA features are stable and the release itself is production-ready. The main risks are the breaking changes — gitRepo removal and IPVS removal — which will hard-fail if you haven't prepared. Do your audit first, test in staging, then upgrade.
Q: Is Ingress NGINX dead? Do I have to migrate immediately?
Retired, not dead. Existing deployments keep working. The concern is that with no security patches, any new CVE discovered in Ingress NGINX won't be fixed. For clusters with internet-facing ingress, the risk timeline depends on your threat model. For internal clusters, you have more breathing room. Start planning the Gateway API migration regardless.
Q: What's the difference between MutatingAdmissionPolicy and MutatingAdmissionWebhook?
Webhooks require an external HTTP server with TLS, which you manage separately. MutatingAdmissionPolicy defines mutation logic as native Kubernetes objects using CEL expressions. No server to run, no certs to rotate, no latency to worry about. For most mutation use cases, the policy approach is operationally simpler. Complex mutations that require external data or are expressed better in code may still need webhooks.
Q: User namespaces have been in alpha/beta for years. Is it safe now?
GA means the API is stable and the implementation is production-ready by Kubernetes standards. Whether it's safe for your specific workloads depends on kernel version and container runtime support. Test with non-critical workloads first. The main watch-out is that some images designed to run as root inside the container may behave unexpectedly when the UID mapping changes.
Q: What's the upgrade path from v1.33?
v1.33 → v1.34 → v1.35 → v1.36. Skipping versions is unsupported. Each upgrade should be validated in staging. The control plane should be upgraded before worker nodes. Check the official migration guide for each step. You can also take a blue green approach i.e. create a new cluster and migrate workloads.
Q: Do we need to do anything about HPA scale-to-zero in v1.36?
If you don't want workloads scaling to zero, check whether your HPAs explicitly set minReplicas: 1. Previously, not setting a minimum also resulted in a minimum of 1. With HPAScaleToZero now in beta and enabled by default, the behavior changes if minReplicas is set to 0 or omitted in contexts where zero scaling applies. Audit your HPA configurations.
Q: Is DRA ready for production AI/ML workloads?
DRA is maturing fast. The core feature graduated to GA in v1.34. v1.36 adds per-pod metrics for DRA resources and continues improving observability. For production GPU scheduling on single clusters, it's increasingly viable. For complex multi-cluster or heterogeneous hardware setups, test thoroughly. The Workload-Aware Scheduling alpha features coming alongside DRA are the other half of the AI/ML scheduling story — worth watching for v1.37+.
Kubernetes upgrades don't have to be painful — CloudRaft can help
Kubernetes releases every four months. Each one brings breaking changes, deprecated APIs, new feature gates, and decisions that compound over time if you don't stay current. The gap between "we should upgrade" and "we're three versions behind with gitRepo volumes in production" closes faster than most teams expect.
CloudRaft helps engineering teams at every stage of this:
Pre-upgrade assessment. We scan your cluster for deprecated APIs, removed features, and configuration patterns that will break across your target version. You get a clear picture of what needs to change before you touch anything.
Migration planning and execution. Whether you're moving from Ingress NGINX to Gateway API, reworking IPVS-based networking, or untangling years of accumulated webhook infrastructure, we've done this across dozens of clusters in production environments.
Version gap recovery. If you're multiple versions behind, we build a structured upgrade path that keeps your workloads stable through each step rather than treating it as a single risky jump.
Ongoing platform ownership. For teams that want Kubernetes expertise without hiring a dedicated platform team, we operate as an extension of your engineering org — keeping your clusters current, secure, and observable.
Kubernetes v1.36 is a strong release. Running it well is the part we can help with.
