CRI-O implementiert die Kubernetes Container Runtime Interface auf OCI-konformen Runtimes wie runc; dieser Text ordnet Umfang, Release-Politik und Beobachtbarkeit des Go-Projekts ein.

Darf ich cri-o/cri-o kommerziell nutzen?

Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.

Wird cri-o/cri-o noch gepflegt?

Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.

In welcher Programmiersprache ist cri-o/cri-o geschrieben?

Hauptsächlich Go, laut der Sprachstatistik von GitHub.

undefined

Auf einen Blick

Was ist das?: CRI-O implementiert die Kubernetes Container Runtime Interface auf OCI-konformen Runtimes wie runc; dieser Text ordnet Umfang, Release-Politik und Beobachtbarkeit des Go-Projekts ein.
Für wen ist es gedacht?: CRI-O passt fuer Kubernetes-Cluster, die einen auf die CRI beschraenkten, OCI-basierten Runtime-Stack wollen und auf Image-Build-Funktionen im Daemon verzichten koennen. Vor dem produktiven Einsatz sollte die Kompatibilitaetsmatrix zur eigenen Kubernetes-Version geprueft und die Version aus dem packaging-Repository installiert werden, etwa ueber die dortigen Paketquellen fuer release-1.36.
Darf ich es kommerziell nutzen?: Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
Wird es noch gepflegt?: Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
In welcher Sprache ist es geschrieben?: Hauptsächlich Go, laut der Sprachstatistik von GitHub.

Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.

TIEFGEHENDE OPEN-SOURCE-ANALYSE

Hysen Labs Redaktion · 8. August 2026 · cri-o/cri-o

Der bewusst enge Umfang hinter der Container Runtime Interface

CRI-O ist eine in Go geschriebene Implementierung der Kubernetes Container Runtime Interface (CRI), die dem Kubelet das direkte Starten und Verwalten von Open Container Initiative Containern ermoeglicht. Das README bindet den Projektumfang eng an den Umfang der CRI: Unterstuetzung mehrerer Image-Formate inklusive des Docker-Formats, Image-Download mit Trust- und Verifikationsmechanismen, Verwaltung von Image-Layern und Overlay-Dateisystemen, Lebenszyklusverwaltung von Containerprozessen, Monitoring und Logging nach CRI-Anforderung sowie Ressourcenisolierung.

Ausdruecklich ausgeschlossen sind das Bauen, Signieren und Pushen von Images sowie eine stabilisierte CLI. Kommandozeilenwerkzeuge, die im Projekt entstehen, dienen laut README nur dem Testen und erhalten keine Garantie auf Rueckwaertskompatibilitaet. Diese Begrenzung ist Programm: CRI-O will keine Konkurrenz zu Podman oder Docker sein, sondern die Integrationsstrecke zwischen OCI-konformen Runtimes und dem Kubelet. Wer eine schlanke Runtime-Komponente fuer Kubernetes sucht und Build-Funktionen separat abdeckt, findet hier eine klare Zusage; wer ein All-in-One-Werkzeug erwartet, stoesst an die definierten Grenzen. Die Metadaten verzeichnen 5.654 Sterne, 1.203 Forks, die Lizenz ist Apache-2.0.

Release-Politik: n-2 Version Skew und handgepflegte Notes

CRI-O folgt bei Minor-Versionen (1.x.y) den Kubernetes-Release-Zyklen. Patch-Releases (1.x.z) sind dagegen nicht synchronisiert: Kubernetes liefert sie monatlich, CRI-O nur bei Bedarf. Laeuft eine Kubernetes-Version aus dem Support, gilt die zugehoerige CRI-O-Version als gleichermaßen beendet. Fuer Feature-Graduierung, Deprecation und Entfernung folgt das Projekt der Kubernetes-n-2-Version-Skew-Politik, und das gilt laut README auch fuer Funktionen, die unabhaengig von Kubernetes sind.

Die Kompatibilitaetsmatrix unterscheidet zwei Zeilen: Der main-Zweig verfolgt den Kubernetes-master-Zweig und implementiert dessen Features aktiv, waehrend release-1.x-Zweige nur manuell gepflegte Bugfix-Backports erhalten. Feature-Backports in unterstuetzte Zweige entscheidet die Community von Fall zu Fall, ohne die Kompatibilitaetsmatrix zu gefaehrden; davon ausgenommen sind laut README auch unabhaengige Werkzeuge wie cri-tools. Die Release-Notes sind handgepflegt und unter cri-o.github.io/cri-o fortlaufend abrufbar. Aktuell erscheinen Patches parallel fuer mehrere Zweige: v1.36.4, v1.35.7 und v1.34.12 trugen alle dasselbe Datum, den 24. August 2026. Das bestätigt die Politik, supported Linien laufend mit Fixes zu versorgen.

OCI-Bausteine: runc, container-libs und CNI

Statt eigene Grundbausteine zu entwickeln, setzt CRI-O auf bestehende OCI-Projekte. Fuer die Laufzeit steht runc oder jede andere Implementierung der OCI-Runtime-Spec, ergaenzt um die OCI-Runtime-Tools. Die Image-Verwaltung nutzt container-libs/image, der Aufbau und die Ablage von Image-Layern laufen ueber container-libs/storage. Netzwerkfunktionen stammen aus CNI, dem Container Network Interface.

Diese Zusammensetzung erklaert, warum CRI-O klein gehalten werden kann: Das Projekt implementiert die CRI-gRPC-Schnittstelle und orchestriert die darunterliegenden Bibliotheken. Die Entwicklung ist historisch ueber einen Design-Vorschlag in der Kubernetes-Community verankert, das README nennt dazu den Pull Request 26788 im Kubernetes-Repository; Fragen und Issues gehoeren in den sig-node-Slack-Kanal. Fuer den Betrieb bedeutet der Aufbau, dass sich Verhalten bei Images, Speicher und Netzwerk aus den Konfigurationen der container-libs ergibt und nicht aus CRI-O-spezifischen Optionen. Eine Roadmap liegt in der Datei roadmap.md, der Fortschritt wird in einem eigenen Feature-Roadmap-GitHub-Projekt nachverfolgt.

Konfiguration mit crio.conf, policy.json und storage.conf

Der Daemon bietet den Befehl crio(8) mit der Konfigurationsdatei crio.conf(5). Fuer Signaturpruefung verweist das README auf policy.json, fuer Registry-Einstellungen auf registries.conf und fuer die Speicherablage auf storage.conf; alle drei stammen aus den container-libs-Repositories. Ein Migrationsleitfaden zu Annotations dokumentiert die Kubernetes-empfohlene Benennung.

Neben dem Daemon gibt es den Unterbefehl crio status, der auf eine HTTP-API zugreift und Unterbefehle wie config, info und containers mitbringt. Diese Trennung zwischen Daemon-Konfiguration und Statusabfrage folgt dem ueblichen Muster von Systemdiensten. Wer CRI-O aufsetzen will, findet die eigentlichen Installationsschritte nicht im README selbst, sondern in einem separaten Installationsleitfaden sowie einem Build-Leitfaden fuer den Quellcode; das packaging-Repository haelt die Paketquellen vor. Fuer ein lokales Testcluster beschreibt das README local-up-cluster.sh aus dem Kubernetes-Repository mit Umgebungsvariablen wie CGROUP_DRIVER=systemd, CONTAINER_RUNTIME=remote und CONTAINER_RUNTIME_ENDPOINT='unix:///var/run/crio/crio.sock'. So laesst sich die Runtime ohne ein vollstaendiges Setup ausprobieren.

HTTP-Status-API, Metriken und Tracing im Betrieb

Zusaetzlich zur gRPC-Schnittstelle der CRI stellt CRI-O eine HTTP-API auf einem Unix-Socket bereit. Das README warnt klar: Diese API ist nicht stabil und sollte nicht in der Produktion verwendet werden. Verfuegbare Endpunkte sind /info, /containers/:id, /config, /pause/:id, /unpause/:id sowie die Debug-Pfade /debug/goroutines und /debug/heap. Fuer die Fehlersuche auf einem Knoten sind damit Live-Informationen zu Containern und Speicherverhalten abrufbar, ohne zusaetzliche Werkzeuge zu installieren.

Fuer den regelmaessigen Betrieb verweist das README auf getrennte Leitfaedene fuer Metriken und Tracing, deren Inhalte dort nicht wiederholt werden; ausserdem gibt es eine Sammlung von Debugging-Tipps. Das HTTP-Interface ergaenzt die CRI, ersetzt aber keine ueberwachte Produktionspipeline: Wer dauerhaft Observability braucht, sollte die Metriken ueber die beschriebenen Leitfaedene anbinden. Die vorsichtige Kennzeichnung der Status-API als instabil ist hilfreich, weil sie Skripte auf Abstraktionen verweist, die ueber Versionsgrenzen Bestand haben, naemlich die CRI und die stabilisierten Konfigurationsdateien.

Sicherheitsprozess, OCI-Hooks und Governance

Schwachstellenmeldungen laufen ueber den in SECURITY.md beschriebenen Prozess; das Repository fuehrt ausserdem einen OpenSSF Scorecard und ein Best-Practices-Badge in den Metadaten. OCI-Hooks lassen sich laut README anhand der Podman-Hooks-Dokumentation konfigurieren, womit Lifezykluserweiterungen ohne Eingriff in den Daemon moeglich sind. Die Lizenz ist Apache-2.0.

Die Community-Kanaele sind klar verteilt: GitHub-Issues und Pull-Requests fuer die Entwicklung, der sig-node-Slack-Kanal fuer Fragen, ein woechentliches, fuer alle offenes Meeting und eine Governance-Datei fuer Entscheidungswege. Ein eigenes README-Kapitel richtet sich an KI-Coding-Assistenten und bündelt Projektkontext, Workflow-Muster und Entwicklungsrichtlinien. Die CI teilt sich laut README in GitHub Actions und OpenShift CI (Prow) auf, wobei periodische Jobs wie periodic-ci-cri-o-cri-o-main-periodics-setup-periodic und eine Fedora-Variante die Testimages bauen. Fuer Kubernetes-Betreiber, die eine Runtime ohne eingebauten Build-Zweig suchen, ist das ein rundes Bild: enger CRI-Scope, dokumentierte Sicherheitsprozesse und eine Wartung, die an den Kubernetes-Zyklen haengt.

Redaktionelles Fazit

CRI-O passt fuer Kubernetes-Cluster, die einen auf die CRI beschraenkten, OCI-basierten Runtime-Stack wollen und auf Image-Build-Funktionen im Daemon verzichten koennen. Vor dem produktiven Einsatz sollte die Kompatibilitaetsmatrix zur eigenen Kubernetes-Version geprueft und die Version aus dem packaging-Repository installiert werden, etwa ueber die dortigen Paketquellen fuer release-1.36.

Offizielle Quellen

Community-Notizen