Kubernetes 1.26 vollendet den Wechsel auf das Container Runtime Interface

Das Kubernetes-Entwicklungsteam hat Version 1.26 der Container-Orchestrierungsplattform vorgelegt – Codename Electrifying. Die zahlreichen Neuerungen im Release betreffen insbesondere die Einführung des Container Runtime Interface (CRI), das ab sofort in der stabilen Version 1.0 zum Einsatz kommt, sowie den Wechsel auf die neue Container Image Registry registry.k8s.io.

Stabilität: Container Runtime Interface v1

Im Stargazer-Release (Kubernetes 1.24) hatte das Entwicklungsteam den endgültigen Abschied von der Dockershim vollzogen, um den Weg freizumachen für CRI-kompatible Container Runtimes wie CRI-O und containerd. Das Container Runtime Interface kam zuletzt jedoch noch immer in der Version v1alpha2 zum Einsatz, mit Freigabe von Kubernetes 1.26 avanciert nun das stabile CRI-Release v1 zum Standard. Damit einhergehend entfällt allerdings auch der Support für containerd 1.5 und ältere Versionen, da Kubelet keine Nodes mehr registriert, sofern die Container-Runtime nicht vollständig kompatibel zu CRI v1 ist.

Entwicklerinnen und Entwicklern eröffnet CRI v1 unterdessen auch die Möglichkeit, einfacheren und vollständigen Zugriff auf Container-Metriken zu erlangen und die bisherige Abhängigkeit vom cAdvisor zu beenden. Die in /metrics/cadvisor erfassten Metriken stammen ab Kubernetes 1.26 nicht mehr vom cAdvisor, sondern direkt vom Container Runtime Interface. Die im Issue #2371 cAdvisor-less, CRI-full Container and Pod Stats formulierte Erweiterung gilt vorläufig aber noch als Alpha.

Um Nutzern und Nutzerinnen schnellere Downloads zu ermöglichen und darüber hinaus auch Lasten über mehrere Cloud-Anbieter und Regionen verteilen zu können, hatte das Kubernetes-Entwicklungsteam im Release 1.25 (Combiner) den Wechsel der Container Image Registry eingeleitet. Die neue registry.k8s.io ist bereits generell verfügbar und gilt ab sofort als Standard. Images der noch unter Support stehenden Kubernetes-Releases 1.22, 1.23, 1.24 und 1.25 können vorläufig noch aus der bisherigen Registry k8s.gcr.io bezogen werden – alle neueren ab 1.26 sind registry.k8s.io vorbehalten.

Mehr Sicherheit: Artefakte mit cosign signieren

Einen weiteren Schritt hin zu mehr Sicherheit vollzieht Kubernetes durch das Signieren der Binary-Artefakte. Offizielle Container Images wurden bereits in den Releases 1.24 und 1.25 signiert. Mit Kubernetes 1.26 wurde der cosign-Signierprozess auf alle Client-, Server- und Quellcode-Tarballs, Binary-Artefakte, Software Bills of Material (SBOMs) sowie den Build-Ursprung ausgeweitet. Weitergehende Informationen zu dieser im Betastatus befindlichen Funktion finden sich in der separaten Ankündigung der Kubernetes Special Interest Group (SIG).

Lesen Sie auch

KubeCon 2022: Kubernetes soll sicherer werden

Einen umfassenden Überblick sämtlicher Änderungen in Kubernetes 1.26 können sich Interessierte im Blogbeitrag zum Electrifying-Release sowie im Change-Log im GitHub-Repo verschaffen.

(map)