Kubernetes 1.31 Update Overview
This article describes some planned changes for the Kubernetes v1.31 release that you should be aware of to continue maintaining your Kubernetes environment. The information below is based on the current status of the v1.31 release.
The process of removing and deprecating Kubernetes API components
The Kubernetes project has a well-documented obsolescence policy features. This policy states that stable APIs can only be deprecated when a newer, stable version of that API is available, and that APIs have a minimum lifespan for each stability level. A deprecated API has been marked for removal in a future Kubernetes release. It will continue to function until removed (at least one year after deprecation), but will display a warning when used. Removed APIs are no longer available in the current release, so you must migrate to a replacement.
Generally available (GA) or stable versions of APIs can be marked as deprecated, but they cannot be removed in the Kubernetes mainline version.
Beta or prerelease versions of APIs must be supported for 3 releases after entering the deprecation status.
Alpha or experimental versions of APIs may be removed in any release without prior deprecation notice.
Regardless of whether an API is removed because a feature has moved from beta to stable or because the API has failed, all removals follow this deprecation policy. Whenever an API is removed, migration options are communicated in documentation.
Note on SHA-1 signature support
IN go1.18 (released March 2022) The crypto/x509 library began rejecting certificates signed with the SHA-1 hash function. While SHA-1 is recognized as insecure and publicly trusted CAs have not issued SHA-1 certificates since 2015, in the context of Kubernetes there may still be cases where user-provided certificates are signed with the SHA-1 hash function via private CAs that are used for aggregated API servers or webhooks. If you were relying on SHA-1-based certificates, you should explicitly opt out of it by configuring GODEBUG=x509sha1=1 in your environment.
Considering the compatibility policy Go with GODEBUG , x509sha1GODEBUG and SHA-1 certificate support will disappear completely in go1.24, which will be released in the first half of 2025. If you rely on SHA-1 certificates, please start ditching them.
Check out Kubernetes issue #125689, to get a better understanding of the SHA-1 deprecation timeline, when Kubernetes will announce plans for go1.24, and more details on how to detect SHA-1 certificate usage using metrics and audit logs.
Deprecations and Removals in Kubernetes 1.31
Deprecation of status.nodeInfo.kubeProxyVersion field for nodes ( KEP 4004 )
The .status.nodeInfo.kubeProxyVersion field of Nodes was deprecated in Kubernetes v1.31 and will be removed in a later release. It was deprecated because the value of this field was not (and is not) accurate. This field is set by the kubelet, which does not have reliable information about the version of kube-proxy or whether kube-proxy is running.
In version 1.31 gateway DisableNodeKubeProxyVersion functions will be set to true by default, and the kubelet will no longer attempt to set the .status.kubeProxyVersion field for the node it is associated with.
Removing all internal integrations with cloud providers
The last remaining support for cloud provider integrations will be removed as part of the v1.31 release. This does not mean that you cannot integrate with a cloud provider, but you should now use the recommended approach of using an external integration. Some integrations are part of the Kubernetes project, while others are third-party software.
This milestone marks the completion of the externalization process for all cloud provider integrations from the Kubernetes core ( KEP-2395 ), a process that began with Kubernetes v1.26. This change helps Kubernetes move closer to becoming a truly vendor-neutral platform.
Other updates
Removing –keep-terminated-pod-volumes kubelet command line flag
The kubelet flag –keep-terminated-pod-volumes, which was deprecated in 2017, will be removed in v1.31.
More details can be found in the pull request #122082 .
Removing CephFS Volume Plugin
CephFS Volume Plugin was removed in this release.
It is recommended to use instead CephFS CSI driver as a third-party storage driver. If you were using the CephFS volume plugin before upgrading your cluster to v1.31, you will need to redeploy your application to use the new driver.
The CephFS volume plugin was officially marked as deprecated in version 1.28.
Removing Ceph RBD Volume Plugin
Will be removed in v1.31 release Ceph RBD Volume Plugin and its support for CSI migration, which will make this rbd volume type non-functional.
It is recommended to use instead RBD CSI driver in clusters. If you were using the Ceph RBD volume plugin before upgrading your cluster to v1.31, you will need to redeploy your application to use the new driver.
The Ceph RBD volume plugin was officially marked as deprecated in version 1.28.
Deprecation of non-CSI volume limit plugins in kube-scheduler
v1.31 will deprecate all non-CSI volume limiter scheduler plugins and remove some legacy plugins from default plugins including:
AzureDiskLimits
Cinder Limits
EBSLimits
GCEPDLimits
It is recommended to use the NodeVolumeLimits plugin as it can handle the same functionality as the removed plugins since these volume types have been migrated to CSI. You should replace deprecated plugins with the NodeVolumeLimits plugin if you are explicitly using them in scheduler configurationsThe AzureDiskLimits, CinderLimits, EBSLimits, and GCEPDLimits plugins will be removed in a future release.
These plugins will be removed from the default scheduler plugin list as they have been deprecated since Kubernetes v1.14.
Future changes
Official list of API removals planned for Kubernetes v1.32, includes:
API version flowcontrol.apiserver.k8s.io/v1beta3 FlowSchema and PriorityLevelConfiguration will be removed. To prepare for this, you can edit existing manifests and rewrite client software to use the flowcontrol.apiserver.k8s.io/v1 API version available since v1.29. All existing persisted objects are available through the new API.
Notable changes in flowcontrol.apiserver.k8s.io/v1beta3 include that the spec.limited.nominalConcurrencyShares field of PriorityLevelConfiguration defaults to 30 only if not specified, and an explicit value of 0 is not changed to 30.
More detailed information can be found at API deprecation guide.
To sum it upKubernetes is becoming a fully vendor-independent, increasingly mature solution. At the same time, updates are increasingly strictly regulated, which helps to smooth out the consequences of frequent updates and the complication of the project itself.
If you have multiple microservices and don't want to spend time setting up CI/CD, monitoring and operating Kubernetes, try our cloud – Amvera Cloud. Amvera – is an alternative to managed Kubernetes. With us, you can update your services via simple commits in Git and get almost all the benefits of Kubernetes without thinking about administration, CI/CD setup, monitoring, alerting and related services. It will be much cheaper than classic managed k8s. Kubernetes is inside us, but you are completely abstracted from its administration, you just need to link your Git repository to the service and update applications with the “git push amvera master” command.
And if you have a complex project and need help in building infrastructure based on Kubernetes, or just a consultation, write to our CEO at telegram (Kirill Kosolapov), or leave your contact information on page our DevOps team. We don't charge for asking, if it's a small consultation or something simple, we'll help for free. And if it's complicated, we'll negotiate.
