Was ist CRI-O?

Bei CRI-O handelt es sich um eine Implementierung des Container Runtime Interface (CRI) für Kubernetes, unter Nutzung von „Open Container Initiative” (OCI) Images und Laufzeitumgebungen (Runtimes). Das Projekt wurde im Jahr 2016 von der Firma „Red Hat“ gestartet und im Frühjahr 2019 an die „Cloud Native Computing Foundation“ (CNCF) übergeben.

Managed Kubernetes
Kubernetes als Managed Service von IONOS Cloud

Die ideale Plattform für performante und hochskalierbare Container-Anwendungen. Umfassend ins IONOS Cloud Ökosystem integriert und rund um die Uhr professionell betreut.

Wie funktioniert CRI-O?

Um die Funktionsweise von CRI-O und das Wechselspiel mit verwandten Technologien zu verstehen, lohnt sich ein Blick auf die historische Entwicklung der containerbasierten Virtualisierung. Grundlage für die Entstehung war die Software Docker, die die Virtualisierung einzelner Apps auf Basis leichtgewichtiger Container in den Mainstream brachte. Vorher verstand man unter Virtualisierung vor allem den Einsatz virtueller Maschinen. Eine virtuelle Maschine enthält ein komplettes Betriebssystem, wohingegen mehrere Container auf einen gemeinsam genutzten Betriebssystem-Kernel zugreifen.

Von Docker über Kubernetes zu CRI-O

Ein Container enthält für gewöhnlich eine einzelne App, die oft einen Microservice zur Verfügung stellt. Im praktischen Einsatz muss in der Regel eine Vielzahl von Containern zusammen gesteuert werden, um eine komplette Anwendung zu realisieren. Die koordinierte Verwaltung ganzer Gruppen von Containern ist als Orchestrierung bekannt.

Auch wenn die Orchestrierung mit Docker und Tools wie Docker Swarm machbar ist, hat sich mit Kubernetes eine Alternative zu Docker durchgesetzt. Kubernetes fasst mehrere Container in einem sogenannten Pod zusammen. Die Pods wiederum laufen auf Nodes genannten Maschinen – dabei kann es sich sowohl um physische als auch um virtuelle Maschinen handeln.

Eines der ausschlaggebenden Probleme mit Docker war die monolithische Architektur der Software. Der Docker-Daemon lief mit Root-Rechten und war für eine Vielzahl unterschiedlicher Aufgaben zuständig: vom Herunterladen der Container-Images, über die Ausführung in der Laufzeitumgebung, bis zum Erstellen neuer Images. Diese Verquicking eigentlich unabhängiger Bereiche verstößt gegen das Software-Entwicklungs-Prinzip „Separation of concerns“ („Trennung der Belange“) und führt in der Praxis u. a. zu Sicherheitsproblemen. Daher folgten Anstrengungen, die einzelnen Komponenten zu entkoppeln.

Beim Erscheinen von Kubernetes enthielt der Kubernetes-Daemon kubelet eine hartcodierte Docker-Laufzeitumgebung. Jedoch zeigte sich schon bald die Notwendigkeit, auch andere Runtimes zu unterstützen. Eine Modularisierung der einzelnen Aspekte versprach eine vereinfachte Weiterentwicklung sowie erhöhte Sicherheit. Um verschiedene Runtimes mit Kubernetes kompatibel zu machen, wurde eine Schnittstelle definiert: das Container Runtime Interface (CRI). CRI-O ist eine spezifische Implementation dieser Schnittstelle.

Hinweis

Machen Sie sich Kubernetes heute zunutze — mit Managed Kubernetes von IONOS.

Architektur und Funktionsweise von CRI-O

Folgende Komponenten gehören zu CRI-O:

  • Die Software-Bibliothek containers/image zum Herunterladen von Container-Images von verschiedenen Online-Quellen.
  • Die Software-Bibliothek containers/storage zum Verwalten der Container-Schichten und Erstellen des Dateisystems für die Container eines Pods.
  • Eine OCI-kompatible Runtime zum Ausführen der Container; die Standard-Runtime ist runC, es können jedoch auch andere OCI-kompatible Runtimes wie die Kata Containers genutzt werden.
  • Die Container-Netzwerk-Schnittstelle („container networking interface“, CNI) zum Erstellen des Netzwerks für einen Pod; zum Einsatz kommen Plug-ins für Flannel, Weave und OpenShift-SDN.
  • Das Container-Monitoring-Tool conmon zur kontinuierlichen Überwachung der Container.

Häufig wird CRI-O auch im Zusammenspiel mit dem Pod-Management-Tool Podman eingesetzt. Dies funktioniert, da Podman auf dieselben Bibliotheken zum Herunterladen der Container-Images und Verwalten der Container-Schichten aufsetzt wie CRI-O.

Der grundlegende Ablauf bei der Nutzung von CRI-O besteht aus den folgenden Schritten:

  1. Herunterladen eines OCI-Container-Images
  2. Entpacken des Images in ein OCI-Runtime-Dateisystem-Bundle
  3. Ausführen des Containers durch eine OCI-Runtime

Wo kommt CRI-O zum Einsatz?

CRI-O kommt derzeit vor allem als Bestandteil von Red Hats OpenShift-Produktserie zum Einsatz. Es existieren OpenShift-Implementationen für die Cloud-Plattformen aller großen Anbieter. Des Weiteren lässt sich die Software als Teil der OpenShift Container Platform in öffentlichen oder privaten Rechenzentren betreiben. Hier eine Übersicht der verschiedenen OpenShift-Produkte:

Produkt Infrastruktur Verwaltet durch Support von
Red Hat OpenShift Dedicated AWS, Google Cloud Red Hat Red Hat
Microsoft Azure Red Hat OpenShift Microsoft Azure Red Hat und Microsoft Red Hat und Microsoft
Amazon Red Hat OpenShift AWS Red Hat und AWS Red Hat und AWS
Red Hat OpenShift on IBM Cloud IBM Cloud IBM Red Hat und IBM
Red Hat OpenShift Online Red Hat Red Hat Red Hat
Red Hat OpenShift Container Platform Private Cloud, öffentliche Cloud, physische Maschine, virtuelle Maschine, Edge Kunde Red Hat, weitere
Red Hat OpenShift Kubernetes Engine Private Cloud, öffentliche Cloud, physische Maschine, virtuelle Maschine, Edge Kunde Red Hat, weitere

Wie unterscheidet sich CRI-O von anderen Runtimes?

Bei CRI-O handelt es sich um eine relativ neue Entwicklung auf dem Gebiet der Container-Virtualisierung. Historisch bedingt existiert eine Reihe an alternativen Container-Runtimes. Das wohl auschlaggebendste Alleinstellungsmerkmal von CRI-O ist der singuläre Fokus auf Kubernetes als Umgebung. Mit CRI-O wird Kubernetes in die Lage versetzt, Container ohne weitere Tools oder spezielle Code-Anpassungen direkt auszuführen. CRI-O selbst unterstützt die existierenden, OCI-kompatiblen Runtimes. Hier eine Übersicht aktiv entwickelter und häufig eingesetzter Runtimes:

Runtime Typ Beschreibung
runC Low-level OCI-Runtime Aus Docker hervorgegangene, in Go geschriebene De-facto-Standard-Runtime
crun Low-level OCI-Runtime Performante Runtime; implementiert in C statt Go
Kata Containers Virtualisierte OCI-Runtime Nutzt leichtgewichtige virtuelle Maschine (VM)
containerd High-level CRI-Runtime Nutzt standardmäßig runC
CRI-O Leichtgewichtige CRI-Runtime Kann u. a. runC, crun, Kata Containers nutzen
War dieser Artikel hilfreich?
Page top