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.

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.

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.

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

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:

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: