Die Unterschiede zwischen Docker, containerd, CRI-O und runc

Der Aufstieg von Docker führte zu einem explosionsartigen Anstieg der Popularität von Containern. Seitdem gibt es eine wachsende Anzahl von Tools und Standards, die dabei helfen sollen, die Nutzung dieser Technologie zu reglementieren.

Leider ist es ziemlich schwierig, mit der Entwicklung Schritt zu halten. Die „Kämpfe“ zwischen den großen Technologieunternehmen tragen bei vielen von uns ebenso zur Verwirrung bei.

In diesem Artikel werde ich alle wichtigen Namen angehen, die Sie bereits gehört haben und versuchen, den Fachjargon für Sie zu entschlüsseln und zu erklären, wie das Container-Ökosystem im Jahr 2021 zusammenarbeitet.

Und wenn Sie denken, dass Sie der Einzige sind, der das alles noch nicht versteht, machen Sie sich keine Sorgen... Sie sind nicht allein!

 

Docker verstehen

Es gibt einen Unterschied zwischen Docker (Unternehmen), Docker-Containern, Docker-Images und den Docker-Entwicklertools, an den wir alle gewöhnt sind:

Joe Beda Twitter

Quelle: https://twitter.com/jbeda

Wie Sie sehen, sind Sie nicht der Einzige, der verwirrt ist. Joe Beda, der Mitentwickler von Kubernetes, sieht es genauso.

Dies ist eine perfekte Gelegenheit, einige der Verwirrungen zu klären und Ihnen zu helfen, zu verstehen, wann es sich um Docker, containerd oder CRI-O handelt. Dies ist besonders wichtig, wenn Sie sich mit dem Thema Kubernetes beschäftigen wollen.

Wichtig ist, dass Sie sich folgendes merken:

Die Container sind nicht mehr fest mit dem Namen Docker verbunden. Es gibt eine ganze Reihe von Container-Tools. Der Docker ist eins davon, und Docker (das Unternehmen) unterstützt einige von denen, aber nicht alle.

Wenn Sie immer noch denken, dass es sich bei Containern nur um Docker handelt, dann lesen Sie weiter! Wir werden uns nun das Ökosystem rund um Container genauer anschauen.

 

Ein Überblick über das Container-Ökosystem

Das Container-Ökosystem setzt sich aus vielen Technologien, Fachterminologien und miteinander konkurrierenden Unternehmen zusammen. Glücklicherweise verhandeln Unternehmen manchmal einen fragilen Waffenstillstand, um sich auf bestimmte Standards zu einigen. 

Diese Standards helfen, die Interoperabilität zwischen verschiedenen Tools zu erreichen und die Abhängigkeit von einem bestimmten Unternehmen oder Projekt (Technologie) zu vermeiden. Die grundlegenden Standards, die zu beachten sind:

Das untere Diagramm zeigt, wie Docker, Kubernetes, CRI, OCI, containerd und runc in diesem Ökosystem zusammenpassen:

 

docker CRI O containerd runc

Die Beziehung zwischen docker, CRI-O, containerd und runc – auf den Punkt gebracht
Quelle: www.tutorialworks.com

 

1. Dies sind Werkzeuge, die zum Ausführen von Containern in der Entwicklung oder in der Produktion verwendet werden.

2. CRI (Container Runtime Interface) ist eine Kubernetes API (Application Programming Interface). CRI definiert die Art und Weise, wie Kubernetes mit verschiedenen Container Runtimes interagiert. Da es in einer Spezifikation standardisiert ist, können Sie wählen, welche CRI-Implementierung Sie verwenden möchten oder möglicherweise eine eigene schreiben wollen.

3. Sie können selbst eine Runtime wählen, die der Container Runtime Interface (CRI)-Spezifikation entspricht. containerd wurde von Docker entwickelt. CRI-Plugin ist ein in containerd nativ integriertes, standardmäßig aktiviertes Plugin (ab der Version 1.1). Dadurch können Sie Kubernetes mit containerd als Container Runtime ausführen.

cri plugin

CRI-O ist ein Open-Source-Projekt und eine Alternative zu containerd und wird von einer Reihe namhafter Unternehmen unterstützt.

4. OCI ist eine offene Industriestandard Spezifikation, die zwei Spezifikationen enthält: die Runtime Spezifikation (runtime-spec) und die Image Spezifikation (image-spec)

5. runC ist ein OCI-konformes Werkzeug zum Erzeugen und Ausführen von Containern. runc wird für die Erstellung und Ausführung der Container entsprechend der OCI-Spezifikation verwendet.

6. Unsere Container laufen jetzt… 

 

Docker

Wir beginnen mit Docker, da es derzeit das beliebteste Container-Tool ist. Für viele ist der Name „Docker“ selbst ein Synonym für das Wort "Container".

Docker hat diese ganze Containerisierungs-Revolution in Gang gesetzt. Docker hat ein sehr ergonomisches und einfach zu bedienendes Werkzeug für die Arbeit mit Containern erschaffen, welches ebenfalls Docker genannt wird.

Projekte zum Betrieb Containers

Die Projekte zum Betrieb eines Containers mit Docker
Quelle: www.tutorialworks.com

 

1. Benutzer / Administratoren erstellen und starten Container mit dem Docker-Befehl.

2. containerd zieht Images, verwaltet Netzwerke und Speicher und verwendet runc, um Container auszuführen

3. runc erledigt den Low-Level-"Stab" zum Erstellen und Ausführen von containerisierten Prozessen 

 

docker kann auf einem Client-Betriebssystem oder auf einem Server-Betriebssystem installiert werden. docker enthält eine Reihe von Tools, die die Arbeit von Entwicklern und DevOps-Ingenieuren vereinfachen. Mit der docker -CLI können Sie Container-Images erstellen, aus Repositories abrufen, Container erstellen, starten und verwalten.

Docker besteht aus drei Projekten:

docker-cli – ist ein Befehlszeilendienstprogramm, mit dem Sie über den Befehl docker interagieren.

containerd –  ist ein Linux-Daemon, der Container verwaltet und startet. Der lädt Images aus dem Repository herunter, verwaltet Speicher und Netzwerke und überwacht die Ausführung von Containern.

runc – ist eine Low-Level-Container-Runtime, die tatsächlich die Container erstellt und ausführt. Sie enthält libcontainer, eine native Go-basierte Implementierung zum Erstellen von Containern.

Wenn Sie einen Container mit docker ausführen, führen Sie ihn in Wirklichkeit über den Docker-Daemon, containerd und dann runc aus.

  

Dockershim: Docker in Kubernetes

Es ist wichtig zu merken, dass Kubernetes nur die Container Runtimes bedienen kann, die das Container Runtime Interface (CRI) unterstützen. Docker kann diesen Standard jedoch nicht direkt unterstützen. Daher enthält Kubernetes eine Komponente namens dockershim, die für die Arbeit mit Docker erforderlich ist.

Kubernetes wird in Zukunft (ab der Version 1.23) die Unterstützung für Dockershim und dementsprechend Docker einstellen und nur noch mit Container Runtimes arbeiten, die das Container Runtime Interface (CRI) unterstützen - containerd oder CRI-O. (Dockershim Deprecation FAQ)

Dies bedeutet jedoch nicht, dass Kubernetes nicht in der Lage sein wird, Docker-formatierte Container auszuführen. Sowohl containerd als auch CRI-O können Docker-formatierte (OCI- formatted) Images ausführen. Sie tun es einfach, ohne den docker-Befehl oder den Docker-Daemon verwenden zu müssen.

Shim - Technisch gesehen, ist ein Shim eine Komponente in einem Softwaresystem, die als Brücke zwischen verschiedenen APIs oder als Kompatibilitätsschicht fungiert. Manchmal wird ein Shim hinzugefügt, wenn Sie eine Komponente eines Drittanbieters verwenden möchten. Sie benötigen quasi ein wenig „Glue Code“, damit es funktioniert.

 

Docker-Images

Was viele Leute als Docker-Images bezeichnen, sind eigentlich Images, die im Format der Open Container Initiative (OCI) verpackt sind.

Wenn Sie ein Image von Docker Hub oder einem anderen Repository herunterladen wollen, können Sie dies mit einem Befehl docker oder mit dem podman-Dienstprogramm durchführen oder mit einem anderen Tool, welches die OCI-Image-Formatspezifikation unterstützt.

 

Container Runtime Interface (CRI)

CRI ist eine API, die Kubernetes zur Steuerung der verschiedenen Container Runtimes verwendet, um die Container zu erstellen und zu verwalten.

CRI vereinfacht dem Kubernetes (oder besser gesagt kubelet) die Verwendung verschiedener Container-Runtimes. Anstatt jede mögliche Container Runtime separat zu unterstützen, wird nur der unterstützte CRI-Standard verwendet. In diesem Fall liegt die Aufgabe der Containerverwaltung vollständig bei der Container Runtime.

Kubernetes CRI

Quelle: www.tutorialworks.com

 

Wenn Sie also lieber containerd zum Ausführen Ihrer Container verwenden möchten, können Sie das gerne tun. Oder, wenn Sie es vorziehen, CRI-O zu verwenden, dann können Sie diese ebenso bedenkenlos verwenden. Das liegt daran, dass in den beiden Runtimes die CRI-Spezifikation implementiert wurde.

Wenn Sie ein Endbenutzer sind, sollte die Art der Implementierung meist keine Rolle für Sie spielen. Die CRI-Implementierungen sind so konzipiert, dass sie pluggable und nahtlos änderbar sind.

Zur Information: Red Hat (das OpenShift-Projekt) verwendet CRI-O und ist für dessen Wartung (Sicherheit, Fehlerbehebungen usw.) verantwortlich. Während containerd weiterhin von Docker einwickelt wird.

 

Welche Container Runtime wird in Kubernetes verwendet?

Der Kubelet (ein auf jedem Knoten ausgeführter Agent) ist in der Kubernetes-Architektur für die Interaktion mit der Container Runtime verantwortlich. Die Hauptaufgabe von kubelet ist das Senden von Anweisungen zum Starten/Stoppen an die Container Runtime.

Folgende Optionen werden für die Konfiguration der Container Runtime verwendet: --container-runtime und --container-runtime-endpoint. Welche Container Runtime bereits in Ihrer Kubernetes-Infrastruktur installiert ist, erfahren Sie mit Hilfe folgender Befehlskette:

kubectl describe node <node_name>

describe node

containerd

containerd ist eine High-Level-Container-Runtime, die von Docker stammt und die CRI-Spezifikation implementiert. сontainerd zieht Images aus dem Repository, verwaltet diese und übergibt sie dann weiter an eine untergeordnete Runtime, die die Container-Prozesse tatsächlich erstellt und ausführt.

containerd wurde aus dem Docker-Projekt herausgelöst, um Docker modularer zu gestalten. Somit verwendet Docker containerd auch für sich selbst. Wenn Sie Docker installieren, wird auch containerd automatisch mitinstalliert. Darüber hinaus verwendet сontainerd ein eigenes Plugin, um CRI in Kubernetes zu unterstützen.

 

CRI-O

CRI-O ist eine weitere High-Level-Container-Runtime, die das Container Runtime Interface (CRI) implementiert. CRI-O ist eine Alternative zu containerd und hat eine identische Funktionsweise.

CRI-O wurde mit Unterstützung von Red Hat, IBM, Intel und SUSE als Container Runtime für Kubernetes entwickelt. CRI-O bietet die Möglichkeit, die Container zu starten, zu stoppen oder neu zu starten, genau wie containerd.

 

Open Container Initiative (OCI)

Die OCI ist eine Gruppe von Technologieunternehmen, die eine Spezifikation für das Container-Image-Format und die Ausführung von Containern pflegen.

Die Idee hinter der OCI ist, dass Sie zwischen verschiedenen Runtimes wählen können, die der Spezifikation entsprechen. Jede dieser Runtimes hat unterschiedliche untergeordnete Implementierungen.

Sie haben beispielsweise eine OCI-kompatible Runtime für Ihre Linux-Hosts und eine für Ihre Windows-Hosts. Das ist der Vorteil, wenn man einen Standard hat, der von vielen verschiedenen Projekten implementiert werden kann.

 

runc

runc ist eine OCI-kompatible Container Runtime. Sie implementiert die OCI-Spezifikation und führt die Containerprozesse aus.

runc wird als Referenzimplementierung von OCI bezeichnet.

Was ist eine Referenzimplementierung?

Eine Referenzimplementierung ist eine Software, die alle Anforderungen einer Spezifikation oder eines Standards implementiert hat. Es ist normalerweise die erste Software, die aus der Spezifikation entwickelt wird. Im Fall von OCI bietet runc alle Funktionen, die von einer OCI-konformen Runtime erwartet werden, obwohl jeder seine eigene OCI- Runtime implementieren kann, wenn er möchte.

runc bietet alle Low-Level-Funktionen für die Container und interagiert mit bestehenden Low-Level-Linux-Features wie Namespaces und Control Group. runc verwendet diese Funktionen zum Erstellen und Ausführen von Containerprozessen.

Es existieren auch einige Alternativen zu runc:

 

Fazit

In diesem Artikel haben wir gesehen, dass Docker nur ein kleiner Teil des gesamten Container-Ökosystems ist. Es gibt offene Standards: CRI und OCI sowie Projekte wie containerdrunc und CRI-O. Möglicherweise werden wir bald viele neue Implementierungen der Container Runtime mit Unterstützung der CRI- und OCI-Standards sehen.

Hoffentlich konnte dieser Artikel ein wenig Licht ins Dunkel der Container-Welt bringen.

 

Autor: Tom Donohue

Dieser Blog-Beitrag ist eine Übersetzung aus dem Englischen. Den Originalartikel finden Sie unter diesem Link.