Kubernetes 1.24 Drops Dockershim, Makes Space for Stateful Workloads
The latest release of the Kubernetes container orchestration engine, nicknamed “Stargazer,” looks out to better support databases, microservices and other emerging use cases, while shedding earlier missteps that have stymied the K8s core developers’ productivity.
Overall, this release comes with 46 “enhancements,” according to the Cloud Native Computing Foundation, which manages the open source project. Fifteen enhancements have graduated to stable status, meaning they are ready for production use, while 15 enhancements are moving to beta, and 13 enhancements are been introduced in alpha status.
First, out with the old.
Those still using the Docker runtime engine must find a replacement, or a commercial workaround, to use it with new releases of Kubernetes: As of 1.24, the Dockershim will no longer be supported.
The decision to drop support for the Docker runtime was made in 2020. Although Docker sparked the first widespread success of the use of containers, Kubernetes switched to a standardized Container Runtime Interface, introduced in 2016, to allow the Kubernetes Kubelet node engine to interface with any compliant runtime engine, with the goal of not being totally dependent on Docker itself.
The original Docker engine itself was not compliant of course, and so a shim itself was made to operate the runtime on K8s. That shim was supported until this release.
This change will be pertinent to those running deployments that are still using the Docker engine itself, which will need to be updated to a compatible runtime — CRI-O or containerd or the commercially-available Mirantis Container Runtime (MCR) — before updating.
Containers built on the Docker development tools are now built to run on the CRI spec and are not affected by this change. “For most application developers, this will be a transparent change,” explained James Laverack, who is the project lead for the v1.24 release.
While Laverack didn’t have an estimate of how many deployments still rely on the Docker engine, he noted that the only reason for still doing so would be if Kubernetes functionality was accessed outside of its API. In these cases, the applications that do this will require some work to upgrade.
Accessing Kubernetes through means other than the API is problematic for several reasons, Laverack explained. For one it could lock users into only using one Docker engine to access Kubernetes features.
The Docker shim was also problematic in that it created a lot of maintenance work on the part of the K8s maintainers. There was a lot of code for handling Docker specifically (in parallel to the CRI itself), and it had been buggy. Eliminating the support helps the K8s engineers simplify the codebase, Laverack said.
“The community felt that removing it would allow that part of the codebase to be streamlined and reduce bugs, improve stability and increase improve velocity for more releases,” Laverack said. “So it’s really a foundational change that will help Kubernetes ship more features in the future with better quality.”
Those using Kubernetes are steadily increasing the size and number of their clusters, according to VMware.
What Else Is in the Box?
Stargazer also shows off the work done to provide storage-aware controls for Kubernetes. This will be good news to those planning to run stateful workloads — such as databases — on Kubernetes. Kubernetes-aware applications will be able to manage storage with a finer granularity with these capabilities, offering the ability to resize volumes or allow the application to make decisions based on the remaining storage available at any given moment.
A contextual logging feature, an introduced as an alpha release to the API Server, will help platform engineers and the Kubernetes core dev team itself debug Kubernetes. The release now supports, in beta, version 3 of the Kubernetes OpenAPI, which allows third-party developers to write operators and custom resource definitions to extend Kubernetes.
Good news for microservices developers: Kubernetes 1.24 supports Google’s gRPC communications protocol.
A new probes functionality eliminates the need to set up separate HTTP servers to check the readiness and availability of containers. Microservices frequently use gRPC for communications and this will allow developers to standardize their stack on gRPC, Laverack said.
Security has taken a giant step forward with the ability to now sign release artifacts with Sigstore. K8s users can now sign their software components, ensuring they haven’t been tampered with.
“This is a huge step in protecting the integrity of the Kubernetes ecosystem and demonstrates that code signing at an enormous scale is possible and frankly necessary due to the increase in supply chain attacks,” said Tracy Miranda, head of open source at Chainguard, who was quoted in a Sigstore blog post announcing the inclusion.
Kubernetes itself is now using SigStore to meet compliance with the Supply-chain Levels for Software Artifacts (SLSA), a security framework to prevent maliciously-minded third parties from tampering with software packages.
For a full rundown of what is new in Kubernetes 1.24, see the release notes here.
A Path Forward
Each release of Kubernetes gets a dedicated release manager. Laverack joined the release team in 2020, before he contributed anything to the codebase. His day job is as a staff solutions engineer for Kubernetes service provider Jetstack. He served as a release team shadow on each release until this one.
“People are interested in joining the release team, we are more than happy to take brand new contributors,” he said.
Cici Huang will lead the release of Kubernetes 1.25, work for which will begin at KubeCon+CloudNativeCon EU this month and be released on or around August 23.
TNS Analyst Lawrence Hecht contributed to this report.
