Container bedeuten für viele Menschen immer noch „Docker“. Docker hat die moderne Verwendung von Containern in der Softwareentwicklung und -bereitstellung populär gemacht. Heutzutage gibt es auch andere Technologien. So verhalten sich Containerd, Docker und Kubernetes zueinander.
Die Anfänge
Bei seiner Veröffentlichung im Jahr 2013 war Docker ein eigenständiges Projekt mit allem, was Sie zum Erstellen und Ausführen von Containern benötigen. Was fehlte, war eine einfache Möglichkeit, Containerbereitstellungen in der Cloud zu orchestrieren.
Ende 2013 befasste sich eine Gruppe von Googlern bereits mit einem Prototyp dessen, was später Kubernetes werden sollte. Kubernetes soll den Betrieb containerisierter Workloads über große Maschinenflotten hinweg vereinfachen.
Damals war Kubernetes untrennbar mit Docker verbunden. Es verwendete Docker direkt, um mit Containern zu interagieren, obwohl es nur eine Teilmenge der Funktionalität benötigte – die Teile, die für die eigentliche Ausführung von Containern verantwortlich sind.
Die entwicklerzentrierte Benutzeroberfläche von Docker stand Kubernetes im Weg. Es musste die menschenfreundlichen Aspekte des Projekts mit einem speziellen Tool, Dockershim, umgehen. Die Probleme wurden durch die unterschiedlichen Richtungen verschärft, in die sich Docker und Kubernetes bewegten. Docker startete Swarm, seine eigene Kubernetes-Alternative, die Orchestrierung als integrierten Docker-„Modus“ anbietet.
Der Aufstieg von Containerd
Als Kubernetes wuchs und immer mehr Tools von Drittanbietern rund um Docker auftauchten, wurden die Grenzen seiner Architektur deutlich. Gleichzeitig begann die Open Container Initiative (OCI) mit der Standardisierung von Containerformaten und Laufzeiten. Dies führte zu einer OCI-Spezifikation, die einen Container definiert, der von mehreren Laufzeiten verwendet werden kann, wofür Docker ein Beispiel ist.
Docker extrahierte dann seine Container-Laufzeit in ein neues Projekt, containerd. Dazu gehören die Docker-Funktionen zum Ausführen von Containern, zum Verwalten von Low-Level-Storage und zum Verwalten von Bildübertragungen. Containerd wurde an die Cloud Native Computing Foundation (CNCF) gespendet, um der Container-Community eine Grundlage für die Erstellung neuer Container-Lösungen zu bieten.
Das Aufkommen von containerd erleichtert Projekten wie Kubernetes den Zugriff auf die benötigten Low-Level-„Docker“-Elemente. Anstatt tatsächlich Docker zu verwenden, haben sie jetzt eine zugänglichere Schnittstelle zur Container-Laufzeit. Durch die OCI-Standardisierung von Container-Technologien können auch andere Laufzeiten verwendet werden.
Die Rolle von Containerd verstehen
Um containerd vollständig zu verstehen, ist es notwendig, sich die Natur von Containern anzusehen. Container sind wirklich eine Abstraktion über verschiedene Linux-Kernel-Funktionen. Um einen Container auszuführen, müssen Sie Systemaufrufe verwenden, um die containerisierte Umgebung einzurichten. Die Schritte variieren je nach Plattform und Distribution.
Containerd springt ein, um diese Low-Level-Verkabelung zu abstrahieren. Es ist als „Client-Schicht“ gedacht, auf der Container-Software dann aufbaut. Dies kann entwicklerorientierte Software wie Docker oder Cloud-orientierte Entwicklungstools wie Kubernetes sein.
Zuvor hatte die Kubernetes-Entwicklung zwei schlechte Optionen:Schreiben Sie weiterhin Shims um die kräftige Docker-Schnittstelle herum oder beginnen Sie direkt mit den Linux-Kernel-Funktionen zu interagieren. Durch das Ausbrechen von containerd aus Docker wurde eine dritte Alternative verfügbar:Verwenden Sie containerd als Systemabstraktionsschicht, ohne Docker einzubeziehen.
Hier ist eine Zusammenfassung der Kombination der drei Technologien:
- Docker – Eine entwicklerorientierte Software mit einer High-Level-Schnittstelle, mit der Sie auf einfache Weise Container von Ihrem Terminal aus erstellen und ausführen können. Es verwendet jetzt containerd als seine Container-Laufzeit.
- Containerd – Eine Abstraktion von Kernelfunktionen, die eine Containerschnittstelle auf relativ hohem Niveau bietet. Andere Softwareprojekte können dies verwenden, um Container auszuführen und Container-Images zu verwalten.
- Kubernetes – Ein Container-Orchestrator, der mit mehreren Container-Laufzeiten funktioniert, einschließlich containerd. Kubernetes konzentriert sich auf die aggregierte Bereitstellung von Containern über einen oder mehrere physische „Knoten“. Historisch war Kubernetes an Docker gebunden.
Containerd ist nur ein Container-Backend. Andere Container, die die Open Containers Runtime-Spezifikation implementieren, umfassen runC und CRI-O. Diese Laufzeiten können auch mit Docker und Kubernetes verwendet werden; jeder hat seine eigenen Unterscheidungen.
Das OCI
Das OCI ist das Gremium, das für die Definition von Containerstandards verantwortlich ist. Seine Arbeit war maßgeblich an der Erleichterung der Interoperabilität zwischen verschiedenen Komponententechnologien beteiligt.
Die Bildspezifikation des OCI definiert, wie ein Container aussehen soll. Die Laufzeitspezifikation legt eine Schnittstelle zum Ausführen von Containern fest. Projekte wie containerd implementieren dann diese Spezifikationen.
Wichtig ist, dass eine der Prioritäten des OCI die Unterstützung der von Docker populären Containernutzungserfahrung ist. Seine Images müssen auf der Zielplattform ohne benutzerdefinierte Argumente ausführbar sein (z. B. docker run hello-world:latest ). OCI-Bilder müssen daher ausreichend Metadaten enthalten, um diese automatische Konfiguration zu ermöglichen.
Möglicherweise sehen Sie auch Verweise auf das Container Runtime Interface (CRI). Dies ist eine Kubernetes-spezifische Abstraktion der OCI-Spezifikation. Der CRI baut auf den OCI-Spezifikationen auf, um die Unterstützung für austauschbare Containerlaufzeiten in Kubernetes zu ermöglichen.
Was ist mit meinen Docker-Images?
Images, die Sie mit Docker erstellen, sind überhaupt keine „Docker-Images“. Da Docker jetzt die containerd-Laufzeit verwendet, werden Ihre Images im standardisierten Format der Open Container Initiative (OCI) erstellt.
Sie sollten sich keine Gedanken über Inkompatibilitäten zwischen Ihren Docker-Images und der Umgebung machen müssen, in der sie verwendet werden. Images, die Sie mit Docker erstellen, können weiterhin mit Kubernetes bereitgestellt werden. Dies liegt daran, dass Kubernetes durch die Verwendung von containerd (und anderen standardkonformen Laufzeiten) auch OCI-Images unterstützt. Es liegt an der Laufzeit um das Ziehen und Ausführen von Images zu handhaben, nicht die High-Level-Schnittstelle, die Tools wie Docker und Kubernetes bieten.
Kubernetes und Docker
Kubernetes hat die Docker-Laufzeit Ende 2020 eingestellt. Sie wird in einer zukünftigen Version entfernt, die derzeit für Ende 2021 geplant ist. Danach wird Kubernetes keine Docker-Laufzeit mehr anbieten Unterstützung. Stattdessen muss eine alternative Laufzeit verwendet werden, die mit den OCI-Spezifikationen kompatibel ist, z. B. containerd.
Diese Ankündigung löste Bedenken hinsichtlich der Auswirkungen auf Entwickler aus. Die Änderung sollte sich nicht auf die meisten bestehenden Workflows auswirken. Wie wir bereits gesehen haben, produziert Docker OCI-konforme Images, die OCI-konforme Laufzeiten ausführen können. Alle Images, die Sie mit docker build erstellen funktioniert weiterhin innerhalb von Kubernetes, auch nachdem die Docker-Laufzeitumgebung entfernt wurde.
Zwei unterschiedliche Technologien werden in Betracht gezogen – die Befehlszeilenschnittstelle von Docker zum Erstellen und Ausführen von Containern und der Laufzeit von Docker die die Befehlszeilenschnittstelle umschließt.
Es ist alles zu verwirrend!
In nur wenigen Jahren haben Container die Arbeit vieler Entwickler verändert. Die Expansion des umgebenden Ökosystems war ein natürliches Nebenprodukt dieser Verschiebung. Der Containers === Docker Mentalität erwies sich als zu erdrückend, da sie Tools wie Kubernetes daran hinderte, ihr volles Potenzial zu entfalten.
Der Trend zur Standardisierung hat zu einer Fülle neuer Begriffe, Tools und Technologien geführt. Nichtsdestotrotz hat sich für Entwickler nichts wirklich geändert, egal ob Sie mit der Docker-CLI auf Ihrem Computer oder einem Kubernetes-Cluster in der Cloud interagieren.
Jede benutzerorientierte High-Level-Schnittstelle (wie Docker und Kubernetes) profitiert jetzt von einer Auswahl austauschbarer Low-Level-Containerlaufzeiten (wie containerd und runC). Dies ermöglicht ein höheres Maß an Flexibilität und lässt neue containerbasierte Technologien standardkonform etablieren.