Container-Laufzeiten im Überblick, Teil 3 High-Level Container Runtimes – eine Stufe höher

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

High-Level Container Runtimes sind die großen Schwestern der Low-Level Container Runtimes: Sie umfassen deutlich mehr Funktionen und sind dadurch einfacher zu verwalten und für komplexere Anwendungen geeignet.

Container-Runtimes sind grob in drei Klassen aufgeteilt: Low-Level Container Runtimes, High-Level Container Runtimes und, als Extra, Virtualisierungsumgebungen. Tatsächlich sind High-Level Container Runtimes eine deutlich komplexere und funktionalere Methode, Container für die Software-Entwicklung oder Anwendungen zu erstellen, als es bei Low-Level-Containern der Fall ist.

Letztere beschränken sich vor allem auf das Zusammenpacken von einheitlichen Laufzeit-Umgebungen. High-Level Container Runtimes bieten im Gegensatz dazu Möglichkeiten, diese Runtimes auch sinnvoll miteinander zu verknüpfen und effizienter zu nutzen, kurzum: zu verwalten.

Was leistet eine High-Level Container Runtime?

Containerd (Docker) oder CRI-O (Kubernetes) sind High-Level Container Runtimes. Das bedeutet zunächst nur, dass diese Runtimes nicht nur das Softwarepaket als Container schnüren und laufen lassen, wie es bei einer Low-Level-Runtime der Fall ist. Vielmehr bieten sie auch Schnittstellen und Management-Möglichkeiten für die Verarbeitung dieser Container an. Das bedeutet im Umkehrschluss, dass High-Level Container Runtimes auch eine Low-Level-Runtime einschließen.

Docker/Containerd und CRI-O „beherbergen“ sozusagen bereits mit den Low-Level Runtimes erstellte Container und ergänzen sie um weitere Funktionen wie einen Daemon, Image-Verwaltung, Netzwerkdienste oder zusätzliche APIs für den Einsatz mit anderen Anwendungen und Diensten. Neben Containerd und CRI-O gibt es noch Pouch von Alibaba oder Linux Containers – doch diese sind in Sachen Verbreitung im Vergleich zu Containerd und CRI-O zu vernachlässigen. Die Alternative Frakti wurde Anfang November 2022 gar eingestellt.

Wo liegt der Unterschied zwischen Docker/Containerd und CRI-O?

Als Container-Verwaltungen verfolgen die beiden High-Level Container Runtimes Containerd und CRI-O unterschiedliche Ansätze. CRI-O hat seine Wurzeln im Kubernetes-System: Ursprünglich nutzte Kubernetes hauptsächlich Docker für das Container-Management, allerdings entwickelte sich nach und nach der Bedarf, auch andere Lösungen wie rkt in Kubernetes einzusetzen. Das machte die Dinge allerdings kompliziert.

CRI-O wurde deshalb sowohl mit dem inzwischen einheitlichen Container Runtime Interface (CRI) als auch mit der OCI-kompatiblen (Open Container Initiative) Runtime entwickelt wurde, um die Einbindung von Nicht-Docker-Lösungen zu erleichtern. Containerd ging als Reaktion darauf aus dem monolithischen Docker-System hervor, das dieses ebenfalls modular aufteilte und CRI-kompatibel gestaltete. Da inzwischen auch Docker CRI und OCI beherrscht, sind Entwickler und Nutzer in der Wahl der jeweiligen Umgebung frei.

Technische Unterschiede zwischen CRI-O und Containerd

Obwohl beide High-Level Container Runtimes im Endeffekt durchaus ähnlich funktionieren, haben beide Lösungen gewisse Vor- und Nachteile. So hat Containerd den großen Vorteil, dass es auf allen Betriebssystemen einsetzbar ist. Es liefert einen Layer, der die in den jeweiligen Systemen vorhandenen Basisfunktionen einsetzt, um ein homogenes „Systemerlebnis“ unabhängig von der verwendeten Plattform zu bieten.

Das macht Containerd auch für Cloud-native-Anwendungen interessant. Auf der anderen Seite sind Containerd-Container auf den Einsatz von runC als Low-Level Container Runtime beschränkt. Dadurch ergibt sich bei Containerd aber eine gewisse „Masse“, die bei CRI-O nicht vorhanden ist: Die auf Leichtigkeit und ein Plug-In-System getrimmte Open-Source-Runtime ist zwar auf Unix-Umgebungen angewiesen, ist dafür aber optimal auf das Zusammenspiel mit Kubernetes abgestimmt.

Der Overhead der Docker-basierten Lösungen wird dadurch vermindert, was der Performance zuträglich ist. Der Unterschied ist aber laut einer Performance-Evaluierung der TU München marginal: „Die Evaluierungsergebnisse zeigen, dass crio/runc die beste Startoption für fast jeden Anwendungsfall ist, während containerd/runc sich bei I/O-lastigen Workloads als besonders leistungsstark erweist.“

Welches wählen?

Das muss Nutzer und Entwickler aber nicht belasten. Grundsätzlich ist es nämlich möglich, nachträglich von einer Container-Runtime in die andere zu wechseln: Wer seine Container etwa vom Docker-System auf Containerd oder CRI-O umstellen will, kann das zumeist mit wenigen Handgriffen in der Kommandozeile erledigen.

Wer sich mit den High-Level Container Runtimes befasst, sollte sich aber vorab im Klaren darüber sein, wie und wo diese eingesetzt werden sollen. Geht es um lokale und netzwerkweite Verwendung oder um die Weitergabe an Entwickler und Kunden, so kann es sinnvoll sein, auf die Docker-Technologie Containerd zu vertrauen. Soll hingegen Kubernetes bespielt werden, kann der Einsatz von CRI-O sinnvoller sein.

(ID:48961402)