Kubernetes 1.24 reaches the end of upstream maintenance

Kubernetes 1.24 made a conspicuous runtime compatibility change when it removed dockershim. Reaching that release required some operators to make an explicit decision about the software beneath their pods. On July 28, 2023, a different boundary arrives. The 1.24 release record gives that date as the end of life for the series, after which upstream supplies neither security updates nor bug fixes.

An already running cluster does not gain a new execution failure merely because its support period ends. The change concerns the source of future corrections. Staying on 1.24 now means retaining a version whose upstream maintenance has stopped. That is a separate issue from whether the current workloads are healthy or whether the runtime transition was completed successfully.

I value Kubernetes' ability to keep converging toward declared state after failures. Continued maintenance supports a different requirement, which is correcting the software responsible for that convergence. An operational configuration can remain reproducible while reproducing a release that no longer receives upstream fixes.

Dockershim solved a compatibility problem inside the kubelet

The project's historical explanation of dockershim describes why the adapter existed. Kubernetes initially supported Docker Engine as its container runtime. As runtime choices expanded, the Container Runtime Interface provided a common integration mechanism. Docker Engine predated that interface and did not implement it, so dockershim bridged the gap within the kubelet.

That let operators keep using Docker Engine while Kubernetes adopted CRI. It also left runtime-specific integration code inside a core component. The history article says that this introduced complexity and inconsistent integrations, increasing the maintenance burden. KEP-2221 proposed removal, and Kubernetes 1.20 made the deprecation official before removal arrived in 1.24.

The distinction between Docker Engine and a container image matters here. Removing an adapter for a particular runtime is not a prohibition on images produced by Docker tooling. The historical account explicitly discusses the confusion between the company, the runtime, and image creation. Treating them as interchangeable would turn a runtime integration change into an unsupported claim about application packaging.

Docker and Mirantis continued the adapter's functionality through cri-dockerd, according to that account. Operators who needed Docker Engine still had an integration option outside the kubelet. Others could use runtimes such as containerd or CRI-O. The architectural change moved the vendor-specific bridge out of the Kubernetes component that had carried it.

A completed runtime migration is only one dependency

For a cluster already on 1.24, crossing the dockershim boundary is part of its existing configuration. That does not establish that its next Kubernetes upgrade is complete. Runtime integration and the upstream lifecycle answer different questions. One concerns how the kubelet talks to the runtime, while the other concerns which Kubernetes release series continues to receive corrections.

This distinction also prevents an inaccurate reading of end of life. July 28 does not introduce the dockershim removal. That happened with 1.24 itself. The date ends upstream maintenance for the release series in which removal occurred. An upgrade discussion should therefore begin with the cluster's actual runtime arrangement instead of repeating an earlier migration as if it were a new requirement of this date.

A reproducible installation definition can help make that arrangement inspectable. It needs to describe the runtime connection as well as the Kubernetes version. Knowing only that a machine uses Docker tooling somewhere in its build or operations does not identify the runtime interface its kubelet consumes. The historical confusion around dockershim shows why the component names need to remain precise.

I prefer the CRI boundary because it makes the integration responsibility clearer. Kubernetes can consume a common interface while a runtime or its adapter implements that interface. The cost of maintaining a particular bridge remains real, but it no longer has to appear as special-purpose code embedded in the kubelet.

Support status describes future corrections

The 1.24 release record is explicit that the series no longer receives security updates or bug fixes. That statement describes upstream Kubernetes. It does not establish the contract of a separate vendor, managed service, or support organisation. Any such contract needs its own evidence and should not be inferred from an upstream version number alone.

For someone consuming upstream releases directly, the consequence is straightforward. A supported release is the route to continued upstream maintenance. An existing image or binary remaining available is a different property. Availability of an artifact lets an installation reproduce the old release, but it does not provide a process for issuing new corrections to that series.

That also changes how a frozen version should be documented. Calling the cluster stable can describe observed behaviour, but it says nothing about the maintenance status of its dependencies. A useful operational record identifies both the version that runs and the source of future fixes. After this date, upstream no longer supplies that second property for Kubernetes 1.24.

The runtime decision made by 1.24 persists beyond its support window. CRI remains the integration boundary described by the dockershim history, and Docker Engine can participate through an external adapter. The end-of-life date adds a separate obligation to select a maintained Kubernetes series if continued upstream corrections are required.