Hinweis perev. : Wir haben bereits mehr als eine Veröffentlichung (siehe Links am Ende des Artikels) über Containerlaufzeiten (Containerlaufzeiten) geschrieben - diese werden in der Regel im Kontext von Kubernetes diskutiert. Diese Materialien erregten jedoch häufig Fragen der Leser, was auf ein Unverständnis darüber hinweist, woher das nächste Projekt kam, wie es mit anderen verbunden ist und was in all diesem Container-Zoo vor sich geht.
Ein kürzlich veröffentlichter Artikel von Phil Estes, Technischer Direktor für Container und Linux-Architektur bei IBM Watson & Cloud Platform, bietet einen hervorragenden Rückblick darauf, wie man navigiert und ein umfassenderes Verständnis dafür gewinnt, wer den Faden der Ereignisse verloren hat (oder nie gefangen hat). Als einer der Betreuer der Moby- und Containerd-Projekte, Mitglied der technischen Komitees der Open Container Initiative (OCI) und von Moby sowie als Docker Captain schreibt der Autor über die Vergangenheit, Gegenwart und Zukunft der neuen wunderbaren Welt der Containerlaufzeiten. Und für die Faulsten beginnt das Material mit einer kompakten TL; DR zum Thema ... Wichtigste Ergebnisse
- Im Laufe der Zeit hat die Auswahl unter den Containerlaufzeiten zugenommen und bietet mehr Optionen als die beliebte Docker-Engine.
- Die Open Container Initiative (OCI) hat das Konzept des Container- und Container-Images erfolgreich standardisiert, um die Interoperabilität („Interoperabilität“ - ca. übersetzt) zwischen Laufzeitumgebungen zu gewährleisten.
- Kubernetes hat das Container Runtime Interface (CRI) hinzugefügt, mit dem Container eine Verbindung zu Laufzeitumgebungen mit der zugrunde liegenden Orchestrierungsschicht in K8s herstellen können.
- Innovationen in diesem Bereich ermöglichen es Containern, die einfache Virtualisierung und andere einzigartige Isolationstechniken für wachsende Sicherheitsanforderungen zu nutzen.
- Mit OCI und CRI sind Interoperabilität und Auswahl im Ökosystem von Laufzeitcontainer- und Orchestrierungsumgebungen Realität geworden.
Die Containerisierungstechnologie gibt es in der Welt der Linux-Betriebssysteme schon seit geraumer Zeit - die ersten Ideen zu separaten Namespaces für Dateisysteme und Prozesse sind vor mehr als einem Jahrzehnt aufgetaucht. In der jüngeren Vergangenheit erschien der LXC und wurde zur Standardmethode für Linux-Benutzer, um mit der leistungsstarken Isolationstechnologie zu interagieren, die im Linux-Kernel verborgen ist.
Trotz der Versuche des
LXC , die Komplexität der Kombination verschiedener technologischer „Innenseiten“ dessen, was wir heute normalerweise als Container bezeichnen, zu verbergen, blieben Container eine Art Magie und wurden nur in der Welt derjenigen stärker, die besonders gut informiert waren und keine breite Verteilung unter den Massen fanden.
Mit
Docker änderte sich 2014 alles, als ein neuer, entwicklerfreundlicher Wrapper für dieselbe Linux-Kernel-Technologie erschien, die LXC in Betrieb hatte - schließlich verwendeten die frühen Versionen von Docker „hinter den Kulissen“ LXC, und die Container wurden - ein echtes Massenphänomen, da die Entwickler von der Einfachheit und den Möglichkeiten der Wiederverwendung von Docker-Container-Images und einfachen Befehlen für die Arbeit mit ihnen durchdrungen waren.
Natürlich war Docker nicht der einzige, der sich einen Anteil am Containermarkt sichern wollte, als der sie begleitende Hype nach dem ersten explosiven Interesse im Jahr 2014 nicht nachlassen wollte. Im Laufe der Jahre sind eine Vielzahl alternativer Ideen für ausführbare Containerumgebungen von
CoreOS (rkt) ,
Intel Clear Containers ,
hyper.sh (leichte containerisierte Virtualisierung) sowie
Singularity und
Shifter in der Welt der Hochleistungsrechnerforschung (HPC) entstanden.
Der Markt wuchs und reifte weiter und mit der
Open Container Initiative (OCI) wurden die ersten von Docker geförderten Ideen standardisiert. Heutzutage sind viele ausführbare Containerumgebungen entweder bereits mit OCI kompatibel oder auf dem Weg dorthin und bieten Herstellern gleiche Bedingungen, um ihre Funktionen und Fähigkeiten zu fördern, die auf eine bestimmte Anwendung ausgerichtet sind.
Popularität von Kubernetes
Die nächste Stufe in der Entwicklung von Containern bestand darin, verteilte Computercontainer a la Microservices mit Containern zu kombinieren - und das alles in der neuen Welt der schnellen Entwicklungs- und Bereitstellungsiterationen (wir können sagen, dass DevOps), die zusammen mit der Popularität von Docker aktiv an Dynamik gewann.
Obwohl
Apache Mesos und andere Software-Orchestrierungsplattformen existierten, bevor
Kubernetes dominierte, starteten die
K8s schnell von einem kleinen Open Source-Projekt von Google zum Hauptprojekt der
Cloud Native Computing Foundation (CNCF) .
Hinweis perev. : Wissen Sie, dass CNCF 2015 anlässlich der Veröffentlichung von Kubernetes 1.0 erschien? Gleichzeitig wurde das Projekt von Google an eine neue unabhängige Organisation übertragen, die Teil der Linux Foundation wurde.
K8s 1.0 Release Event, gesponsert unter anderem von Mesosphere, CoreOS, Mirantis, OpenStack, Bitnami
Aus den Nachrichten über die Veröffentlichung von Kubernetes 1.0 auf ZDNetSelbst nachdem Docker die in Docker integrierte konkurrierende Orchestrierungsplattform
Swarm veröffentlicht hatte , die Docker-Einfachheit und einen Fokus auf die standardmäßige sichere Cluster-Konfiguration bietet, reichte dies nicht mehr aus, um das wachsende Interesse an Kubernetes einzudämmen.
Viele Stakeholder außerhalb der schnell wachsenden Cloud-Communitys waren jedoch verwirrt. Ein durchschnittlicher Beobachter konnte nicht herausfinden, was geschah: Kubernetes kämpfen mit Docker oder ihrer Zusammenarbeit? Da Kubernetes nur eine Orchestrierungsplattform war, war eine ausführbare Containerumgebung erforderlich, mit der in Kubernetes orchestrierte Container direkt gestartet werden konnten. Von Anfang an verwendete Kubernetes die Docker-Engine. Trotz der Konkurrenz zwischen Swarm und Kubernetes war Docker immer noch die Standardlaufzeit und für die Funktion des Kubernetes-Clusters erforderlich.
Bei einer kleinen Anzahl anderer Containerlaufzeiten als Docker schien es klar zu sein, dass für das Koppeln der Laufzeit mit Kubernetes für jede Laufzeit eine speziell geschriebene Schnittstelle - Shim - erforderlich ist. Das Fehlen einer klaren Schnittstelle für die Implementierung von Containerlaufzeiten machte es sehr schwierig, Unterstützung für neue Laufzeiten in Kubernetes hinzuzufügen.
Container Runtime Interface (CRI)
Um die wachsende Komplexität der Implementierung von Laufzeiten in Kubernetes zu lösen, definierte die Community eine schnittstellenspezifische Funktion, die die Container-Laufzeit in Kubernetes implementieren sollte, und nannte sie
Container Runtime Interface (CRI) (sie erschien in Kubernetes 1.5 - ca. Transl.) . Dieses Ereignis half nicht nur dem Problem der wachsenden Anzahl von Fragmenten der Kubernetes-Codebasis, die sich auf die Verwendung von Containerlaufzeiten auswirken, sondern auch zu verstehen, welche Funktionen von potenziellen Laufzeiten unterstützt werden sollten, wenn sie CRI einhalten möchten.
Wie Sie sich vorstellen können, erwartet CRI von der Laufzeit sehr einfache Dinge. Eine solche Umgebung sollte in der Lage sein, Pods zu starten und zu stoppen, alle Vorgänge mit Containern im Kontext von Pods abzuwickeln (Start, Stopp, Pause, Kill, Löschen) und auch die Verwaltung von Container-Images mithilfe der Registrierung zu unterstützen. Es gibt auch Zusatzfunktionen zum Sammeln von Protokollen, Metriken usw.
Wenn neue Funktionen in Kubernetes angezeigt werden und von der Ebene der Container-Laufzeit abhängen, werden solche Änderungen an der versionierten CRI-API vorgenommen. Dies schafft wiederum eine neue funktionale Abhängigkeit von Kubernetes und erfordert die Veröffentlichung neuer Versionen von Laufzeiten, die neue Funktionen unterstützen (ein aktuelles Beispiel sind Benutzernamensräume).
Aktuelle CRI-Landschaft
Ab 2018 gibt es in Kubernetes mehrere Optionen zur Verwendung als Containerlaufzeiten. Wie in der folgenden Abbildung gezeigt, ist Docker mit seinem
Dockershim , der die CRI-API implementiert, immer noch eine der wirklichen Optionen. Tatsächlich ist es in den meisten Kubernetes-Installationen heute er, Docker, der die Standardlaufzeit bleibt.
Eine der interessanten Konsequenzen der Spannung zwischen der Docker-Orchestrierungsstrategie mit Swarm und der Kubernetes-Community war ein gemeinsames Projekt, das auf der Grundlage der Laufzeit von Docker ein neues, gemeinsam entwickeltes Open Source-Projekt -
Containerd - zusammenfasste. Im Laufe der Zeit wurde Containerd an CNCF übertragen, dieselbe Organisation, die das Kubernetes-Projekt verwaltet und besitzt.
( Anmerkung übersetzt : Wir haben das Erscheinungsbild von Containerd in einem separaten Artikel ausführlicher beschrieben .)
Aus der Ankündigung von Containerd im Docker-BlogContainerd, eine einfache, grundlegende und unternehmensunabhängige
(nicht meinungsgebundene) Implementierung der Laufzeit für Docker und Kubernetes (über CRI), wurde in vielen Kubernetes-Installationen als potenzieller Ersatz für Docker immer beliebter. Bisher verfügen sowohl IBM Cloud als auch Google Cloud über Cluster auf Basis von Containerds im Early Access / Beta-Modus. Microsoft Azure versprach auch, in Zukunft auf Containerd umzusteigen, und Amazon erwägt weiterhin verschiedene Optionen für die Laufzeit seiner Containerlösungen (ECS und EKS), während Docker weiterhin verwendet wird.
Red Hat hat den Container-
Laufzeitbereich betreten, indem eine einfache CRI-Implementierung namens
cri-o erstellt wurde, die auf der OCI-Referenzimplementierung
runc basiert . Docker und Containerd sind ebenfalls Runc-basiert, aber die Entwickler von Cri-O behaupten, dass ihre Laufzeiten für Kubernetes "gerade genug" sind und sie nicht mehr benötigen - sie haben nur die wichtigsten Funktionen hinzugefügt, um Kubernetes CRI über die Basis-Runc-Binärdatei zu implementieren.
( Anmerkung übersetzt : Wir haben in diesem Artikel mehr über das CRI-O-Projekt und hier über seine Weiterentwicklung in Form von Podman geschrieben.)Leichte Virtualisierungsprojekte: Intel Clear Containers und hyper.sh - erschienen in der Wildnis der OpenStack Foundation,
Kata-Container , und bieten ihre Vision von virtualisierten Containern für zusätzliche Isolation mithilfe einer CRI-Implementierung namens
frakti . Sowohl Cri-O als auch Containerd funktionieren auch mit Kata-Containern, sodass ihre OCI-kompatible Laufzeit als steckbare Option ausgewählt werden kann.
Die Zukunft vorhersagen
Zu sagen, dass Sie die Zukunft kennen, ist normalerweise nicht sehr klug, aber wir können zumindest einige aufkommende Trends korrigieren, wenn sich das Ökosystem der Container von Begeisterung und Hype zu einem reiferen Stadium unserer Existenz entwickelt.
Es gab frühe Befürchtungen, dass das Container-Ökosystem eine fragmentierte Umgebung bilden würde, deren unterschiedliche Teilnehmer unterschiedliche und inkompatible Vorstellungen darüber haben würden, was ein Container ist. Dank der Arbeit von OCI und des verantwortungsvollen Handelns der wichtigsten Anbieter und Teilnehmer konnten wir unter den Softwareangeboten, die die Kompatibilität mit OCI bevorzugten, ein gesundes Umfeld in der Branche erkennen.
Selbst in neueren Umgebungen, in denen der Docker-Verwendungsstandard aufgrund bestehender Einschränkungen - beispielsweise in HPC - weniger Widerstand fand, wurde bei allen Versuchen, nicht auf Docker basierende Container-Container-Umgebungen zu erstellen, auch auf die OCI aufmerksam. Es wird diskutiert, ob OCI eine tragfähige Lösung für die spezifischen Bedürfnisse der Gemeinschaften von Wissenschaftlern und Forschern sein kann.
Hinzu kommt die Standardisierung der Plug-in-Containerlaufzeiten in Kubernetes mithilfe von CRI. Wir können uns eine Welt vorstellen, in der Entwickler und Administratoren die richtigen Tools und Software-Stacks für ihre Aufgaben auswählen und auf die Interoperabilität im gesamten Container-Ökosystem warten und diese beobachten können.
Betrachten Sie ein bestimmtes Beispiel, um diese Welt besser zu verstehen:
- Ein Entwickler mit einem MacBook verwendet Docker für Mac, um seine Anwendung zu entwickeln, und verwendet sogar die integrierte Kubernetes-Unterstützung (Docker funktioniert hier wie CRI-Laufzeit), um zu versuchen, die neue Anwendung auf K8s-Pods bereitzustellen.
- Die Anwendung durchläuft CI / CD in der Software des Anbieters, die runc und speziellen (vom Anbieter geschriebenen) Code verwendet, um das OCI-Image zu verpacken und zum Testen in die Unternehmensregistrierung von Containern zu laden.
- Die lokale Kubernetes-Clusterinstallation, die mit Containerd als CRI-Laufzeit arbeitet, führt eine Reihe von Tests für die Anwendung aus.
- Aus irgendeinem Grund hat dieses Unternehmen Kata-Container für bestimmte Workloads in der Produktion ausgewählt. Wenn Sie die Anwendung bereitstellen, wird sie in Pods mit Containerd gestartet, die so konfiguriert sind, dass Kata-Container als Laufzeit anstelle von runc verwendet werden.
Das gesamte beschriebene Szenario funktioniert wunderbar, da es mit der OCI-Spezifikation für Laufzeitumgebungen und Images kompatibel ist und CRI die Flexibilität bietet, die Laufzeit auszuwählen.
Diese mögliche Flexibilität und Auswahl macht das Container-Ökosystem wirklich bemerkenswert und ist auch eine sehr wichtige Voraussetzung für die Reife der Branche, die seit 2014 so schnell gewachsen ist. An der Schwelle von 2019 und den folgenden Jahren sehe ich eine glänzende Zukunft mit kontinuierlichen Innovationen und Flexibilität für diejenigen, die Plattformen auf der Basis von Containern nutzen und erstellen.
Weitere Informationen zu diesem Thema finden Sie in einem kürzlich von Phil Estes auf QCon NY gehaltenen Vortrag: „
CRI Runtimes Deep Dive: Wer betreibt meinen Kubernetes Pod? ""
PS vom Übersetzer
Lesen Sie auch in unserem Blog: