The 46 advancements in this release are comparable to the 56 in Kubernetes 1.22 and the 45 in Kubernetes 1.23. Of those 46 improvements, 13 have been upgraded to Stable, 14 are ongoing improvements to existing features, 13 are brand-new features, and 6 are discontinued features.
The new CSI volume health monitoring, the new Network Policy Status field, or the TimeZone support for CronJobs are just a few of the additional features that are part of this release but have the possibility of altering how we engage with Kubernetes. Other enhancements, such as the non-graceful node termination or the maxUnavailable for StatefulSets, will also make life simpler for network admins.
All the brilliant improvements that are being made available in the GA state are the cherry on top of this version. This contains features with a long track record, such as Service Type=LoadBalancer Class, Storage Capacity Tracking, PodOverhead, and CSI Volume Expansion, to mention a few.
Let’s get right to the point and go over the new version’s features in more detail.
Kubernetes 1.24 Latest Updates
The Kubernetes 1.24 is known by the codename ‘stargazer’ Owing to the more than a thousand individuals and companies who participated in the latest release.
Let’s talk about the feature making the most headlines.
Eliminating the Docker runtime
We seem to have been talking about this for a very long time, but it is likely the largest feature elimination in Kubernetes history, and it contains the most risk of causing harm.
However, the good thing is that it is still premature. Although the updated version has been launched, few people will be adopting it just now. Therefore, there are still possibilities of disruption and will remain for the upcoming 6-12 months.
New beta APIs are, by default, disabled.
Another interesting development is that new beta APIs will now be turned off by default. Previously, they were turned on by default, which was incredibly useful—almost too useful—but now it’s the opposite. Individuals started becoming addicted despite not being completely aware they were beta.
As a result, starting with version 1.24, all new beta APIs will be switched off by default, but those that were beta in earlier releases and were already enabled will remain so. Therefore, in order to access any new beta features like the 15 advancements in 1.24, you must manually enable them.
Volume expansion and Storage capacity are now stable
volume growth and storage capacity tracking are now reliable capabilities, and feature-rich storage in Kubernetes is essential for important applications.
With volume expansion, you may immediately modify a preexisting PVC and define a new, larger size. And it has to be bigger; they cannot be reduced in size. The back-end storage system and CSI driver must support it.
Capacity tracking is the other option. This makes capacity information available so the planner may choose the best nodes for Pods that require storage.
The components, APIs, and interfaces utilize the Network SIG to provide networking capabilities to the workloads and clusters of Kubernetes. A crucial bug fix from the SIG is included in the 1.24 version to fix the double port-opening problem with Kube-proxy. Every Kubernetes cluster has a network component called Kube-proxy running as a proxy. Before the 1.24 version, Kube-proxy attempted to open two ports when IPv6ZeroCIDR and IPv4ZeroCIDR were used as triggers and nodePortAddresses were empty. The port was always opened successfully on the first try but never on the second. The update ensures that proxies’ nodeAddresses only include addresses that belong to their IP family.
Cloud Providers SIG
The mission of the Cloud Provider SIG is to create and maintain extensions or add-ons for cloud providers. Extensions known as add-ons interact with Kubernetes to incorporate new features. The Kubernetes cluster add-ons are configured and installed by cluster administrators. The updated 2022 version does not contain the add-on extension. You have to update your tooling and scripts if you create Kubernetes clusters and deploy the dashboard add-on.
Cluster Lifecycle SIG
The Cluster Lifecycle SIG focuses on the setup, downgrades, upgrades, creation, and removal of clusters in a manner that is cloud-native in order to expedite Kubernetes cluster activities. Among the features that are kept up to date in the latest version is kubeadm. By using guiding principles, you can leverage them to build minimally functional Kubernetes clusters.
For kubeadm, the 1.24 release includes two crucial changes:
- UnversionedKubeletConfigMap has advanced to the beta stage and is now, by default, turned on. As a result, rather than utilizing kubelet-config-x.yy, new clusters built by kubeadm will opt for the name convention Kube-system/kubelet-config. The new RBAC and ConfigMap structures will be created by kubeadm if you update your clusters.
- Elimination of the requirement for a single certificate. kubeadm employs a ca. crt file, but prior to version 1.24, it demanded that the file contain only a singular certificate. This constraint is no longer present in the current edition, and kubeadm will now automatically choose the first certificate in the file.
The elements in between hosts and pods resources, such as compute, are the central focus of Node SIG. The two most important Node SIG parts, kubelet and container runtime have undergone considerable changes in the 1.24 version.
One of Kubernetes’ primary functions, the deployment of pods to nodes, is the target of the Scheduling SIG. The Kube-scheduler has only seen one crucial modification in the 1.24 release. The address and insecure port flags have been eliminated.
Kubernetes’ initial release in 2022 intends to increase its dependability and security. Additionally, Kubernetes will stay current with the most recent technological advancements in the cloud thanks to the improvements made to the architecture, including container runtime adjustments.
Even though the latest version seems legit, it will take over six months or more for all of us to get a complete picture of how effective the advancements are going to be.
Further blogs within this Kubernetes Compliance category.