Kubernetes 1.26 completes switch to Container Runtime Interface

The Kubernetes development team has released version 1.26 of the container orchestration platform – codenamed Electrifying. Several innovations in the release are particularly related to the introduction of the Container Runtime Interface (CRI), now used in the stable version 1.0, and changes to the new container image registry. registry.k8s.io,

Fixture: Container Runtime Interface v1

In the Stargazer release (Kubernetes 1.24), the development team finally said goodbye to Dockershim to clear the way for CRI-compatible container runtimes such as CRI-O and containerd. Although the Container Runtime Interface was still used in version v1alpha2, with the release of Kubernetes 1.26 the stable CRI release v1 has now become the standard. However, this also means that support for containerd 1.5 and earlier is no longer available, as kubelet no longer registers nodes if the container runtime is not fully compatible with CRI v1.

Meanwhile, CRI v1 also gives developers the opportunity to gain easy and full access to container metrics and eliminate their previous reliance on cAdvisor. As of Kubernetes 1.26, metrics recorded in /metrics/cadvisor no longer come from cAdvisor, but directly from the container runtime interface. that are in issue #2371 cAdvisor-less, CRI-full container and pod statistics However, for the time being, the crafted expansion is still considered alpha.

To enable users to perform faster downloads and to be able to distribute the load across multiple cloud providers and regions, the Kubernetes development team introduced a change to the container image registry in release 1.25 (Combiner). New registry.k8s.io Already generally available and now standard. Images for Kubernetes releases 1.22, 1.23, 1.24 and 1.25 that are still in support can still be downloaded from the previous registry k8s.gcr.io should be received – all new since 1.26 registry.k8s.io reserved.

More Security: Sign Artifacts With Cosines

Kubernetes takes another step towards greater security by signing binary artifacts. The official container images were already signed in the 1.24 and 1.25 releases. With Kubernetes 1.26, the cosine signing process has been extended to all client, server, and source code tarballs, binary artifacts, software bills of materials (SBOMs), and build origins. More information about this beta feature can be found here In a separate announcement by the Kubernetes Special Interest Group (SIG),

Interested parties can find a comprehensive overview of all the changes in Kubernetes 1.26 In blog post for Electrify release as well as in Change log in GitHub repo render.

(Map)