What’s New in Kubernetes v1.24?

Kubernetes v1.24 is almost here. In fact, it’s only taken this long because the official release was pushed back twice, from April 15th to 19th and then from April 19th to May 3rd. But it’s finally on the way.

So, what if, like many developers and Kubernetes lovers, you’re getting tired of the wait?

No need to sweat. We already have important details of the upcoming release. So, we can confidently share the highlights with you, so you’re fully prepared when the new version is officially rolled out.

Quick Overview

Kubernetes v1.24 brings 46 major changes, one less than v1.23 released in December last year and ten less than v1.22 released earlier.

Of the 46, 13 are features graduating to GA, 14 are features moving to beta, and six are deprecated or discontinued features. Lastly, 13 key features are introduced to Kubernetes for the first time.

The biggest highlight of the new release is the removal of Dockershim. The Dockershim component was originally introduced to Kubernetes to enable Docker as a Kubernetes container runtime. It served as an adaptor (middleman) that allowed Kubelet to interact with Docker.

However, the need for a middleman became unnecessary when the CRI specification was adopted, which allows containers to schedule directly with the container runtime. So, Dockershim has to make way.

You may also want to know from the onset that the new features introduced in v1.24 are minor and may not have a significant impact how you use Kubernetes right away. However, they could make life significantly easier in due course. So let’s now look at the specific changes.

Deprecated/Removed Features

Deprecated features are those marked for removal from the Kubernetes platform, while removed features are finally struck from the platform. The main deprecations and removals in v1.24 are as follows:

Dynamic kubelet configuration

Kubernetes developers have often relied on dynamickubeconfig to enable the dynamic configuration of the Kubelet. You could easily change the configuration of each Kubelet in a running Kubernetes cluster by deploying ConfigMap. Unfortunately, not anymore. Deprecated in v1.22, the feature was completely removed from Kubernetes in v1.24.

Dynamic log sanitization

Dynamic log sanitization was an experimental alpha feature added under SIG Instrumentation in Kubernetes v1.20. SIG had some reservations about the feature from the off, but it was decided that an alpha POC would be of minimal risk. Unfortunately, the feature proved too much of a logging burden, and the SIG Instrumentation team decided to adopt static analysis, which graduated to Stable in v1.23. Thus, Dynamic Log Sanitization is no longer valuable, and the team has proposed its deprecation in v1.24.

Dockershim is deprecated

Anyone who’s used Dockershim in previous versions knows what an important feature it is. Unfortunately, according to the Kubernetes team, it’s become a massive burden for the maintenance team. For instance, the feature was initially created to ensure smooth interoperability of different container runtimes. However, it doesn’t even implement CRI in the first place.

VolumeSnapshot v1beta1 CRD

Also on the chopping board is the volume snapshot v1beta1 CRD feature. Kubernetes introduced a new volume snapshot and restore functionality that provides standardized API design and adds PV snapshots and restore support for CSI volume drivers in v1.19. This function entered GA in v1.20. As a result, the team has deprecated snapshot.storage.k8s. io/v1beta1.

Other Deprecations and Removals

Other features removed or deprecated in Kubernetes v1.24 are the cluster addon for the dashboard (removed), insecure servicing configuration from cloud provider package (removed), VSphere releases less than 7.0u2 (deprecated), and in-tree azure plugin (deprecated).

Graduated and New Features

At least 27 features have graduated in the new release, 13 going from beta to stable and 14 from alpha to beta. Meanwhile, at least six key features are introduced to alpha. The following is a summary of the most notable graduands.

Graduated to Stable (GA)

General Availability (GA) features are stable software versions that will appear in Kubernetes for many subsequent versions. More importantly, the features are permanently enabled; you cannot disable them. Key features headed to GA in the new release are:

Beta APIs disabled by default

Previously, beta APIs not considered stable were enabled by default. The idea was to make the features fully accessible to developers to accelerate the adoption of the said features. Unfortunately, this approach has many drawbacks. For instance, beta APIs with bugs were found in 90% of deployed clusters, creating a nightmare for developers. Therefore, starting v1.24, beta APIs are disabled by default.

Efficient watch resumption

Efficientwatchresumption is initialized from etcd at the moment when it starts with empty change history. This way, clients who wish to resume a watch immediately after the kubeAPI server reboots have a resource version out of the history window. The feature was initially in beta but has now jumped to general availability.

Indexed job semantics in job API

Indexed jobs were first introduced to Kubernetes in v1.21 to make it easy to schedule parallel jobs. In addition, they allow you to statistically partition work among parallel workers. The indexed jobs semantics graduating to stable in v1.24 adds completion indexes into the pods of a job with a fixed completion count, making it easier to run embarrassingly parallel jobs.

Batch/v1: add suspend field to jobs API

The ability to temporarily suspend jobs was first introduced in v1.21. From then, developers could suspend jobs by updating the jobs spec. In other words, you just needed to change the .sec.suspend field of the job to true. Then, you can resume your jobs by setting .sec.suspend back to false whenever you’re ready. The feature which was in alpha just last year is now in GA.

CSR duration adds new ExpirationSeconds field

Kubernetes adds a new ExpirationsField to CertificateSigningRequestSpec that accepts 600 seconds (equivalent to ten seconds) as a minimum value. The change was first made in Kubernetes v1.22, allowing those requesting certificate signing to set a minimum valid lifetime for the issues certificate. The new minimum of 600 seconds is now generally available.

Others

Other features that graduate to general availability in Kubernetes v1.24 are, PodOverhead, Non-preempting priority, Pod affinity namespaceselector, CSI volume expansion, Storage capacity tracking, Openstack in-tree to CSI driver migration, and Azure disk in-tree to CSI driver migration.

Leader migration, which provides a mechanism for HA clusters to safely migrate cloud-specific controllers between the Kube-controller-manager and cloud-controller-manager, also moves to stable. The same applies to the service type=loadbalancer class.

Graduated to Beta

Beta features are well-tested features considered safe for developers and other users. They’re enabled by default on Kubernetes. Keep in mind that the feature’s schema and semantics of objects may change in subsequent beta and stable releases. The main features moving to beta are;

Criteria for field validation

Server-side validation was only recently added to Kubernetes. Prior, you could use the kubectl dry-run feature to validate your dry-run manifests. While useful, this process sometimes only results in local validation; the validation doesn’t manifest when you send it to the API server. Now, serverside validation is here with kubectl -validate=true, which simplifies everything.

OpenAPI v3

Initial support for OpenAPI V3 started in Kubernetes v1.23. That’s when the feature entered alpha. So, it was disabled by default, though you could easily enable it by turning on the feature gate named OpenAPI V3 for the Kube-apiserver component. Now, the feature is in beta, thus enabled by default. Remember that if you adopt a beta API, you can continue to interact with your clusters using the API even after the feature graduates to stable.

Track job-ready pods in Job Status

An enhancement in the JobReadyPods feature adds the job.status.ready field that counts the number of jobs with a “ready” status, similar to active, succeed, and failed states, which is already in use today. This means you no longer need to continuously listen to pod updates to keep track of their status. The feature is now in beta and comes enabled by default in Kubernetes v1.24.

Reduction of secret-based service account tokens

You may recall that TokenRequestAPI has been stable since v1.22 of Kubernetes. However, the platform usually automatically creates a “secret” service account during pod creation, which holds the credentials for accessing the API. That’s changing. Here onwards, pods will now obtain API credentials directly through TokenRequest API. Tokens are also automatically deleted/invalidated when the associated pod is deleted.

Volume populator

Introduced in v1.18, the volume populator establishes standards that enable users to create pre-populated volumes. An excellent example is if you wish to pre-populate a disk for a virtual machine with an OS image or enable data backup and restore. Volume pre-population makes it a straightforward process. The population details are left for purpose-built controllers.

Others

Other features graduating to beta (thus will be enabled by default starting Kubernetes v1.24) are support for mixed protocols in services with type-LoadBalancer, service internal traffic policy, Kubelet credential provider, PriorityClassValueBasedGracefulShutdown, and gRPC probes.

Note that Azure file in-tree to CSI driver migration, always honor reclaim policy, and openApiEnum Types are also in beta.

Graduated to Alpha

Alpha features are new features under testing. They often contain many bugs and thus are disabled by default. Additionally, support for alpha features may stop at any time. It is not advised to enable for production clusters.. The main features graduating to alpha are:

MaxUnavailable for StatefulSets

Everyone who has worked with Kubernetes understands the importance of the StatefulSets feature. It supports stateful applications requiring stable storage, unique network identifiers, and ordered rolling updates.

Unfortunately, pods are often deleted and recreated one at a time when performing rolling updates, significantly slowing down the process. MaxUnavailable is a new feature introduced to control the number of pods deleted and recreated at any given time to speed up rolling updates.

Network policy status

Although the current network policy resources are okay, they often create a few risky confusions. For instance, the policies are currently implemented by different CNI providers and in different orders. Thus, it’s easy to end up in a situation where a network policy is not honored by the CNI provider, and the user does not know about it.

To solve this problem, Kubernetes is introducing a new “Status” sub-resource that updates users on whether a network policy and its features have been properly parsed. This will also help users follow up on features that aren’t working.

MinDomains in PodTopologySpread

Whenever you allocate pods to nodes in Kubernetes, Pod-Topology-Spread, through maxSkew, defines the pod distribution process. It all comes down to resource availability, though. For instance, the scheduler may not allocate new pods if you cannot meet maxSkew requirements due to insufficient resources. Alternatively, the Cluster Autoscaler may scale down the number of domains to zero to save resources, making the few existing domains invisible.

The new minDomain subresource establishes a minimum number of available domains to prevent the two issues above.

Others

Other key features coming to Kubernetes for the first time are non-graceful node shutdown, control volume mode conversion between source and target PVC, CSI volume health monitoring, and Reserve service IP ranges for dynamic and static IP allocation.

Timezone support in cronjob, contextual logging, add subsource support in kubectl, and Kubectl return code normalization also enter alpha for the first time.

Summary

Kubernetes v1.24 is set for release in early May after the rollout was pushed back twice in April. It comes with 46 key changes and multiple minor changes, which could define Kubernetes for the next few years. As a result, it’s one of the most important releases for Kubernetes yet. We strongly suggest upgrading to Kuberntes v1.24 to be able to use all the new amazing features from this new release.

To see how to use Rafay to easily upgrade Kubernetes across your fleet of clusters on data centers, the cloud, and the edge, sign up for a free trial today!