The Kubernetes release train keeps rolling, and version 1.36 — scheduled for the end of April 2026 — arrives at a moment when the orchestration platform faces its most significant evolutionary pressure since the shift to cloud-native microservices. AI workloads are reshaping cluster architectures, security requirements are tightening across every layer, and the operational complexity of running production Kubernetes has pushed many SRE teams to their limits. Here is what v1.36 brings to the table and why it matters.
Security Features Graduate to Stable
Kubernetes 1.36 promotes several critical security features from beta to stable, signaling that the project considers them production-ready and committed to long-term API compatibility. Structured authentication configuration, which allows administrators to define authentication chains using a declarative configuration file rather than command-line flags, finally reaches GA. This has been a long-requested improvement — managing authentication through flags on the API server was always fragile and error-prone at scale.
Authorization improvements are equally significant. The new structured authorization configuration allows chaining multiple authorizers with fine-grained control over which requests each authorizer evaluates. Combined with the stable graduation of validating admission policies using CEL (Common Expression Language), cluster operators now have a cohesive, declarative security stack that can be version-controlled and audited like any other infrastructure-as-code artifact.
Workload isolation also gets a boost. User namespaces for pods, which map container UIDs to unprivileged host UIDs, graduate to stable. This is a defense-in-depth measure that significantly reduces the blast radius of container escapes — if a process breaks out of its container, it lands as a nobody user on the host rather than root.
Self-Healing Clusters and Operational Resilience
One of the quieter but impactful changes in 1.36 is improved self-healing behavior. The node lifecycle controller now handles taint-based evictions more intelligently, reducing the cascade failures that can occur when a node becomes unreachable. Pod disruption budgets receive updates that make them more predictable during rolling updates, and the scheduler gains better awareness of resource pressure signals from nodes.
For operators running large clusters, the improvements to the control plane scalability are welcome. Etcd watch performance has been optimized, API server memory consumption during large list operations is reduced, and the scheduler throughput increases by roughly 15 percent in benchmarks with heterogeneous workloads. These are not headline features, but they directly reduce the operational burden on platform teams.
AI Workload Scheduling: Kubernetes Meets GPUs
The most forward-looking changes in 1.36 address the elephant in the room: AI and machine learning workloads are flooding into Kubernetes clusters, and the platform was not originally designed for them. The Dynamic Resource Allocation (DRA) framework, which reached beta in earlier releases, sees significant enhancements. DRA allows devices like GPUs, FPGAs, and custom accelerators to be requested and allocated through a structured API rather than the crude device-plugin mechanism that required hard-coded resource names.
New in 1.36 is improved support for GPU topology awareness. When training large models across multiple GPUs, the interconnect topology between those GPUs dramatically affects performance — two GPUs connected via NVLink will communicate orders of magnitude faster than two connected through PCIe. The scheduler can now factor topology constraints into placement decisions, ensuring that multi-GPU pods land on nodes where the requested accelerators have optimal interconnectivity.
Model serving workloads also benefit from new scaling primitives. The gateway API integration, now stable, provides sophisticated traffic splitting for inference endpoints, enabling canary deployments of new model versions with percentage-based traffic routing and automatic rollback on error rate thresholds.
Deprecations and Removals: What to Watch
Every Kubernetes release removes features, and 1.36 is no exception. The in-tree cloud provider integrations continue their march toward removal — Azure and vSphere in-tree providers are now fully deprecated, with migration to external cloud-controller-manager required before 1.38. The legacy klog text format for structured logging is removed; JSON-formatted logs are now the default and only option.
Operators should also note that several beta API versions for features that have since graduated to stable are being removed. If your manifests reference beta API versions for resources like CronJobs, PodDisruptionBudgets, or CSI drivers, you will need to update them. The migration is straightforward but must be completed before upgrading.
Is Kubernetes Ready for the AI Era?
The honest assessment is that Kubernetes is adapting, but the adaptation is incomplete. GPU scheduling, topology awareness, and dynamic resource allocation are real improvements. But the fundamental challenges of AI infrastructure — long-running training jobs that consume entire nodes for days, the need for gang scheduling where all pods in a job must be placed simultaneously, and the sheer cost of idle GPU resources — push beyond what Kubernetes was architecturally designed to handle.
Predictions that AI workloads would push SRE teams to their breaking point are proving accurate. The tooling gap between what Kubernetes provides out of the box and what production AI workloads require is filled by an ecosystem of add-ons: Kueue for job queuing, Volcano for gang scheduling, and various custom operators for model lifecycle management. Version 1.36 narrows this gap but does not close it. For platform teams, the message is clear: upgrade promptly, plan for the deprecations, and invest in understanding DRA — it is the foundation of how Kubernetes will handle specialized hardware for years to come.