runc ist die Low-Level-Container-Runtime, die einzelne Container-Prozesse direkt mit dem Linux-Kernel erzeugt und startet. Sie ist die Referenz-Implementierung der OCI-Runtime-Spezifikation der Open Container Initiative und die unterste Schicht im Container-Stack: Docker und containerd nutzen runc für das eigentliche Starten.
Was runc macht
runc entstand aus libcontainer, der Bibliothek, die Docker ursprünglich für die Isolation verwendete. Wenn ein Container gestartet wird, übergibt die darüberliegende High-Level-Runtime ein OCI-Bundle — eine Sammlung mit dem Dateisystem (rootfs) und einer config.json, die genau beschreibt, was der Container darf. runc richtet dann die Isolation ein:
- Namespaces: getrennte Sicht auf Prozesse, Netzwerk, Dateisystem und mehr.
- cgroups: Begrenzung von CPU, Arbeitsspeicher und I/O.
- Root-Dateisystem: der Container sieht nur sein eigenes Dateisystem.
- Prozessstart: der eigentliche Befehl läuft mit den konfigurierten Rechten.
Stellenwert im Stack
runc allein ist für den Alltag zu nackt — es gibt keine Image-Verwaltung und keine Netzwerk-Komfortfunktionen. Seine Aufgabe ist die saubere, sichere Ausführung eines einzelnen Prozesses. Die Verantwortung ist damit klar geteilt: High-Level-Runtimes wie containerd und CRI-O kümmern sich um Images und Lebenszyklus, runc um den Kernel-Kontakt. Docker ruft intern diese Kette auf: Client → Daemon → containerd → runc.
Alternativen
Neben runc gibt es weitere OCI-konforme Low-Level-Runtimes wie crun (in C geschrieben, oft bei Podman) oder youki (in Rust). Sie sind in der Regel austauschbar, weil alle dieselbe OCI-Spezifikation umsetzen. runc bleibt jedoch die am weitesten verbreitete und am gründlichsten getestete Variante.
Mehr dazu: containerd, CRI-O, Container-Runtime, Kubernetes, Docker.