Wird der veraltete Docker durch Podman ersetzt?

Das Kubernetes-Team hat vor Kurzem angekündigt, dass die von Docker in der neuesten Version unterstützten Funktionen veraltet sein werden und in nachfolgenden Versionen entfernt werden.

Kürzlich hat das Kubernetes-Team die neueste Version 1.20 veröffentlicht, die viele Inhalte aktualisiert:

Die Speichervolumen-Snapshot-Funktion ist stabil geworden; Kubectl Debug ist in die Beta eingetreten; Beta: API-Priorität und Fairness; IPV4/IPV6 Alpha-Funktionsupdate; GA: Prozess-PID begrenzen; Dockershim ist veraltet; Exec-Probe-Timeout-Verarbeitung usw. (Weitere Einzelheiten finden Sie unter: https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/ )

Darunter befindet sich ein Update, das für die Entwickler-Community zweifelsohne ein Knaller ist: die offizielle Ankündigung der Abkündigung von Features, die von Docker unterstützt werden. Warum also macht Kubernetes dies und welche Auswirkungen wird es haben?

Docker ist eine Möglichkeit, Anwendungen in Containern zu verpacken, zu verteilen und bereitzustellen. Seit seiner Erstveröffentlichung am 13. März 2013 hat sich Docker zum De-facto-Standard in der Containerbranche entwickelt. Kubernetes ist ein von Google entwickeltes Open-Source-Container-Orchestrierungssystem.

Kubernetes-Architekturdiagramm, aus Wikipedia

Docker und OpenShift

Auf dem Summit 2015 veröffentlichte Red Hat OpenShift V3.0. Diese neue Version von OpenShift verwendet Docker-Container auf der untersten Ebene und beginnt, Kubernetes zur Orchestrierung von Images zu verwenden. Während des Red Hat Summit 2016 startete Docker jedoch einen scharfen Angriff auf Red Hats OpenShift. Sie haben nicht nur den folgenden Tweet gepostet, sondern auch T-Shirts mit der Aufschrift „Wir akzeptieren keine Imitationen“ an die Teilnehmer verteilt:

Offensichtlich macht sich der künstliche Wal auf der linken Seite über OpenShift von Red Hat lustig. Zu dieser Zeit verwendete OpenShift Docker-basierte Container. Der von Red Hat veröffentlichte Docker hinkt im Allgemeinen der Originalversion etwas hinterher, und um sogenannten „Enterprise-Support“ bereitzustellen, hat Red Hat das Verhalten zum Patchen der alten Docker-Version übernommen. Im Gegensatz dazu veröffentlicht Docker immer die neueste Version.

Natürlich gibt es immer noch unterschiedliche Meinungen darüber, ob Unternehmensanwendungen durch Upgrades oder Portierungen von Patches gewartet werden sollten, daher werde ich diesen Punkt hier nicht kommentieren, aber das Verhalten von Docker auf Red Hats eigenem Gipfel ist in der Tat etwas unerwartet. Ich muss zugeben, dass Docker vorher eine großartige Technologie war, schließlich war es ein wichtiger Teil von RedShift, aber von diesem Tag an begannen die Dinge schief zu laufen.

Plattformkriege

Zu den frühen PaaS-Plattformen gehörten hauptsächlich OpenShift sowie die beiden Konkurrenten Docker und Pivotal. Docker ist jedem bekannt, mehr muss man dazu also nicht sagen. Pivotal ist ein 2013 von EMC und VMware gegründetes Unternehmen, das sich auf Open-Source-PaaS-Lösungen konzentriert. Ihre Unternehmenslösung war aus einem einfachen Grund sehr erfolgreich: Das Benutzererlebnis ist großartig, insbesondere in Kombination mit Pivotal Labs.

Docker ist ein aufsteigender Stern bei Unternehmenslösungen. Sein Vorteil besteht darin, dass Entwickler bereits mit der Docker-Engine vertraut sind. Zu diesem Zeitpunkt war Kubernetes nirgends zu finden. Der Angriff von Docker auf OpenShift zwang Red Hat jedoch dazu, Ressourcen in Kubernetes zu investieren. Später haben alle die Ergebnisse gesehen. Kubernetes war ein großer Erfolg und hat die Unterstützung der gesamten Branche gewonnen.

Zu diesem Zeitpunkt startete Docker Docker Swarm, um die Situation zu retten, aber es war zu spät. In der zweiten Hälfte des Jahres 2016 überholte Kubernetes Docker Swarm und wurde zum De-facto-Standard in der Branche. Letztendlich konnte Docker Swarm Kubernetes keinen Abbruch tun. Dies kann als erster Tod von Docker angesehen werden. Von da an ist Docker keine PaaS-Lösung auf Unternehmensebene mehr und kann nur noch als Teil des Cloud-native-Systems existieren. Glücklicherweise war es schon immer ein wichtiger Teil von Kubernetes.

Kubernetes kündigt die Abschaffung von Docker an

Kubernetes hat kürzlich angekündigt, dass Docker veraltet sein wird.

(Offizieller Blog-Link: https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/):

Dies ist zweifellos die zweite Ankündigung des Todes von Docker. Laut Kubernetes selbst ist Docker keine notwendige Technologie mehr, sondern zu einer technischen Schuld geworden. Kubernetes-Versionen vor 1.19 mussten über ein Modul namens Dockershim eine Verbindung zu Docker herstellen und Docker dann mit Containerd verbinden, um Container zu erstellen. Technisch gesehen ist Containerd und nicht Docker die eigentliche Containerlaufzeit. Die Rolle von Docker besteht lediglich darin, Container auf Containerd zu erstellen. Für einen menschlichen Benutzer ist es sehr praktisch, einen Container zu erstellen, indem man einfach einen Docker-Lauf ausführt. Obwohl dies praktisch ist, bringt Docker jedoch auch viele nutzlose Vorgänge und technische Schulden mit sich, was eine Belastung für Kubernetes darstellt. Kubernetes kann Docker vollständig umgehen und Container auf Containerd erstellen, um denselben Effekt zu erzielen. Dieser Ansatz wurde in Kubernetes 1.20 übernommen.

Obwohl das Geschäftsmodell von Docker gescheitert ist, müssen wir den großen Beitrag anerkennen, den Docker zur gesamten Branche geleistet hat. Die von Docker bereitgestellte Technologie ist die beste der Branche. Bis heute basiert unser CI/CD-System stark auf Docker. Ohne Docker hätte es keinen Erfolg von Kubernetes gegeben, und Kubernetes steht immer noch im Schatten von Docker.

Aber keine Sorge, das Kubernetes-Team hat viel Arbeit investiert, um den Upgrade-Prozess so reibungslos wie möglich zu gestalten. Selbst wenn Sie auf 1.20 aktualisieren, erhalten Sie nur eine Warnung, dass Docker veraltet ist. Der aktuelle Plan für Kubernetes sieht vor, die Docker-Unterstützung in 1.22, das Ende 2021 veröffentlicht wird, vollständig zu entfernen, sodass Entwickler bis dahin auf andere Container-Runtimes wie Containerd oder CRI-O umsteigen müssen.

Alternativen zu Docker

Nachdem Docker aufgegeben wurde, begannen die Entwickler, Alternativen zu diskutieren, unter denen Containerd und Podman mit großer Spannung erwartet wurden.

Containerd ist eine branchenübliche Container-Laufzeitumgebung, bei der Einfachheit, Robustheit und Portabilität im Vordergrund stehen. Es kann den Lebenszyklus von Containern verwalten, von Projekten wie Kubernetes CRI verwendet werden und den Grundstein für eine umfassende Branchenzusammenarbeit legen.

Podman war ursprünglich Teil des CRI-O-Projekts, wurde aber später in ein separates Projekt namens libpod ausgegliedert. Die Benutzererfahrung von Podman ähnelt der von Docker, außer dass Podman keinen Daemon hat. Der Container wird direkt über die OCI-Runtime (standardmäßig auch runc) gestartet, daher ist der Containerprozess ein untergeordneter Prozess von Podman. Dies ähnelt eher dem Fork/Exec-Modell von Linux, während Docker das C/S-Modell (Client/Server) verwendet.

Obwohl Docker immer noch einen großen Anteil am aktuellen Containermarkt einnimmt, ist sein Schicksal, aufgegeben zu werden, sicher. Während dieser Übergangsphase können Sie Containerd und Podman genauso gut annehmen!

Damit schließen wir den Artikel „Wird der veraltete Docker durch Podman ersetzt?“ ab. Dies ist das Ende des Artikels. Weitere Informationen zum Ersatz von Podman durch Docker finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!