Definition „Container Runtime Interface using OCI“ Was ist CRI-O?

CRI-O ist eine Implementierung des Kubernetes CRI, sprich Container Runtime Interface von Red Hat. Container sollen sich damit deutlich einfacher verwalten lassen, da die Notwendigkeit entfällt, zusätzlichen Code ausführen. Gleiches gilt für ein etwaiges Tooling.

Bei CRI-O handelt es sich um ein Kofferwort aus Container Runtime Interface (CRI) und Open Container Initiative (OCI). CRI gestattet es Kubeletes, unterschiedliche Runtimes für Container zu verwenden. Dabei muss Kubernetes nicht jedes Mal wieder kompiliert werden.

Bevor das Interface von Red Hat veröffentlicht wurde, war Kubernetes an spezielle Runtimes gekoppelt. CRI löste diese Verbindung. Mit CRI-O wurde dieser Prozess fortgeführt: Nun können OCI-kompatible Container komplett unabhängig von zusätzlichem Code oder Tooling sowohl gestartet wie auch gestoppt werden.

So funktioniert CRI-O

• 1. Kubernetes möchte einen spezifischen Container starten.

• 2. Hierfür spricht es CRI-O an.

• 3. Das Interface spricht die Image- und die Speicher-Bibliothek des Containers an.

• 4. Zeitgleich wird die Runtime aktiviert.

• 5. Die Runtime startet den Container im Zusammenspiel mit den Bibliotheken.

• 6. Dabei teilt die Runtime dem Linux Kernel mit, welche Prozesse genau ausgeführt werden müssen.

Das Stoppen von Containern funktioniert prinzipiell auf identische Weise. Nur wird statt des Start-Befehls das Kommando gegeben, den Container anzuhalten.

Die Schwachpunkte von CRI-O

Irgendwann einmal soll CRI-O wirklich mit allen OCI-Containern funktionieren. Wann diese vollständige Komptabilität erreicht sein wird, ist jedoch noch unklar. Unterstützt werden bislang runC- sowie Clear Container Runtimes.

Zudem gilt: Wer Images erstellen will, muss hierfür nach wie vor auf Source-to-Image von OpenShift oder auf Buildah vertrauen. Das Command Line Interface von CRI-O ist hierfür nicht geeignet. Es ist lediglich dafür vorgesehen, um CRI-O zu überprüfen. Das Container-Management in einer Produktionsumgebung kann es hingegen nicht durchführen.

CRI-O ist ein Problem für Docker

Zu Beginn hatte Kubernetes nur eine einzige Runtime für Container: Docker. Später kam rkt hinzu. Das Hinzufügen weiterer Runtimes erwies sich jedoch als aufwendig und schwierig. Docker hatte deshalb stets eine Art Sonderrolle. CRI-O zielt darauf ab, diese zu beenden.

Docker hat dies erkannt und mit dem „containerd“-System selbst eine „leichtgewichtige“ Option geschaffen, um Container zu verwalten. Seit Version 1.1 ist sogar ein natives Plug-in für CRI mit an Bord. Allerdings ist containerd nicht für den Gebrauch mit Kubernetes optimiert worden, sondern wurde für vielfältige Einsatzzwecke entwickelt. Dies spricht dafür, dass Docker die Rolle als „die Standard-Runtime“ für Kubernetes verlieren dürfte.

(ID:46525256)