Container: Kubernetes beendet den Support für Docker
(Bild: Travel mania/Shutterstock.com)
Die Entscheidung stand schon länger im Raum – seit drei Jahren steht fest, dass Kubernetes den Docker-Daemon nicht mehr unterstützen will. Jetzt tritt es ein.
Ab Kubernetes 1.20, dessen Release am 8. Dezember unmittelbar bevorsteht, erhalten Entwickler eine Deprecation-Warnung für Docker. Docker gilt dann als veraltet (deprecated) und Kubernetes stellt damit offiziell den Support für den Docker-Tech-Stack ein, wie man den Release Notes auf GitHub bereits entnehmen kann.
Aus heiterem Himmel kommt die Nachricht nicht: Das Kubernetes-Entwicklerteam hatte diesen Schritt bereits seit 3 Jahren geplant und vorbereitet, sodass es letztlich nur eine Frage der Zeit war. Da Kubernetes ursprünglich zum Orchestrieren von Docker-Containern entwickelt worden ist, dürfte die Neuigkeit manchen Kubernetes-Nutzer dennoch irritieren.
Auf das Wesentliche konzentrieren
Hintergrund ist offenbar die Aufsplittung des Docker-Ökosystems in zahlreiche Unterprojekte mit kleinteiligen Komponenten, die eine differenzierte Entwicklung durchlaufen. Den Docker-Daemon empfand die Kubernetes-Community als zunehmend aufgebläht, wie Entwicklerin Kat Cosgrove bei Twitter auf den Punkt bringt [1]: "Kubernetes braucht diesen ganzen schicken UX-Kram nicht."
(Bild: Twitter)
Cosgrove differenziert zwischen der Runtime von Docker und Docker als Gesamtpaket, in ihrem mehrteiligen Tweet erläutert sie die Motivation der Entscheidung und beschreibt, welche Auswirkungen die Deprecation auf Cloud-Entwickler hat. Für Kubernetes am wichtigsten sei die Container-Runtime, und hier existiert bereits seit 2018 die alternative High-Level-Runtime Containerd. Da Docker inkompatibel zum Container Runtime Interface (CRI) ist, war stets die Zwischenschicht Dockershim [2] nötig – Containerd empfiehlt sich aber als technisch bessere Lösung.
CRI-O und Containerd unterstützen die Standard-Schnittstelle
Mit der neuen Entwicklung ist laut Cosgrove Docker zwar nicht tot, es funktioniert lediglich nicht mehr als Laufzeitumgebung in Kubernetes. Entwickler müssen mit der nächsten Version zu Containerd wechseln [3]. Einige größere Projekte wie Red Hat und Suse verzichten bereits seit geraumer Zeit auf Docker und setzen auf Alternativen wie CRI-O [4]. Für Kubernetes-Anwender dürfte die Neuerung eine Arbeitserleichterung bedeuten, da künftig schlicht die standardisierte Schnittstelle CRI zur Kommunikation mit der Container-Runtime zum Einsatz kommt. CRI-O und Containerd unterstützen diese Schnittstelle.
Der Deprecation-Hinweis ist auf GitHub in den Release Notes dokumentiert [5]. Mehr Informationen zu den Laufzeitumgebungen für Container lassen sich der Kubernetes-Dokumentation entnehmen [6].
Mehr Informationen rund um Kubernetes, Container und Cloud-native Betriebsmodelle bieten die Konferenzen Continuous Lifecycle und Container Conf mit den Special Days Container Deep Dive [7], Kubernetes Experts Day [8] und Cloud Native Day [9].
(sih [10])
URL dieses Artikels:
https://www.heise.de/-4978841
Links in diesem Artikel:
[1] https://twitter.com/Dixie3Flatline/status/1334188913724850177
[2] https://kubernetes.io/blog/2020/12/02/dockershim-faq/
[3] https://www.heise.de/meldung/containerd-ist-das-fuenfte-Projekt-mit-Graduiertenstatus-in-der-CNCF-4323678.html
[4] https://www.heise.de/meldung/Container-CRI-O-1-18-ueberarbeitet-die-Protokollierung-4710946.html
[5] https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation
[6] https://kubernetes.io/docs/setup/production-environment/container-runtimes/
[7] https://www.containerconf.de/container.php
[8] https://www.containerconf.de/kubernetes_2.php
[9] https://www.containerconf.de/cloud_native.php
[10] mailto:sih@ix.de
Copyright © 2020 Heise Medien