|
| 1 | +--- |
| 2 | +layout: blog |
| 3 | +title: 'Kubernetes v1.36 Sneak Peek' |
| 4 | +date: 2026-XX-XX |
| 5 | +draft: true |
| 6 | +slug: kubernetes-v1-36-sneak-peek |
| 7 | +author: > |
| 8 | + Chad Crowell, |
| 9 | + Kirti Goyal, |
| 10 | + Sophia Ugochukwu, |
| 11 | + Swathi Rao, |
| 12 | + Utkarsh Umre |
| 13 | +--- |
| 14 | + |
| 15 | +Kubernetes 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 |
| 16 | +enhancements. Here are some of the features we are most excited about in this cycle! |
| 17 | + |
| 18 | +Please note that this information reflects the current state of v1.36 development and may change before release. |
| 19 | + |
| 20 | +## The Kubernetes API removal and deprecation process |
| 21 | + |
| 22 | +The Kubernetes project has a well-documented [deprecation policy](/docs/reference/using-api/deprecation-policy/) for features. This policy states that stable APIs |
| 23 | +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 |
| 24 | +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 |
| 25 | +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. |
| 26 | + |
| 27 | +- Generally available (GA) or stable API versions may be marked as deprecated but must not be removed within a major version of Kubernetes. |
| 28 | +- Beta or pre-release API versions must be supported for 3 releases after the deprecation. |
| 29 | +- 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. |
| 30 | + |
| 31 | +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 |
| 32 | +deprecation policy. Whenever an API is removed, migration options are communicated in the [deprecation guide](/docs/reference/using-api/deprecation-guide/). |
| 33 | + |
| 34 | +A recent example of this principle in action is the retirement of the ingress-nginx project, announced |
| 35 | +by SIG-Security on March 24, 2026. As stewardship shifts away from the project, the community has been |
| 36 | +encouraged to evaluate alternative ingress controllers that align with current security and maintenance |
| 37 | +best practices. This transition reflects the same lifecycle discipline that underpins Kubernetes itself, |
| 38 | +ensuring continued evolution without abrupt disruption. |
| 39 | + |
| 40 | +## Ingress NGINX retirement |
| 41 | + |
| 42 | +To prioritize the safety and security of the ecosystem, Kubernetes SIG Network and the Security Response Committee have retired Ingress NGINX on March 24, 2026. |
| 43 | +Since that date, there have been no further releases, no bugfixes, and no updates to resolve any security vulnerabilities discovered. Existing deployments of |
| 44 | +Ingress NGINX will continue to function, and installation artifacts like Helm charts and container images will remain available. |
| 45 | + |
| 46 | +For full details, see the [official retirement announcement](/blog/2025/11/11/ingress-nginx-retirement/). |
| 47 | + |
| 48 | + |
| 49 | +## Deprecations and removals for Kubernetes v1.36 |
| 50 | + |
| 51 | +### Deprecation of `.spec.externalIPs` in Service |
| 52 | + |
| 53 | +The `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 |
| 54 | +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](https://github.com/kubernetes/kubernetes/issues/970760). From Kubernetes v1.36 and onwards, you will see deprecation warnings when using it, with full removal |
| 55 | +planned for v1.43. |
| 56 | + |
| 57 | +If your Services still lean on `externalIPs`, consider using LoadBalancer services for cloud-managed ingress, NodePort for simple port exposure, or Gateway API |
| 58 | +for a more flexible and secure way to handle external traffic. |
| 59 | + |
| 60 | +For more details on this enhancement, refer to [KEP-5707: Deprecate service.spec.externalIPs](https://kep.k8s.io/5707) |
| 61 | + |
| 62 | +### Removal of `gitRepo` volume driver |
| 63 | + |
| 64 | +The 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 |
| 65 | +on. This change protects clusters from a critical security issue where using `gitRepo` could let an attacker run code as root on the node. |
| 66 | + |
| 67 | +Although `gitRepo` has been deprecated for years and better alternatives have been recommended, it was still technically possible to use it in previous releases. |
| 68 | +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 |
| 69 | +containers or external git-sync style tools. |
| 70 | + |
| 71 | +For more details on this enhancement, refer to [KEP-5040: Remove gitRepo volume driver](https://kep.k8s.io/5040) |
| 72 | + |
| 73 | +## Featured enhancements of Kubernetes v1.36 |
| 74 | + |
| 75 | +The 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. |
| 76 | + |
| 77 | +### Faster SELinux labelling for volumes (GA) {#volume-selinux-labelling} |
| 78 | + |
| 79 | +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. |
| 80 | + |
| 81 | +This feature was introduced as beta in v1.28 for `ReadWriteOncePod` volumes. In v1.32, it gained metrics and an opt-out option |
| 82 | +(`securityContext.seLinuxChangePolicy: Recursive`) to help catch conflicts. Now in v1.36, it reaches stable and defaults to all volumes, with Pods or |
| 83 | +CSIDrivers opting in via `spec.SELinuxMount`. |
| 84 | + |
| 85 | +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. |
| 86 | +Setting the `seLinuxChangePolicy` field and |
| 87 | +SELinux volume labels on Pods, correctly, is the responsibility of the Pod author |
| 88 | +Developers have that responsibility whether they are writing a Deployment, StatefulSet, DaemonSet or even a custom resource that includes a Pod template. |
| 89 | +Being careless |
| 90 | +with these settings can lead to a range of problems when Pods share volumes. |
| 91 | + |
| 92 | +For more details on this enhancement, refer to [KEP-1710: Speed up recursive SELinux label change](https://kep.k8s.io/1710) |
| 93 | + |
| 94 | +### External signing of ServiceAccount tokens |
| 95 | + |
| 96 | +As a beta feature, Kubernetes already supports external signing of ServiceAccount tokens. This allows clusters to integrate with external key management systems |
| 97 | +or signing services instead of relying only on internally managed keys. |
| 98 | + |
| 99 | +With this enhancement, the `kube-apiserver` can delegate token signing to external systems such as cloud key management services or hardware security modules. This |
| 100 | +improves security and simplifies key management services for clusters that rely on centralized signing infrastructure. |
| 101 | +We expect that this will graduate to stable (GA) in Kubernetes v1.36. |
| 102 | + |
| 103 | +For more details on this enhancement, refer to [KEP-740: Support external signing of service account tokens](https://kep.k8s.io/740) |
| 104 | + |
| 105 | +### DRA Driver support for Device taints and tolerations |
| 106 | + |
| 107 | +Kubernetes v1.33 introduced support for taints and tolerations for physical devices managed through [Dynamic Resource Allocation (DRA)](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/). Normally, any device can be |
| 108 | +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. |
| 109 | +Alternatively, cluster administrators can create a `DeviceTaintRule` to mark devices that match a certain selection criteria(such as all devices of a certain |
| 110 | +driver) as tainted. This improves scheduling control and helps ensure that specialized hardware resources are only used by workloads that explicitly request them. |
| 111 | + |
| 112 | +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 |
| 113 | +flag and open to user feedback. |
| 114 | + |
| 115 | +To learn about taints and tolerations, see [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). |
| 116 | +For more details on this enhancement, refer to [KEP-5055: DRA: device taints and tolerations](https://kep.k8s.io/5055). |
| 117 | + |
| 118 | +### DRA support for partitionable devices |
| 119 | + |
| 120 | +Kubernetes v1.36 expands Dynamic Resource Allocation (DRA) by introducing support for partitionable devices, allowing a single hardware accelerator to be split |
| 121 | +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 |
| 122 | +to a single workload can lead to underutilization. |
| 123 | + |
| 124 | +With this enhancement, platform teams can improve overall cluster efficiency by allocating only the required portion of a device to each workload, rather than |
| 125 | +reserving it entirely. This makes it easier to run multiple workloads on the same hardware while maintaining isolation and control, helping organizations get more |
| 126 | +value out of their infrastructure. |
| 127 | + |
| 128 | +To learn more about this enhancement, refer to [KEP-4815: DRA Partitionable Devices](https://kep.k8s.io/4815) |
| 129 | + |
| 130 | +## Want to know more? |
| 131 | + |
| 132 | +New features and deprecations are also announced in the Kubernetes release notes. We will formally announce what's new in [Kubernetes v1.36] |
| 133 | +(https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.36.md) as part of the CHANGELOG for that release. |
| 134 | + |
| 135 | +Kubernetes v1.36 release is planned for Wednesday, April 22, 2026. Stay tuned for updates! |
| 136 | + |
| 137 | +You can also see the announcements of changes in the release notes for: |
| 138 | + |
| 139 | + |
| 140 | +- [Kubernetes v1.35](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.35.md) |
| 141 | +- [Kubernetes v1.34](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.34.md) |
| 142 | +- [Kubernetes v1.33](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.33.md) |
| 143 | +- [Kubernetes v1.32](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md) |
| 144 | +- [Kubernetes v1.31](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.31.md) |
| 145 | +- [Kubernetes v1.30](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md) |
| 146 | + |
| 147 | +## Get involved |
| 148 | + |
| 149 | +The simplest way to get involved with Kubernetes is by joining one of the many [Special Interest Groups](https://github.com/kubernetes/community/blob/master/siglist.md) (SIGs) that align with your interests. Have something you’d like to broadcast to the Kubernetes community? Share your voice at our weekly |
| 150 | +[community meeting](https://github.com/kubernetes/community/tree/master/communication), and through the channels below. Thank you for your continued feedback and support. |
| 151 | + |
| 152 | +- Follow us on Bluesky [@kubernetes.io](https://bsky.app/profile/kubernetes.io) for the latest updates |
| 153 | +- Join the community discussion on [Discuss](https://discuss.kubernetes.io/) |
| 154 | +- Join the community on [Slack](http://slack.k8s.io/) |
| 155 | +- Post questions (or answer questions) on [Server Fault](https://serverfault.com/questions/tagged/kubernetes) or [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) |
| 156 | +- Share your Kubernetes [story](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform) |
| 157 | +- Read more about what’s happening with Kubernetes on the [blog](https://kubernetes.io/blog/) |
| 158 | +- Learn more about the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team) |
0 commit comments