# Kubernetes Deprecations, Removals, and Major Changes in v1.31

As Kubernetes develops and matures, features may be deprecated, removed, or replaced with better ones for the project's overall health. This article outlines some planned changes for the Kubernetes 1.31 release that the release team feels you should be aware off for the continued mantainance of your Kubernetes enviroment. Information listed below is based on the current status of the v1.31 release and may change before the actual release date.

### The Kubernetes API Removal and Deprecation process
The Kubernetes project has a well-documented [deprecation policy](https://kubernetes.io/docs/reference/using-api/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.

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 [documentation](https://kubernetes.io/docs/reference/using-api/deprecation-guide/).

## A note about SHA-1 signature support fully going away in go1.24 - Abbie

In go1.18 (released in March 2022), the crypto/x509 library started to reject certificates that were signed with a SHA-1 hash function. While SHA-1 is established to be unsafe and publicly trusted Certificate Authorities have not issues SHA-1 certificates since 2015, there might still be cases in the context of Kubernetes where user-provided certificates are signed using a SHA-1 hash function through private authorities with them being used for Aggregated API Servers of webhooks. If you have been reliant on SHA-1 based certificates, you must be explicitly opting back into its support by setting `GODEBUG=x509sha1=1` in your environment.

Given Go's [compatibility policy for GODEBUGs](https://go.dev/blog/compat), the `x509sha1` GODEBUG and consequently the support for SHA-1 certificates will [fully go away in go1.24](https://tip.golang.org/doc/go1.23) which would release in the first half of 2025. If you are reliant on SHA-1 certificates, please start moving off of them.

Please also see issue (#125689)[https://github.com/kubernetes/kubernetes/issues/125689] to get a better idea of timelines around the support for SHA-1 going away and when Kubernetes releases would adopt go1.24, and also to know how to detect usage of SHA-1 certificates via metrics and audit logging:

## Deprecations and Removals in Kubernetes 1.31

### Deprecate and remove kustomize from kubectl - Yigit
In the early days of Kubernetes, when not that many tools in the field of declarative configurations existed, kustomize was introduced and to make life easier for kubectl users it was included in kubectl, by default.

Over the past several years the ecosystem around Kubernetes grew significantly, resulting in wider spread of tooling, including declarative configuration. With these new options, it's best left to the user to match their use cases with the best tool capable of resolving the problem at hand. Using kubectl plugins, users can pick and choose the best tool to match their needs.

With Kubernetes v1.31, kustomize will be deprecated from kubectl. This will allow both tools to be developed and maintained separately.

### Deprecate Kubelet RunOnce mode [#4580](https://github.com/kubernetes/enhancements/issues/4580) sig-node - Rashan
The kubelet support for RunOnce mode is being deprecated and removed. Users are advised to deprecate RunOnce mode by disabling the LegacyNodeRunOnceMode feature gate. Starting in Kubernetes 1.31, kubelet will refuse to start if this feature gate is disabled.

Users who still rely on this feature can migrate to the `podman kube` subcommand. Refer to the [podman documentation](https://docs.podman.io/en/latest/markdown/podman-kube.1.html.) for more information.

### Deprecate status.nodeInfo.kubeProxyVersion field [#4004](https://github.com/kubernetes/enhancements/issues/4004) sig-node - Rashan
The `status.nodeInfo.kubeProxyVersionv1.Node` field is being deprecated due to inaccuracies. This field is set by the kubelet, which does not have reliable information about the kube-proxy version or whether kube-proxy is running.

After deprecation, users will no longer be able to retrieve the kube-proxy version from the Node object.

* [note] This was announced as deprecated first in the [1.29 mid-cycle blog](https://kubernetes.io/blog/2023/11/16/kubernetes-1-29-upcoming-changes/#deprecation-of-the-status-nodeinfo-kubeproxyversion-field-for-node). We should check to see if there are new changes in the KEP. If there are, we can add a message. If not, we probably dont need to include this again.

### Removal of in-tree cloud providers - sig-cloudprovider Matteo

As highlighted in our [previous blog](https://kubernetes.io/blog/2024/05/20/completing-cloud-provider-migration/), the last bits of in-tree cloud provider code have been removed.
This milestone marks the completion of the externalization process for all cloud providers integrations from the Kubernetes core ([KEP-2395](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cloud-provider/2395-removing-in-tree-cloud-providers/README.md)), a process started with Kubernetes v1.26 and long due since v1.7. This change helps Kubernetes to get closer to being a truly vendor-neutral platform.

For further details on the cloud provider integrations read our [v1.29 Cloud Provider Integrations feature blog](https://kubernetes.io/blog/2023/12/14/cloud-provider-integration-changes/) and for additional context about the in-tree code removal we invite you to check the ([v1.29 deprecation blog](https://kubernetes.io/blog/2023/11/16/kubernetes-1-29-upcoming-changes/#removal-of-in-tree-integrations-with-cloud-providers-kep-2395-https-kep-k8s-io-2395)).

The latter blog also contains useful information for users who need to migrate to version 1.29 and later.

~~* [note] We might want to include links one or more of these blogs [Kubernetes 1.29 blog](https://kubernetes.io/blog/2023/11/16/kubernetes-1-29-upcoming-changes/#removal-of-in-tree-integrations-with-cloud-providers-kep-2395-https-kep-k8s-io-2395), [Completing Cloud Provider Migration](https://kubernetes.io/blog/2024/05/20/completing-cloud-provider-migration), [Cloud Provider Integration Changes](https://kubernetes.io/blog/2023/12/14/cloud-provider-integration-changes/)~~

### Final Removal of Kubelet Flag ``--keep-terminated-pod-volumes`` - Edith
The Kubelet flag ``--keep-terminated-pod-volumes``, which was deprecated in 2017, has now been removed.

You can find more details in the pull request [#122082](https://github.com/kubernetes/kubernetes/pull/122082)

### Removal of CephFS volume plugin - Yigit
[CephFS volume plugin](https://kubernetes.io/docs/concepts/storage/volumes/#cephfs) was removed in this release and the cephFS volume type became non-functional.

Alternative is to use [CephFS CSI driver](https://github.com/ceph/ceph-csi/) in your Kubernetes Cluster. A re-deployment of your application is required to use the new driver if you were using CephFS volume plugin before upgrading cluster version to v1.31.

CephFS volume plugin was formally marked as deprecated in v1.28.

### Removal of Ceph RBD volume plugin - Yigit
[Ceph RBD volume plugin](https://kubernetes.io/docs/concepts/storage/storage-classes/#ceph-rbd) was removed in this release together with its CSI migration support and the ceph RBD volume type became non-functional.

Alternative is to use [RBD CSI driver](https://github.com/ceph/ceph-csi/) in your Kubernetes Cluster. A re-deployment of your application is required to use the new driver if you were using Ceph RBD volume plugin before upgrading cluster version to v1.31.

CephRBD volume plugin was formally marked as deprecated in v1.28.

### Deprecation and Removal of Non-CSI Volume Limit Plugins in Kube-scheduler - Edith

The ``Kube-scheduler`` has deprecated all non-CSI volume limit plugins and removed them from the default plugins, including:

- AzureDiskLimits
- CinderLimits
- EBSLimits
- GCEPDLimits

The NodeVolumeLimits plugin can handle the same functionality as the above plugins since those volume types have been migrated to CSI. Please remove the specified plugins and replace them with the NodeVolumeLimits plugin if you explicitly use them in the scheduler config. These plugins will be removed in release 1.32.

These plugins have been removed from the default plugins as they have been marked as deprecated since version 1.14.

You can find more details in the pull request [#124500](https://github.com/kubernetes/kubernetes/pull/124500).

## Looking ahead - Matteo
The official list of API removals planned for [Kubernetes v1.32](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-32) include:

* The `flowcontrol.apiserver.k8s.io/v1beta3` API version of FlowSchema and PriorityLevelConfiguration, following [this change](https://kubernetes.io/blog/2023/11/16/kubernetes-1-29-upcoming-changes/#removal-of-the-v1beta2-flow-control-api-group) happened in release 1.29.

For more information please refer to [these docs](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-32).

~~* Include content from https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-32~~

## Want to know more?
Deprecations are announced in the Kubernetes release notes. We will formally announce the deprecations that come with [Kubernetes v1.31](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.31.md#deprecation) as part of the CHANGELOG for that release.

You can see the announcements of pending deprecations in the release notes for:

* [Kubernetes v1.30](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md#deprecation)

* [Kubernetes v1.29](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md#deprecation)

* [Kubernetes v1.28](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.28.md#deprecation)

* [Kubernetes v1.27](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.27.md#deprecation)