Symbiotische Container-Technologien Kubernetes ohne Docker, geht das?

Anbieter zum Thema

Stäubli TEC-Systems GmbH Connectors

DAXTEN GmbH

EPS Rechenzentrum Infrastruktur GmbH

Es war einmal die Geschichte von Docker, das die Container machte und Kubernetes, das dessen Betrieb managte. Dies ist spätestens mit der Einstellung der Unterstützung der Docker-Runtime durch Kubernetes zumindest in dieser Form vorbei. Wie kam es dazu und was bedeutet das für die Container-Umgebungen?

Obwohl Kubernetes und Docker unterschiedliche Technologien darstellen, ergänzten sie sich eine Zeit lang hervorragend und bildeten eine leistungsstarke Kombination. Docker stellte hierfür die Plattform zur Containerisierung bereit, die es Entwicklerinnen und Entwicklern ermöglichte, Anwendungen in kleine, isolierte Container zu packen.

Developer konnten diese virtualisierten Anwendungen dann in ihrer gesamten IT-Umgebung ausführen, ohne sich Gedanken über Kompatibilitätsprobleme machen zu müssen. Wenn eine Anwendung während des Testens auf einem einzelnen Knoten ausgeführt wird, ließ sie sich auch überall ausführen.

Kubernetes (K8s) stiftete dazu die Orchestrierung von Docker-Containern sowie die Planung und automatische Bereitstellung in allen IT-Umgebungen, um eine hohe Verfügbarkeit sicherzustellen. Neben der Ausführung von Containern bot K8s unter anderem die Vorteile von Lastausgleichen als auch automatisierte Rollouts und Rollbacks. Außerdem verfügt es über eine grafische Benutzeroberfläche für eine einfache Bedienung.

Die wahre Stärke von Kubernetes liegt auch heute noch in seiner nahezu grenzenlosen Skalierbarkeit, Konfigurierbarkeit und seinem reichhaltigen Technologie-Ökosystem, einschließlich vieler Open-Source-Frameworks für Überwachung, Verwaltung und Sicherheit. Kein Wunder, dass sich K8s in den vergangenen Jahren seit seiner Veröffentlichung zum großen Player bei der Container-Orchestrierung mauserte.

Wo es Licht gibt, ist auch Schatten

Docker gehörte zu den ersten Container-Anbietern, die den Developer als Zielgruppe fokussierte. Es wurde eine Lösung angeboten, mit der sich Anwendungen samt allen Abhängigkeiten, jedoch ohne Betriebssystem, bereitstellen ließe. Dabei wurden jedoch hinsichtlich des Designs einige Entscheidungen gefällt, die damals durchaus ihre Berechtigung fanden.

Erst zu einem späteren Zeitpunkt stellten sie sich als eher suboptimal heraus. Ein Beispiel ist die Nutzung des Daemon-Service unter Linux, der mit Kommandozeilen-Werkzeugen gesteuert wird, zur Verwaltung der Container. Auf diese Weise sind einige Sicherheitsprobleme entstanden, weil Daemon als quasi „Super-Admin“ ausgeführt werden muss. Mittlerweile lösen das viele Container-Lösungen ganz anders.

Für eine besser standardisierte und vor allem deutlich sichere Umgebung für Container wurde die Open Container Initiative (OCI) der Linux Foundation aus der Taufe gehoben. Somit steht eine Spezifikation für Container-Umgebungen am Start, an der sich viele neue Lösungen ausrichten können.

Auf diese Weise können Entwickler und Entwicklerinnen schließlich die Lösung wählen, die am besten für die Anwendung passt. Für die Anbindung dieser Lösungen an Kubernetes steht das „Container Runtime Interface using OCI compliant runtimes“ (CRI-O) bereit, was den Umgang mit der jeweils zugrundlegenden Container-Lösung wesentlich vereinfacht.

Das Ende von „Dockershim“

Das heißt konkret: Wenn der Entwickler mit einer OCI-kompatiblen Container-Umgebung nicht mehr arbeiten möchte, so kann er sie sofort austauschen. Ein Schritt in die richtige Richtung. Aber wo ist der Haken? Ganz einfach: Die Spezifikationen passen leider nicht zum alten Klassiker, dem Docker-Container.

Das rührt daher, dass Docker anfangs wegen seiner weiten Verbreitung von Kubernetes unterstützt werden musste, aber nicht für die Einbettung in Kubernetes entwickelt wurde. Die Community um K8s begegnete diesen Problemen in den vergangenen Jahren mit einer Abstraktionsschicht, die sich „Dockershim“ nennt. Diese Schicht berücksichtigt einerseits die Eigenheiten von Docker, aber verbirgt sie hinter der eigentlichen Orchestrierungsschicht.

Bei Kubernetes erscheint daher Dockershim im Prinzip wie jede andere OCI-kompatible Container-Umgebung. Wobei diese Lösung im Hinblick eines zunehmenden und divergierenden Funktionsumfangs von Docker sowie den OCI-Spezifikationen der letzten Jahre zu einem überdimensionalen Wartungsaufwand führte.

Daher entschloss sich das Team um K8s dazu, Dockershim bereits in der Version v1.23 zu entfernen, wodurch die Unterstützung für Docker als Container-Runtime obsolet wurde. Da die Bedeutung von Docker zusehends schwindet, ein zusätzliches Maß an Komplexität nur stört und es letztlich auf eine saubere Funktionalität ankommt, war dieser Schritt nur allzu verständlich.

Wie geht es weiter?

Doch das muss längst nicht das Ende der Welt bedeuten. Zunächst einmal gilt weiterhin: Kubernetes kann ohne Docker funktionieren und Docker arbeitet wunderbar ohne Kubernetes. Docker als zugrunde liegende Runtime wird zugunsten von Runtimes verworfen, die das für Kubernetes erstellte Container Runtime Interface (CRI) verwenden. Docker-produzierte Images funktionieren weiterhin in dem Cluster mit allen Runtimes.

Die Anwender müssen im Wesentlichen nur die Container-Runtime von Docker auf eine andere kompatible Container-Runtime wie beispielsweise containerd oder CRI-O wechseln. Wenn ein Cluster genutzt wird, der bereits von großen Cloud-Anbietern wie zum Beispiel GKE, EKS oder AKS (standardmäßig containerd) bereitgestellt wurde, oder wenn der Anwender lediglich ein Kubernetes-User ist, hat dies quasi keine Auswirkungen auf ihn.

Die Verwerfung von Kubernetes bedeutet demnach nicht das völlige Aus von Docker, oder dass Docker nicht mehr als Entwicklungstool verwenden werden kann oder sollte. Docker ist nach wie vor ein nützliches Tool zum Erstellen von Containern. Die aus der Ausführung resultierenden Images „docker build“ können weiterhin in einem Kubernetes-Cluster ausgeführt werden.

(ID:48172734)