Ab Version 1.20 löscht Kubernetes Docker als Container-Laufzeit.
Aber keine Panik. Nicht alles ist so schlecht, wie es auf den ersten Blick scheint.
TL; DR. Kubernetes verzichtet auf Docker zugunsten von CRI-Laufzeiten ( Container Runtime Interface ), die speziell für Kubernetes entwickelt wurden. Docker-Images funktionieren zu allen Laufzeiten wie gewohnt weiter.
Für Kubernetes-Endbenutzer wird sich wenig ändern. All dies bedeutet nicht, dass Docker "stirbt" oder dass es nicht mehr für die Entwicklung verwendet werden sollte / sollte. Docker wird weiterhin ein großartiges Tool zum
docker build
Erstellen von Containern sein, und damit erstellte Images werden weiterhin auf dem K8s-Cluster ausgeführt.
Wenn Sie verwaltete Kubernetes-Dienste wie GKE oder EKS verwenden, sollten Sie sicherstellen, dass Ihre Mitarbeiter eine unterstützte Version der Laufzeit verwenden, bevor Sie die Docker-Unterstützung in einer zukünftigen Version von K8s entfernen. Wenn Ihre Knoten über bestimmte Konfigurationen verfügen, müssen Sie höchstwahrscheinlich ein Upgrade durchführen, um die entsprechenden Umgebungs- und Laufzeitanforderungen zu erfüllen. Wir empfehlen, dass Sie sich an Ihren Diensteanbieter wenden und alle Test- und Upgradeplanungsprobleme besprechen.
Wenn Sie die Cluster selbst ausrollen, müssen Sie auch die entsprechenden Änderungen vornehmen, um Probleme zu vermeiden. Beim Upgrade auf Version 1.20 erhalten Sie eine Docker-Verfallswarnung. Entwickler planen, Docker in Version 1.23, deren Veröffentlichung für Ende 2021 geplant ist, vollständig aufzugeben. Mit der Veröffentlichung müssen Sie zu einer der kompatiblen ausführbaren Umgebungen wechseln, z. B. Containerd oder CRI-O. Stellen Sie einfach sicher, dass die von Ihnen ausgewählte Umgebung die von Ihnen verwendeten Docker-Dämonkonfigurationen unterstützt (z. B. Protokollierung).
Worum geht es in dieser Verwirrung und warum sind alle so besorgt?
Tatsächlich handelt es sich um zwei völlig unterschiedliche Umgebungen, was zu Verwirrung führt. Innerhalb des Kubernetes-Clusters gibt es eine sogenannte Container-Laufzeit , die für das Laden und Ausführen von Container-Images verantwortlich ist. Und Docker ist als Tool zum Organisieren dieser Umgebung sehr beliebt (Containerd und CRI-O sind ebenfalls weithin bekannt). Docker wurde jedoch nicht für die Einbettung in Kubernetes entwickelt, was eine Reihe von Problemen aufwirft.
"Docker" ist kein separates Tool, sondern ein ganzer Technologie-Stack, und eine seiner Komponenten heißt "Containerd" (wir haben hier ausführlicher darüber geschrieben - ca. Transl.)und fungiert als allgemeine Laufzeit für Container. Docker ist beliebt und praktisch, da es eine große Anzahl von Add-Ons für Benutzer gibt, die die Interaktion mit diesem Tool während der Entwicklung erheblich vereinfachen. Alle diese UX-Verbesserungen werden von Kubernetes jedoch nicht benötigt, da er kein Mensch ist.
Diese benutzerfreundliche Abstraktionsebene zwingt den Kubernetes-Cluster, ein anderes Tool, Dockershim, zu verwenden, um das zu erreichen, was es wirklich benötigt: Containerd. Und das ist schlecht, da eine solche zusätzliche Schicht gewartet werden muss und auch "brechen" kann. In Wirklichkeit stellt sich Folgendes heraus: In Kubernetes v1.23 wird Dockershim aus Kubelet entfernt - dementsprechend verliert Docker die Unterstützung als Container-Laufzeit. Es stellt sich die Frage: Wenn Containerd bereits im Docker-Stack enthalten ist, warum benötigt Kubernetes Dockershim?
Der Punkt ist, dass Docker nicht mit der Container Runtime-Schnittstelle kompatibel ist .(CRI). Wenn es kompatibel wäre, würden wir keine zusätzliche Schicht benötigen und alles wäre großartig. Dies ist jedoch nicht das Ende der Welt und kein Grund zur Panik. Ersetzen Sie einfach die Docker-Laufzeit durch eine unterstützte.
Beachten Sie, dass Sie
/var/run/docker.sock
nach dem Wechsel in eine andere Umgebung nicht mehr damit arbeiten können , wenn Sie Docker's socket ( ) als Teil eines normalen Workflows verwenden. Dieses Muster wird oft als "Docker in Docker" bezeichnet. Es gibt viele verschiedene Tools arbeiten , um dieses Problem, einschließlich Kaniko , img, und buildah .
Wie wird sich diese Änderung auf die Entwickler auswirken? Schreiben wir noch Dockerfiles? Sollen wir Bilder mit Docker erstellen?
Bei dieser viel diskutierten Änderung handelt es sich um eine völlig andere Umgebung als die, mit der die meisten Menschen mit Docker interagieren. Die Installation von Docker für die Entwicklung hat nichts mit der Laufzeit im Kubernetes-Cluster zu tun. Ja, das ist verwirrend, ich weiß ...
Auch nach der Innovation wird Docker das gleiche nützliche Werkzeug für Entwickler bleiben. Von Docker generierte Bilder können mit mehr als nur Docker arbeiten. Dies sind vollständige OCI-Bilder. Jedes OCI-kompatible Image sieht auf Kubernetes unabhängig vom Tool, mit dem es erstellt wurde, gleich aus. Containerd und CRI-O können diese Bilder hervorragend abrufen und ausführen. Aus diesem Grund wurde der Containerstandard erstellt.
Es kommen also Veränderungen. Einige Leute werden natürlich auf bestimmte Probleme stoßen. Aber es gibt nichts zu bereuen oder sich Sorgen zu machen, denn Fortschritt ist eine coole Sache. Je nachdem, wie Sie Kubernetes verwenden, kann dies für Sie entweder völlige Untätigkeit oder einen minimalen Aufwand bedeuten. Langfristig wird eine solche Innovation die Dinge nur einfacher machen.
Wenn die bevorstehenden Änderungen Sie immer noch verwirren, geht es Ihnen gut. Es gibt viele bewegliche Teile in Kubernetes, und niemand ist 100% Experte darin. Bitte zögern Sie nicht, Fragen zu stellen, unabhängig von Erfahrung oder Schwierigkeitsgrad! Unser Ziel ist es, alle so gut wie möglich auf die bevorstehenden Veränderungen vorzubereiten. <3 Wir hoffen, dass dieser Beitrag die meisten Ihrer Fragen beantwortet und alle Bedenken und Bedenken ausgeräumt hat!
Benötigen Sie weitere Antworten? Lesen Sie die häufig gestellten Fragen zur Dockershim-Ablehnung .
PS vom Übersetzer
Eine ausführliche Antwort von Tim Hockin , einem der Kubernetes-Entwickler, finden Sie auch in der Diskussion zu diesem Thema auf Reddit .
Lesen Sie auch in unserem Blog: