Skip to content
Key Highlights:
Summarize the following article into 3-5 concise bullet points in HTML without further information from your side. format:
By |
Monday, March 30, 2026Kubernetes v1.36 is coming at the end of April 2026. This release will include removals and deprecations, and it is packed with an impressive number of
enhancements. Here are some of the features we are most excited about in this cycle!Please note that this information reflects the current state of v1.36 development and may change before release.The Kubernetes API removal and deprecation processThe Kubernetes project has a well-documented deprecation policy for features. This policy states that stable APIs
may only be deprecated when a newer, stable version of that same API is available and that APIs have a minimum lifetime for each stability level. A deprecated API
has been marked for removal in a future Kubernetes release. It will continue to function until removal (at least one year from the deprecation), but usage will
result in a warning being displayed. Removed APIs are no longer available in the current version, at which point you must migrate to using the replacement.Generally available (GA) or stable API versions may be marked as deprecated but must not be removed within a major version of Kubernetes.Beta or pre-release API versions must be supported for 3 releases after the deprecation.Alpha or experimental API versions may be removed in any release without prior deprecation notice; this process can become a withdrawal in cases where a different implementation for the same feature is already in place.Whether an API is removed as a result of a feature graduating from beta to stable, or because that API simply did not succeed, all removals comply with this
deprecation policy. Whenever an API is removed, migration options are communicated in the deprecation guide.A recent example of this principle in action is the retirement of the ingress-nginx project, announced
by SIG-Security on March 24, 2026. As stewardship shifts away from the project, the community has been
encouraged to evaluate alternative ingress controllers that align with current security and maintenance
best practices. This transition reflects the same lifecycle discipline that underpins Kubernetes itself,
ensuring continued evolution without abrupt disruption.Ingress NGINX retirementTo prioritize the safety and security of the ecosystem, Kubernetes SIG Network and the Security Response Committee have retired Ingress NGINX on March 24, 2026.
Since that date, there have been no further releases, no bugfixes, and no updates to resolve any security vulnerabilities discovered. Existing deployments of
Ingress NGINX will continue to function, and installation artifacts like Helm charts and container images will remain available.For full details, see the official retirement announcement.Deprecations and removals for Kubernetes v1.36Deprecation of .spec.externalIPs in ServiceThe externalIPs field in Service spec is being deprecated, which means you’ll soon lose a quick way to route arbitrary externalIPs to your Services. This
field has been a known security headache for years, enabling man-in-the-middle attacks on your cluster traffic, as documented in CVE-2020-8554. From Kubernetes v1.36 and onwards, you will see deprecation warnings when using it, with full removal
planned for v1.43.If your Services still lean on externalIPsconsider using LoadBalancer services for cloud-managed ingress, NodePort for simple port exposure, or Gateway API
for a more flexible and secure way to handle external traffic.For more details on this enhancement, refer to KEP-5707: Deprecate service.spec.externalIPsRemoval of gitRepo volume driverThe gitRepo volume type has been deprecated since v1.11. Starting Kubernetes v1.36, the gitRepo volume plugin is permanently disabled and cannot be turned back
on. This change protects clusters from a critical security issue where using gitRepo could let an attacker run code as root on the node.Although gitRepo has been deprecated for years and better alternatives have been recommended, it was still technically possible to use it in previous releases.
From v1.36 onward, that path is closed for good, so any existing workloads depending on gitRepo will need to migrate to supported approaches such as init
containers or external git-sync style tools.For more details on this enhancement, refer to KEP-5040: Remove gitRepo volume driverFeatured enhancements of Kubernetes v1.36The following list of enhancements is likely to be included in the upcoming v1.36 release. This is not a commitment and the release content is subject to change.Faster SELinux labelling for volumes (GA)Kubernetes v1.36 makes the SELinux volume mounting improvement generally available. This change replaced recursive file relabeling with mount -o context=XYZ option, applying the correct SELinux label to the entire volume at mount time. It brings more consistent performance and reduces Pod startup delays on SELinux-enforcing systems.This feature was introduced as beta in v1.28 for ReadWriteOncePod volumes. In v1.32, it gained metrics and an opt-out option
(securityContext.seLinuxChangePolicy: Recursive) to help catch conflicts. Now in v1.36, it reaches stable and defaults to all volumes, with Pods or
CSIDrivers opting in via spec.SELinuxMount.However, we expect this feature to create the risk of breaking changes in the future Kubernetes releases, due to the potential for mixing of privileged and unprivileged pods.
Setting the seLinuxChangePolicy field and
SELinux volume labels on Pods, correctly, is the responsibility of the Pod author
Developers have that responsibility whether they are writing a Deployment, StatefulSet, DaemonSet or even a custom resource that includes a Pod template.
Being careless
with these settings can lead to a range of problems when Pods share volumes.For more details on this enhancement, refer to KEP-1710: Speed up recursive SELinux label changeExternal signing of ServiceAccount tokensAs a beta feature, Kubernetes already supports external signing of ServiceAccount tokens. This allows clusters to integrate with external key management systems
or signing services instead of relying only on internally managed keys.With this enhancement, the kube-apiserver can delegate token signing to external systems such as cloud key management services or hardware security modules. This
improves security and simplifies key management services for clusters that rely on centralized signing infrastructure.
We expect that this will graduate to stable (GA) in Kubernetes v1.36.For more details on this enhancement, refer to KEP-740: Support external signing of service account tokensDRA Driver support for Device taints and tolerationsKubernetes v1.33 introduced support for taints and tolerations for physical devices managed through Dynamic Resource Allocation (DRA). Normally, any device can be
used for scheduling. However, this enhancement allows DRA drivers to mark devices as tainted, which ensures that they will not be used for scheduling purposes.
Alternatively, cluster administrators can create a DeviceTaintRule to mark devices that match a certain selection criteria(such as all devices of a certain
driver) as tainted. This improves scheduling control and helps ensure that specialized hardware resources are only used by workloads that explicitly request them.In Kubernetes v1.36, this feature graduates to beta with more comprehensive testing complete, making it accessible by default without the need for a feature
flag and open to user feedback.To learn about taints and tolerations, see taints and tolerations.For more details on this enhancement, refer to KEP-5055: DRA: device taints and tolerations.DRA support for partitionable devicesKubernetes v1.36 expands Dynamic Resource Allocation (DRA) by introducing support for partitionable devices, allowing a single hardware accelerator to be split
into multiple logical units that can be shared across workloads. This is especially useful for high-cost resources like GPUs, where dedicating an entire device
to a single workload can lead to underutilization.With this enhancement, platform teams can improve overall cluster efficiency by allocating only the required portion of a device to each workload, rather than
reserving it entirely. This makes it easier to run multiple workloads on the same hardware while maintaining isolation and control, helping organizations get more
value out of their infrastructure.To learn more about this enhancement, refer to KEP-4815: DRA Partitionable DevicesWant to know more?New features and deprecations are also announced in the Kubernetes release notes. We will formally announce what’s new in Kubernetes v1.36 as part of the CHANGELOG for that release.Kubernetes v1.36 release is planned for Wednesday, April 22, 2026. Stay tuned for updates!You can also see the announcements of changes in the release notes for:Get involvedThe simplest way to get involved with Kubernetes is by joining one of the many Special Interest Groups (SIGs) that align with your interests. Have something you’d like to broadcast to the Kubernetes community? Share your voice at our weekly
community meetingand through the channels below. Thank you for your continued feedback and support.
License is not valid, please check your API Key!
