Vergangenheit, Gegenwart und Zukunft von Docker und anderen ausführbaren Containern in Kubernetes

Ursprünglicher Autor: Phil Estes
  • Übersetzung
Hinweis trans. : Wir haben mehr als eine Veröffentlichung (siehe die Links am Ende des Artikels) über ausführbare Containerlaufzeiten geschrieben - sie befinden sich normalerweise im Kontext von Kubernetes. Diese Materialien führten jedoch häufig zu Fragen des Lesers, aus denen hervorgeht, wo das nächste Projekt herkommt, wie es mit anderen zusammenhängt und was normalerweise in diesem Container-Zoo geschieht.



Ein kürzlich erschienener Artikel des Technischen Direktors der IBM Watson & Cloud-Plattform zu Containerstrategie und Linux-Architektur - Phil Estes - bietet eine hervorragende Retrospektive und hilft Ihnen beim Navigieren, um ein umfassenderes Verständnis derjenigen zu erlangen, die den Faden der Ereignisse verloren haben (oder nie verstanden haben). Als einer der Hauptbetreuer des Moby and Containerd-Projekts, Mitglied der Open Container Initiative (OCI) und der Technischen Komitees von Moby sowie mit dem Status eines Docker Captain, schreibt der Autor über die Vergangenheit, Gegenwart und Zukunft der wunderbaren Welt der Containerlaufzeiten. Und für die Faulsten beginnt das Material mit einem kompakten TL: DR zum Thema ...

Hauptergebnisse


  • Mit der Zeit ist die Auswahl zwischen den ausführbaren Containerumgebungen gewachsen und bietet mehr und mehr Optionen als die beliebte Docker-Engine.
  • Die Open Container Initiative (OCI) hat das Konzept eines Containers und eines Containerimages erfolgreich vereinheitlicht, um die Interoperabilität ("Interoperabilität" - ca. Transl.) Zwischen ausführbaren Umgebungen sicherzustellen .
  • In Kubernetes wurde die CRI-Schnittstelle (Container Runtime Interface) hinzugefügt, mit der ausführbare Mediencontainer mit der darunter liegenden Orchestrierungsschicht in K8 verbunden werden können.
  • Innovationen in diesem Bereich ermöglichen es Containern, leichte Virtualisierung und andere einzigartige Isolationstechniken für wachsende Sicherheitsanforderungen einzusetzen.
  • Mit OCI und CRI sind Interoperabilität und Auswahl im Ökosystem ausführbarer Container- und Orchestrierungsumgebungen Realität geworden.

In der Welt des Linux-Betriebssystems gibt es die Containerisierungstechnologie schon lange - die ersten Ideen zu separaten Namespaces für Dateisysteme und Prozesse kamen vor mehr als einem Jahrzehnt auf. In relativ kurzer Zeit erschien LXC als Standard für Linux-Benutzer, um mit leistungsstarker Isolationstechnologie zu interagieren, die im Linux-Kernel verborgen ist.

Trotz der Versuche von LXC, die Komplexität der Kombination verschiedener technologischer "Eingriffe", wie wir sie heute als Container bezeichnen, zu verbergen, blieben die Container jedoch eine Art Magie und wurden nur in der Welt besonders gut geschult und wurden unter den Massen nicht verbreitet.

Mit Docker hat sich 2014 alles geändertals ein neuer, entwicklerfreundlicher Wrapper der gleichen Linux-Kernel-Technologie verwendet wurde, der vom LXC verwendet wurde - in der Tat verwendeten die frühen Versionen des Docker hinter den Kulissen den LXC - und Container wurden wirklich sehr verbreitet Einfachheit und Wiederverwendbarkeit von Docker-Container-Images und einfache Befehle, um mit ihnen zu arbeiten.

Natürlich war Docker nicht der einzige, der Marktanteile auf dem Containermarkt gewinnen wollte, als der begleitende Hype nach dem ersten explosiven Interesse im Jahr 2014 keine Beruhigung fand. Im Laufe der Jahre sind aus CoreOS (rkt) , Intel Clear Containers und hyper.sh eine Vielzahl alternativer Ideen für ausführbare Containerumgebungen entstanden(leichte Container-basierte Virtualisierung) sowie Singularity und Shifter in der Welt der Hochleistungs-Computing-Forschung (HPC).

Der Markt wuchs und reifte weiter, und mit der Open Container Initiative (OCI) wurde versucht, die ursprünglichen Ideen, die von Docker vorangetrieben wurden, zu vereinheitlichen. Heutzutage sind viele ausführbare Containerumgebungen entweder bereits mit OCI kompatibel oder auf dem Weg dorthin, und bieten Herstellern die gleichen Bedingungen, um ihre Funktionen und Fähigkeiten für bestimmte Anwendungen zu fördern.

Kubernetes Popularität


Der nächste Schritt in der Evolution von Containern war die Integration von verteilten Computing-Containern à la Microservices - und all dies in der neuen Welt der schnellen Entwicklung und Bereitstellung von Bereitstellungen (wir können sagen, dass DevOps), die mit der Popularität von Docker immer mehr an Bedeutung gewann.

Obwohl Apache Mesos und andere Software-Orchestrierungsplattformen vor der Einführung von Kubernetes existierten , starteten K8s von einem kleinen Open-Source-Projekt von Google zum Hauptprojekt der Cloud Native Computing Foundation (CNCF) . Hinweis trans. : Wussten Sie, dass CNCF erschienen ist ?

im Jahr 2015 anlässlich der Veröffentlichung von Kubernetes 1.0? Gleichzeitig wurde das Projekt von Google an eine neue unabhängige Organisation übertragen, die Teil der Linux Foundation wurde.


Veranstaltung anlässlich der Veröffentlichung von K8s 1.0, die unter anderem von Mesosphere, CoreOS, Mirantis, OpenStack, Bitnami gesponsert wurde.

Aus den Nachrichten über die Veröffentlichung von Kubernetes 1.0 auf ZDNet.

Auch nachdem Docker eine Konkurrenzplattform für Orchestrierung veröffentlicht hatte - Swarm - in Docker integriert Aufgrund der Einfachheit von Docker und der Konzentration auf die standardmäßige sichere Clusterkonfiguration konnte dies das wachsende Interesse an Kubernetes nicht mehr aufhalten.

Viele Stakeholder außerhalb der schnell wachsenden Beliebtheit von Cloud-Communities (native Clouds) waren jedoch verwirrt. Ein gewöhnlicher Beobachter konnte nicht herausfinden, was los war: Kubernetes, der gegen Docker kämpft, oder deren Zusammenarbeit? Da Kubernetes nur eine Plattform für die Orchestrierung war, war eine ausführbare Containerumgebung erforderlich, mit der direkt Container gestartet werden, die in Kubernetes orchestriert sind. Von Anfang an nutzte Kubernetes die Docker-Engine. Trotz der Spannungen zwischen Swarm und Kubernetes blieb der Docker die Standardlaufzeit und war für das Funktionieren des Kubernetes-Clusters erforderlich.

Bei einer kleinen Anzahl von ausführbaren Containerumgebungen mit Ausnahme von Docker schien es klar zu sein, dass das Koppeln der Laufzeit mit Kubernetes für jede der ausführbaren Umgebungen eine speziell geschriebene Schnittstelle (shim) erfordern würde. Das Fehlen einer klaren Schnittstelle für die Implementierung ausführbarer Containerumgebungen machte es sehr schwierig, Unterstützung für neue Laufzeit in Kubernetes hinzuzufügen.

Container Runtime Interface (CRI)


Um das Problem der wachsenden Komplexität bei der Implementierung runtime'ov Kubernetes zu lösen, Gemeinschaft der Schnittstelle bestimmt - spezifische Funktionen , die ausführbare Container - Umgebung sind , muß im Rahmen umgesetzt werden Kubernetes, - es ruft den Container Runtime Interface (CRI) (er erschien in Kubernetes 1.5 -. Ca. Perevi). . Dieses Ereignis half nicht nur dem Problem der wachsenden Anzahl von Kubernetes-Codebasisfragmenten, die sich auf die Verwendung von ausführbaren Containerumgebungen auswirkten, sondern trug auch dazu bei, genau zu verstehen, welche Funktionen von der potenziellen Laufzeit unterstützt werden sollten, wenn sie die CRI einhalten möchten.

Wie Sie sich vorstellen können, erwartet CRI sehr einfache Dinge aus der ausführbaren Umgebung. Eine solche Umgebung sollte in der Lage sein, Betrug zu starten und zu stoppen, alle Containeroperationen im Kontext von Bereichen (Starten, Stoppen, Anhalten, Löschen, Löschen) auszuführen und auch die Verwaltung von Containerimages über die Registrierung zu unterstützen. Es gibt auch Unterstützungsfunktionen zum Sammeln von Protokollen, Metriken usw.

Wenn neue Funktionen in Kubernetes erscheinen und von der Ebene der Umgebung für ausführbare Container abhängen, werden diese Änderungen an der versionierten CRI-API vorgenommen. Dies führt wiederum zu einer neuen funktionalen Abhängigkeit von Kubernetes und erfordert die Freigabe neuer Versionen der Laufzeitunterstützung neuer Funktionen (ein aktuelles Beispiel sind Benutzernamensräume).

Die aktuelle Landschaft von CRI


Seit 2018 gibt es mehrere Möglichkeiten, Kubernetes als ausführbare Containerumgebungen zu verwenden. Wie in der Abbildung unten gezeigt, ist Dockerhim , das die CRI-API implementiert , immer noch eine der wirklichen Optionen von Docker . In den meisten heutigen Kubernetes-Installationen bleibt er, Docker, die ausführbare Umgebung.



Eine der interessanten Konsequenzen der Spannung zwischen der Docker-Strategie für die Orchestrierung mit Swarm und der Kubernetes-Community war ein gemeinsames Projekt, das den Kern der Laufzeit vom Docker nahm und daraus ein neues, gemeinsam entwickeltes Open Source-Projekt - containerd - sammelte . Im Laufe der Zeit wurde Containerd an CNCF übergeben - dieselbe Organisation, die das Kubernetes-Projekt verwaltet und besitzt. (Hinweis trans. : Das Aufkommen von Containerd wurde in einem separaten Artikel ausführlicher beschrieben .)


Von der Ankündigung von Containerd im Blog von Docker

Containerd ausgehend, ist sie einfach, grundlegend und unabhängig von den Ansichten eines bestimmten Unternehmens (unbewertete) Implementierung der Laufzeit für Docker und Kubernetes (über CRI). begann sich als möglicher Ersatz für Docker in einer Vielzahl von Kubernetes-Installationen zu etablieren. Heutzutage befinden sich auf IBM Cloud- und Google Cloud-Clustern basierende Cluster im frühen Zugriffs- / Betamodus. Microsoft Azure versprach auch, in Zukunft auf Container zuzugreifen, und Amazon erwägt weiterhin verschiedene Laufzeitoptionen für seine Containerlösungen (ECS und EKS), während Docker weiterhin verwendet wird.

Red Hat kam in die ausführbare Containerumgebung, indem er eine einfache CRI-Implementierung namens cri-o auf Basis der OCI-Referenzimplementierung runc erstellte . Docker und Containerd basieren ebenfalls auf runc, aber die Entwickler von cri-o behaupten, dass ihre Laufzeit für Kubernetes „gerade genug“ ist und nicht mehr benötigt wird. Sie fügten nur die wichtigsten hinzu, um Kubernetes CRI-Funktionen auf der Basis-runc-Binärdatei zu implementieren. ( Hinweis: Weitere Informationen zum CRI-O-Projekt, das wir in diesem Artikel geschrieben haben , und zur weiteren Entwicklung als Podman - hier .)

Leichte Virtualisierungsprojekte: Intel Clear Containers und hyper.sh - tauchten in der Wildnis der Kata-Container der OpenStack Foundation auf, und bieten ihre Vision von virtualisierten Containern zur zusätzlichen Isolierung mit einer CRI-Implementierung namens frakti an . Sowohl cri-o als auchcontainer funktionieren auch mit Kata-Containern, sodass ihre OCI-kompatible Laufzeitumgebung als steckbare Option ausgewählt werden kann.

Zukunft vorhersagen


Zu sagen, dass Sie wissen, dass die Zukunft normalerweise nicht sehr klug ist, aber wir können zumindest einige aufkommende Trends korrigieren, während sich das Ökosystem der Container vom allgemeinen Enthusiasmus und der Hyip zu einem reiferen Stadium seiner Existenz bewegt.

Es gab früh Bedenken, dass das Container-Ökosystem eine fragmentierte Umgebung bilden würde, bei der verschiedene Teilnehmer unterschiedliche und inkompatible Vorstellungen davon haben, was ein Container ist. Dank der Arbeit von OCI und dem verantwortungsbewussten Handeln der Hauptanbieter und Teilnehmer, sahen wir in der Branche ein gesundes Umfeld bei Softwareangeboten, die die Kompatibilität von OCI fördern.

Selbst in neueren Umgebungen, in denen der Standard für die Verwendung von Docker aufgrund bestehender Einschränkungen - z. B. in HPC - weniger Widerstand erfahren hat, haben alle Versuche, nicht Docker-basierte ausführbare Containerumgebungen zu erstellen, auch OCI berücksichtigt. Es gibt Diskussionen darüber, ob OCI eine praktikable Lösung für die spezifischen Bedürfnisse der Gemeinschaften von Wissenschaftlern und Forschern sein kann.

Durch die Standardisierung von verbundenen ausführbaren Containerumgebungen zu Kubernetes mithilfe von CRI können wir uns eine Welt vorstellen, in der Entwickler und Administratoren die geeigneten Softwaretools und Softwarestacks auswählen können, während sie warten und die Interoperabilität im gesamten Container-Ökosystem beobachten.

Betrachten Sie ein bestimmtes Beispiel, um diese Welt besser zu verstehen:

  • Ein MacBook-Entwickler verwendet Docker für Mac, um seine Anwendung zu entwickeln, und verwendet sogar die integrierte Unterstützung für Kubernetes (der Docker fungiert hier als CRI-Laufzeit), um die Bereitstellung der neuen Anwendung auf K8s zu versuchen.
  • Die Anwendung durchläuft das CI / CD in der Herstellersoftware, die das OCI-Image mit runc und speziellem (vom Hersteller geschriebenem) Code verpackt und zum Testen in das Unternehmensregister der Container lädt.
  • Die eigene (lokale) Clusterinstallation von Kubernetes, die als CRI-Laufzeit mit Containern arbeitet, führt die Testsuite für die Anwendung aus.
  • Aus irgendeinem Grund hat sich dieses Unternehmen für bestimmte Workloads in der Produktion für Kata-Container entschieden. Wenn die Anwendung implementiert wird, wird sie in Unterfeldern ausgeführt, in denen container für die Verwendung von Kata-Containern als Laufzeit anstelle von runc konfiguriert ist.

Das gesamte oben beschriebene Skript funktioniert dank der OCI-Kompatibilität für ausführbare Umgebungen und Images sowie der Tatsache, dass CRI die Flexibilität bei der Wahl einer Laufzeit bietet, perfekt.

Diese mögliche Flexibilität und Auswahl macht das Container-Ökosystem wirklich bemerkenswert und ist auch eine sehr wichtige Voraussetzung für die seit 2014 stark gewachsene Industrie. An der Schwelle von 2019 und den folgenden Jahren sehe ich eine glänzende Zukunft mit fortwährender Innovation und Flexibilität für diejenigen, die Container-basierte Plattformen nutzen und erstellen.

Weitere Informationen zu diesem Thema finden Sie in einer kürzlich von Phil Estes auf der QCon NY gehaltenen Rede: „ CRI Runtimes Deep Dive: Wer läuft mit meinem Kubernetes Pod!? "

PS vom Übersetzer


Lesen Sie auch in unserem Blog:


Jetzt auch beliebt: