Dockershim deprecated with Kubernetes 1.24 • The Register | #ukscams | #datingscams | #european

The day has come. At long last Dockershim is dead.

The removal was one of several notable changes that came with today’s Kubernetes 1.24 release. The shift on Dockershim has broad albeit well-documented implications for those running Kubernetes in production, James Laverack, lead solutions engineer for the release, told The Register.

The news shouldn’t, however, come as a surprise, he noted. Dockershim was deprecated with Kubernetes 1.20 in late 2020.

Those affected by the change will need to do some careful planning before upgrading their clusters to the latest Kubernetes release, Laverack said. “The main takeaway for platform teams and others running Kubernetes in production is, as they make the upgrade to 1.24, they have to be aware of what container runtime they’re running in their clusters, and if it’s Docker, they’re going to need to take some action.”

The good news, he added, is this is a relatively straightforward process that has a well-documented upgrade path.

Why deprecate Dockershim?

The decision to remove Dockershim was rooted in a desire to eliminate duplicated effort and simplify the Kubernetes codebase, according to Laverack.

Previously, “the Kubernetes project had introduced a container runtime interface to allow platform teams or others to customize what container runtime they want to use,” he said.

“That means that within the codebase of Kubernetes, and particularly the Kubelet, there have been two paths: one for CRI implementations and one for Docker, and this led to a lot of duplicated effort.”

While the Docker CRI no longer ships with Kubernetes 1.24 or later, that doesn’t mean it’s no longer supported. Any number of CRIs can be deployed on version 1.24, including Docker.

The latest Kubernetes release also marks a change in philosophy surrounding which features are enabled by default. Prior to this release, beta features were enabled by default in most instances, Laverack said. With Kubernetes 1.24, “that has changed so that new APIs are now disabled by default.”

This won’t affect anything that’s already in beta prior to version 1.24, he noted.

The change aims to discourage the use of beta features in production environments and prevent projects from staying in beta for too long, Laverack explained.

“This is really to encourage users to only build guarantees upon stable workloads that we’re not going to deprecate,” he said.

New features

As with previous releases, Kubernetes 1.24 adds a number of notable features and improvements.

One of the headliners is the general availability of capacity and volume expansion functionality for block storage within the Kubernetes API.

The capability, first introduced in beta with version 1.11, eliminates the need for third-party tools to indirectly manage block storage. “There have been ways to do this just by talking to the underlying storage engine. This is a way to do it through the native API,” Laverack said.

“This really helps cluster administrators understand and administer storage within their clusters and also enables applications to be built on top of Kubernetes that can manage storage automatically.”

Alongside the block storage enhancements, the release also adds IP collision mitigations in beta. The feature is analogous to defining a scope of IPs that can be assigned dynamically by a DHCP server. The result is users can now assign static IPs to their workloads and know for certain there won’t be IP collisions because it had, unbeknownst to them, already been assigned.

And in an effort to improve supply chain security for Kubernetes clusters, version 1.24 adds an experimental support for verifying Kubernetes artifacts.

“If you are a platform team running Kubernetes you can use this to verify that what you’re getting is in fact a correctly produced, untampered, unmodified version of Kubernetes,” Laverack said. ®