Was ist CRI-O?

Bei CRI-O handelt es sich um eine Im­ple­men­tie­rung des Container Runtime Interface (CRI) für Ku­ber­netes, unter Nutzung von „Open Container In­itia­ti­ve” (OCI) Images und Lauf­zeit­um­ge­bun­gen (Runtimes). Das Projekt wurde im Jahr 2016 von der Firma „Red Hat“ gestartet und im Frühjahr 2019 an die „Cloud Native Computing Foun­da­ti­on“ (CNCF) übergeben.

Um die Funk­ti­ons­wei­se von CRI-O und das Wech­sel­spiel mit ver­wand­ten Tech­no­lo­gien zu verstehen, lohnt sich ein Blick auf die his­to­ri­sche Ent­wick­lung der con­tai­ner­ba­sier­ten Vir­tua­li­sie­rung. Grundlage für die Ent­ste­hung war die Software Docker, die die Vir­tua­li­sie­rung einzelner Apps auf Basis leicht­ge­wich­ti­ger Container in den Main­stream brachte. Vorher verstand man unter Vir­tua­li­sie­rung vor allem den Einsatz vir­tu­el­ler Maschinen. Eine virtuelle Maschine enthält ein kom­plet­tes Be­triebs­sys­tem, wo­hin­ge­gen mehrere Container auf einen gemeinsam genutzten Be­triebs­sys­tem-Kernel zugreifen.

Ein Container enthält für ge­wöhn­lich eine einzelne App, die oft einen Mi­cro­ser­vice zur Verfügung stellt. Im prak­ti­schen Einsatz muss in der Regel eine Vielzahl von Con­tai­nern zusammen gesteuert werden, um eine komplette Anwendung zu rea­li­sie­ren. Die ko­or­di­nier­te Ver­wal­tung ganzer Gruppen von Con­tai­nern ist als Or­ches­trie­rung bekannt.

Auch wenn die Or­ches­trie­rung mit Docker und Tools wie Docker Swarm machbar ist, hat sich mit Ku­ber­netes eine Al­ter­na­ti­ve zu Docker durch­ge­setzt. Ku­ber­netes fasst mehrere Container in einem so­ge­nann­ten 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 aus­schlag­ge­ben­den Probleme mit Docker war die mo­no­li­thi­sche Ar­chi­tek­tur der Software. Der Docker-Daemon lief mit Root-Rechten und war für eine Vielzahl un­ter­schied­li­cher Aufgaben zuständig: vom Her­un­ter­la­den der Container-Images, über die Aus­füh­rung in der Lauf­zeit­um­ge­bung, bis zum Erstellen neuer Images. Diese Ver­qui­cking ei­gent­lich un­ab­hän­gi­ger Bereiche verstößt gegen das Software-Ent­wick­lungs-Prinzip „Se­pa­ra­ti­on of concerns“ („Trennung der Belange“) und führt in der Praxis u. a. zu Si­cher­heits­pro­ble­men. Daher folgten An­stren­gun­gen, die einzelnen Kom­po­nen­ten zu ent­kop­peln.

Beim Er­schei­nen von Ku­ber­netes enthielt der Ku­ber­netes-Daemon kubelet eine hart­co­dier­te Docker-Lauf­zeit­um­ge­bung. Jedoch zeigte sich schon bald die Not­wen­dig­keit, auch andere Runtimes zu un­ter­stüt­zen. Eine Mo­du­la­ri­sie­rung der einzelnen Aspekte versprach eine ver­ein­fach­te Wei­ter­ent­wick­lung sowie erhöhte Si­cher­heit. Um ver­schie­de­ne Runtimes mit Ku­ber­netes kom­pa­ti­bel zu machen, wurde eine Schnitt­stel­le definiert: das Container Runtime Interface (CRI). CRI-O ist eine spe­zi­fi­sche Im­ple­men­ta­ti­on dieser Schnitt­stel­le.

Der grund­le­gen­de Ablauf bei der Nutzung von CRI-O besteht aus den folgenden Schritten:

1. Her­un­ter­la­den eines OCI-Container-Images
2. Entpacken des Images in ein OCI-Runtime-Da­tei­sys­tem-Bundle
3. Ausführen des Con­tai­ners durch eine OCI-Runtime

CRI-O kommt derzeit vor allem als Be­stand­teil von Red Hats OpenShift-Pro­dukt­se­rie zum Einsatz. Es exis­tie­ren OpenShift-Im­ple­men­ta­tio­nen für die Cloud-Platt­for­men aller großen Anbieter. Des Weiteren lässt sich die Software als Teil der OpenShift Container Platform in öf­fent­li­chen oder privaten Re­chen­zen­tren betreiben. Hier eine Übersicht der ver­schie­de­nen OpenShift-Produkte:

Bei CRI-O handelt es sich um eine relativ neue Ent­wick­lung auf dem Gebiet der Container-Vir­tua­li­sie­rung. His­to­risch bedingt existiert eine Reihe an al­ter­na­ti­ven Container-Runtimes. Das wohl aus­ch­lag­ge­bends­te Al­lein­stel­lungs­merk­mal von CRI-O ist der singuläre Fokus auf Ku­ber­netes als Umgebung. Mit CRI-O wird Ku­ber­netes in die Lage versetzt, Container ohne weitere Tools oder spezielle Code-An­pas­sun­gen direkt aus­zu­füh­ren. CRI-O selbst un­ter­stützt die exis­tie­ren­den, OCI-kom­pa­ti­blen Runtimes. Hier eine Übersicht aktiv ent­wi­ckel­ter und häufig ein­ge­setz­ter Runtimes: