Das Dockershim-Maintainance-Ende hat Konsequenzen für Entwickler, die Docker in ihren Kubernetes-Clustern nutzen.(Foto: Sheila Fitzgerald/Shutterstock)
Der Changelog zum Kubernetes-Projekt auf GitHub verkündet das Support-Ende für Docker. Ab Version 1.21 erhalten Kubernetes-Nutzer, die Docker verwenden, eine Deprecation-Warnung.
Zugunsten von kompatibleren Runtimes verabschiedet sich Kubernetes voraussichtlich mit Version 1.23 von der Docker-Runtime. „Kompatibler“ meint in dem Fall Laufzeitumgebungen, die das Kubernetes Container Runtime Interface – kurz CRI – nutzen. Was das für Kubernetes-Endnutzer bedeutet? Zunächst nicht allzu viel. Via docker build produzierte Images werden weiterhin wie gehabt innerhalb der Cluster funktionieren.
Nutzer mit eigenen Clustern müssen wechseln
Für Nutzer eines verwalteten Kubernetes-Dienstes wie GKE oder EKS sieht das schon anders aus. Ihnen empfiehlt der Kubernetes-Blog die baldige Migration der Worker-Nodes auf eine der unterstützten Container-Runtimes. Im Zuge dessen kann es sein, dass möglicherweise vorhandene Node-Anpassungen entsprechend der Anforderungen der neuen Umgebung angepasst werden müssen.
Auch Kubernetes-User mit eigenen Clustern müssen Anpassungen vornehmen, um zu vermeiden, dass die Cluster mit dem Upgrade auf Kubernetes 1.23 zusammenbrechen. Bei der Auswahl einer kompatiblen Alternative sollten Entwickler ein Augenmerk darauf haben, dass der kompatible Ersatz – zum Beispiel containerd oder CRI-O – die aktuellen docker daemon-Konfigurationen des eigenen Clusters unterstützt.
Docker ist nicht für CRI-kompatibel
Eine Twitter-Userin hat es in einem vielbeachteten Thread wie folgt zusammengefasst: „Viele Entwickler denken Docker = Kubernetes. Das stimmt nicht.“ Daher komme jedoch die allgemeine Verwirrung um die Ankündigung des Support-Endes. Die Container-Runtime – zum Beispiel Docker, Containerd oder CRI-O – befindet sich innerhalb eurer Kubernetes-Cluster. Sie ist dafür verantwortlich, Container-Images zu erstellen und auszuführen. Unter Entwicklern ist Docker zwar eine beliebte Wahl, die Runtime wurde jedoch, anders als die genannten Alternativen, nicht für die Einbettung in ein Kubernetes-Cluster entworfen.
Maintainance-Ende für Dockershim
„Was gemeinhin ‚Docker‘ genannt wird, ist nämlich nicht nur eine Runtime, sondern ein kompletter Techstack“, schreibt die Twitter-Userin weiter. Eine Komponente davon ist containerd – eine CRI-kompatible Container-Laufzeitumgebung. Docker bringt ansonsten eine Reihe von UX-Erweiterungen mit, die Entwicklern den Umgang mit dem Tool drastisch erleichtern. Um Container-Images innerhalb eines Clusters auszuführen, braucht Kubernetes dieses Interface nicht. Damit Kubernetes von containerd – der dafür notwendigen Docker-Komponente – Gebrauch machen kann, braucht es ein weiteres Tool. Dieses Tool heißt Dockershim. Ab Version 1.23 soll Dockershim nicht länger gewartet werden. Als Grund führen die Maintainer den erheblichen Mehraufwand der Wartung eines zusätzlichen Tools an. In der Konsequenz bleibt Docker-Verwendern schlussendlich nur der Wechsel zu einer anderen, CRI-kompatiblen Runtime.
