Das steckt da wirklich hinter
Vor ein paar Tagen stieß ich auf einen Artikel mit dem verwirrenden Titel „What Does Kubernetes’ Docker Deprecation Mean for Users“ oder zu deutsch „Was bedeutet die Abkündigung von Docker in Kubernetes für Benutzer?“. Der Artikel impliziert, dass eine Microservice Architektur auf der Basis von Docker nicht mehr auf einem Kubernetes Cluster läuft. Wirklich?
Nein, grundsätzlich hat das keine Auswirkungen auf die Architektur. Im dem Artikel geht es lediglich darum, dass die Art und weise, wie die Container mittels `dockershim` erzeugt werden, und dass dieser dockershim support abgekündigt ist. Der Artikel hat eine schöne Übersicht, was sich für den Nutzer tatsächlich ändert, außer nichts.
* Docker-Images funktionieren weiterhin so wie sie in den bestehenden und neuen Kubernetes-Clustern sind.
* Sie können Docker weiterhin verwenden, um auf Ihren weniger kritischen Stacks und auf Ihren persönlichen Computern zu testen, um sicherzustellen, dass alles funktioniert.
* Images, die mit Docker-Build erstellt wurden, funktionieren auch über Cluster hinweg.
* Public Cloud-Lösungen wie AKS von Azure und EKS/ECS von AWS müssen zu einer unterstützten Containerlaufzeit migrieren, bevor Kubernetes die Unterstützung für Docker entfernt.
* Systeme, die Docker-Sockets in ihrem Workflow verwenden, brechen ab, daher ist es wichtig, auf andere Optionen wie kaniko, buildah oder img zu migrieren.
dockershim und containerd
Dockershim ist die CRI-konforme Schicht zwischen dem Kubelet und dem Docker-Daemon. Es geht hier also um den Docker Daemon, der die Instanzen der Container erzeugt und verwaltet. Dazu zählt zum Beispiel das Verwalten der Layer, also den schreibgeschützten Schichten der sukzessive Änderungen am Dateisystem des Images.
Kubernetes dient dazu, die Container Runtimes zu bedienen und arbeitet dafür mit einem Container Runtume Interface (CRI). Um direkt mit der docker API zu arbeiten wird ein shim benötigt, das dockershim.
Ein sehr guter Artikel dazu findet sicher hier.
Containerd ist ein Linux Daemon, der direkt container starten und verwalten kann. Es entfällt also eine Zwischenschicht bei der Interaktion zwischen Kubernetes und Docker Images und Containern.
Docker Desktop und Kubernetes
Wer jetzt schon Docker Desktop und containerd verwenden möchte, findet hierzu in den „Experimental Features“ die Option. Der Blog Artikel von Docker zu diesem Thema findet sich hier.
In dem Blog von Kubernetes findet sich auch eine entsprechende Readmap über die Timeline zum Entfernen von dockershim support. Der Artikel findet sich hier.
Fazit
Das Ziel, dockershim zu entfernen ist primär, is es den Code zu verschlanken und in die Jahre gekommene Bibliotheken und veralteten Support zu entfernen. Für eine Cloud-ready Softwareentwicklung änder sich erst mal nix.
Schreibe einen Kommentar