Kubernetes v1.36 arrives at the end of April 2026 with a substantial set of enhancements, deprecations, and removals. Here's what stands out in this development cycle.
Note that details may shift as development continues toward the final release.
Understanding the API deprecation lifecycle
Kubernetes follows a strict deprecation policy that governs how features are phased out. Stable APIs can only be deprecated once a newer stable version exists, and each stability tier has minimum support windows. Deprecated APIs remain functional for at least one year after deprecation, though they trigger warnings. Once removed, you'll need to migrate to the replacement API.
- Stable (GA) APIs cannot be removed within a major Kubernetes version, even after deprecation.
- Beta APIs must remain supported for three releases following deprecation.
- Alpha APIs may be removed at any time without prior notice, particularly when alternative implementations already exist.
All removals follow this policy, whether an API graduates to stability or simply doesn't gain traction. Migration paths are always documented in the deprecation guide.
A concrete example: the ingress-nginx project retirement announced by SIG-Security on March 24, 2026. As project stewardship ended, the community was directed toward alternative ingress controllers that meet current security and maintenance standards. This mirrors the same lifecycle discipline that keeps Kubernetes evolving without breaking existing deployments abruptly.
The end of Ingress NGINX
Kubernetes SIG Network and the Security Response Committee retired Ingress NGINX on March 24, 2026. No further releases, bug fixes, or security patches will be issued. Existing deployments continue to work, and installation artifacts like Helm charts and container images remain accessible, but the project is no longer maintained.
Read the full context in the official retirement announcement.
What's being deprecated and removed in v1.36
Deprecating .spec.externalIPs in Service
The externalIPs field in Service specs is now deprecated. This field has long been a security liability, enabling man-in-the-middle attacks as outlined in CVE-2020-8554. Starting with v1.36, using it triggers deprecation warnings. Full removal is scheduled for v1.43.
If you're still using externalIPs, migrate to LoadBalancer services for cloud-managed ingress, NodePort for straightforward port exposure, or the Gateway API for more flexible and secure external traffic handling.
Details: KEP-5707: Deprecate service.spec.externalIPs
Removing the gitRepo volume driver
The gitRepo volume type, deprecated since v1.11, is now permanently disabled in v1.36 and cannot be re-enabled. This closes a critical security hole where gitRepo could allow attackers to execute code as root on nodes.
Though deprecated for years with better alternatives available, it was technically still usable in prior releases. That ends with v1.36. Migrate any remaining workloads to init containers or external git-sync tools.
Details: KEP-5040: Remove gitRepo volume driver
Key enhancements coming in v1.36
The enhancements below are expected in v1.36, though the final release content may change.
Faster SELinux volume labeling reaches GA
Kubernetes v1.36 promotes the SELinux volume mounting improvement to general availability. Instead of recursively relabeling files, the system now uses mount -o context=XYZ to apply the correct SELinux label to the entire volume at mount time. This delivers more consistent performance and reduces Pod startup delays on SELinux-enforcing systems.
Introduced as beta in v1.28 for ReadWriteOncePod volumes, the feature gained metrics and an opt-out mechanism (securityContext.seLinuxChangePolicy: Recursive) in v1.32 to help identify conflicts. Now stable in v1.36, it applies to all volumes by default, with Pods or CSIDrivers opting in via spec.SELinuxMount.
Be aware: this feature may introduce breaking changes in future releases if privileged and unprivileged Pods share volumes. Pod authors are responsible for setting seLinuxChangePolicy and SELinux volume labels correctly, whether in Deployments, StatefulSets, DaemonSets, or custom resources with Pod templates. Misconfiguration can cause issues when Pods share volumes.
Details: KEP-1710: Speed up recursive SELinux label change
External signing for ServiceAccount tokens
Kubernetes already supports external signing of ServiceAccount tokens as a beta feature. This lets clusters integrate with external key management systems or signing services rather than relying solely on internal keys.
With this enhancement, the kube-apiserver can delegate token signing to external systems like cloud key management services or hardware security modules. This strengthens security and simplifies key management for clusters using centralized signing infrastructure. Expect this to graduate to stable in v1.36.
Details: KEP-740: Support external signing of service account tokens
Device taints and tolerations in DRA drivers
Kubernetes v1.33 introduced taints and tolerations for physical devices managed through Dynamic Resource Allocation (DRA). By default, any device can be scheduled. This enhancement lets DRA drivers mark devices as tainted, preventing them from being scheduled unless explicitly tolerated. Cluster administrators can also create a DeviceTaintRule to taint devices matching specific criteria, such as all devices from a particular driver. This improves scheduling control and ensures specialized hardware is only used by workloads that explicitly request it.
In v1.36, this feature graduates to beta with expanded testing, making it available by default without a feature flag.
Learn more about taints and tolerations.
Details: KEP-5055: DRA: device taints and tolerations
Partitionable devices in DRA
Kubernetes v1.36 extends Dynamic Resource Allocation (DRA) with support for partitionable devices, enabling a single hardware accelerator to be divided into multiple logical units shared across workloads. This is particularly valuable for expensive resources like GPUs, where dedicating an entire device to one workload often leads to underutilization.
Platform teams can now allocate only the necessary portion of a device to each workload instead of reserving it entirely. This improves cluster efficiency by running multiple workloads on the same hardware while maintaining isolation and control, helping organizations extract more value from their infrastructure.
Details: KEP-4815: DRA Partitionable Devices
Dig deeper
New features and deprecations are documented in the Kubernetes release notes. The full list of changes in Kubernetes v1.36 will be published in the CHANGELOG when the release ships.
Kubernetes v1.36 is scheduled for Wednesday, April 22, 2026. Watch for updates as the release date approaches.
Previous release notes:
- Kubernetes v1.35
- Kubernetes v1.34
- Kubernetes v1.33
- Kubernetes v1.32
- Kubernetes v1.31
- Kubernetes v1.30
Join the community
The easiest way to get involved is by joining one of the many Special Interest Groups (SIGs) that match your interests. Want to share something with the Kubernetes community? Participate in our weekly community meeting or through the channels below.
- Follow us on Bluesky at @kubernetes.io for updates
- Join discussions on Discuss
- Connect on Slack
- Ask or answer questions on Server Fault or Stack Overflow
- Share your Kubernetes story
- Read more on the blog
- Learn about the Kubernetes Release Team
