K8s 1.24 Release Notes

[Jacinto Dieujuste]

Thisrelease consists of 46 enhancements: fourteen enhancements have graduated to stable,fifteen enhancements are moving to beta, and thirteen enhancements are entering alpha.Also, two features have been deprecated, and two features have been removed.

After its deprecation in v1.20, the dockershim component has been removed from the kubelet in Kubernetes v1.24.From v1.24 onwards, you will need to either use one of the other supported runtimes (such as containerd or CRI-O)or use cri-dockerd if you are relying on Docker Engine as your container runtime.For more information about ensuring your cluster is ready for this removal, pleasesee this guide.

Release artifacts are signed using cosignsignatures,and there is experimental support for verifying image signatures.Signing and verification of release artifacts is part of increasing software supply chain security for the Kubernetes release process.

With Kubernetes 1.24, the gRPC probes functionalityhas entered beta and is available by default. You can now configure startup, liveness, and readiness probes for your gRPC appnatively within Kubernetes without exposing an HTTP endpoint orusing an extra executable.

Originally released as Alpha in Kubernetes 1.20, the kubelet's support forimage credential providershas now graduated to Beta.This allows the kubelet to dynamically retrieve credentials for a container image registryusing exec plugins rather than storing credentials on the node's filesystem.

Kubernetes 1.24 introduces a new opt-in feature that allows you tosoft-reserve a range for static IP address assignments to Services.With the manual enablement of this feature, the cluster will prefer automatic assignment fromthe pool of Service IP addresses, thereby reducing the risk of collision.

VolumeSnapshot v1beta1 CRD has been removed.Volume snapshot and restore functionality for Kubernetes and the Container Storage Interface (CSI), which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, moved to GA in v1.20. VolumeSnapshot v1beta1 was deprecated in v1.20 and is now unsupported. Refer to KEP-177: CSI Snapshot and Volume Snapshot GA blog for more information.

This release would not have been possible without the combined efforts of committed individualscomprising the Kubernetes 1.24 release team. This team came together to deliver all of the componentsthat go into each Kubernetes release, including code, documentation, release notes, and more.

Special thanks to James Laverack, our release lead, for guiding us through a successful release cycle,and to all of the release team members for the time and effort they put in to deliver the v1.24release for the Kubernetes community.

Generations of people have looked to the stars in awe and wonder, from ancient astronomers to thescientists who built the James Webb Space Telescope. The stars have inspired us, set our imaginationalight, and guided us through long nights on difficult seas.

With this release we gaze upwards, to what is possible when our community comes together. Kubernetesis the work of hundreds of contributors across the globe and thousands of end-users supportingapplications that serve millions. Every one is a star in our sky, helping us chart our course.

The CNCF K8s DevStats projectaggregates a number of interesting data points related to the velocity of Kubernetes and varioussub-projects. This includes everything from individual contributions to the number of companies thatare contributing, and is an illustration of the depth and breadth of effort that goes into evolving this ecosystem.

As Kubernetes evolves, features and APIs are regularly revisited and removed. New features may offeran alternative or improved approach to solving existing problems, motivating the team to remove theold approach.

We want to make sure you are aware of the changes coming in the Kubernetes 1.24 release. The release willdeprecate several (beta) APIs in favor of stable versions of the same APIs. The major change comingin the Kubernetes 1.24 release is theremoval of Dockershim.This is discussed below and will be explored in more depth at release time. For an early look at thechanges coming in Kubernetes 1.24, take a look at the in-progressCHANGELOG.

It's safe to say that the removal receiving the most attention with the release of Kubernetes 1.24is Dockershim. Dockershim was deprecated in v1.20. As noted in the Kubernetes 1.20 changelog:"Docker support in the kubelet is now deprecated and will be removed in a future release. The kubeletuses a module called "dockershim" which implements CRI support for Docker and it has seen maintenanceissues in the Kubernetes community." With the upcoming release of Kubernetes 1.24, the Dockershim willfinally be removed.

Docker as an underlying runtime is being deprecated in favor of runtimes that use theContainer Runtime Interface (CRI) created for Kubernetes. Docker-produced imageswill continue to work in your cluster with all runtimes, as they always have.

Several guides have been created with helpful information about migrating from dockershimto container runtimes that are directly compatible with Kubernetes. You can find them on theMigrating from dockershimpage in the Kubernetes documentation.

Kubernetes contains a large number of components that evolve over time. In some cases, thisevolution results in APIs, flags, or entire features, being removed. To prevent users from facingbreaking changes, Kubernetes contributors adopted a feature deprecation policy.This policy ensures that stable APIs may only be deprecated when a newer stable version of thatsame API is available and that APIs have a minimum lifetime as indicated by the following stability levels:

Removals follow the same deprecation policy regardless of whether an API is removed due to a beta featuregraduating to stable or because that API was not proven to be successful. Kubernetes will continue to makesure migration options are documented whenever APIs are removed.

Deprecated APIs are those that have been marked for removal in a future Kubernetes release. RemovedAPIs are those that are no longer available for use in current, supported Kubernetes versions after havingbeen deprecated. These removals have been superseded by newer, stable/generally available (GA) APIs.

As stated earlier, there are several guides aboutMigrating from dockershim.You can start with Finding what container runtime are on your nodes.If your nodes are using dockershim, there are other possible Docker Engine dependencies such asPods or third-party tools executing Docker commands or private registries in the Docker configuration file. You can follow theCheck whether Dockershim removal affects you guide to review possibleDocker Engine dependencies. Before upgrading to v1.24, you decide to either remain using Docker Engine andMigrate Docker Engine nodes from dockershim to cri-dockerd or migrate to a CRI-compatible runtime. Here's a guide tochange the container runtime on a node from Docker Engine to containerd.

The kubectl convert plugin for kubectlcan be helpful to address migrating off deprecated APIs. The plugin facilitates the conversion ofmanifests between different API versions, for example, from a deprecated to a non-deprecated APIversion. More general information about the API migration process can be found in the Deprecated API Migration Guide.Follow the install kubectl convert plugindocumentation to download and install the kubectl-convert binary.

The Kubernetes 1.25 and 1.26 releases planned for later this year will stop serving beta versionsof several currently stable Kubernetes APIs. The v1.25 release will also remove PodSecurityPolicy,which was deprecated with Kubernetes 1.21 and will not graduate to stable. See PodSecurityPolicyDeprecation: Past, Present, and Future for more information.

Kubernetes rapidly evolves with new features, design updates, and bug fixes. The community releases new Kubernetes minor versions (such as 1.30) on average once every four months. Amazon EKS follows the upstream release and deprecation cycle for minor versions. As new Kubernetes versions become available in Amazon EKS, we recommend that you proactively update your clusters to use the latest available version.

We recommend that you create your cluster with the latest available Kubernetes version supported by Amazon EKS. If your application requires a specific version of Kubernetes, you can select older versions. You can create new Amazon EKS clusters on any version offered in standard or extended support.

The following table shows important release and support dates to consider for each Kubernetes version. Billing for extended support starts at the beginning of the day that the version reaches end of standard support.

In line with the Kubernetes community support for Kubernetes versions, Amazon EKS is committed to offering standard support for at least four production-ready versions of Kubernetes at any given time. We will announce the end of standard support date of a given Kubernetes minor version at least 60 days in advance. Because of the Amazon EKS qualification and release process for new Kubernetes versions, the end of standard support date of a Kubernetes version on Amazon EKS will be on or after the date that the Kubernetes project stops supporting the version upstream.

A Kubernetes version received standard support for 14 months after first being available on Amazon EKS. This is true even if upstream Kubernetes no longer support a version that's available on Amazon EKS. We backport security patches that are applicable to the Kubernetes versions that are supported on Amazon EKS.

Yes. If any clusters in your account are running the version nearing the end of support, Amazon EKS sends out a notice through the AWS Health Dashboard approximately 12 months after the Kubernetes version was released on Amazon EKS. The notice includes the end of support date. This is at least 60 days from the date of the notice.

3a8082e126