Virtualisierung
Container-Runtime
Eine Container-Runtime führt Container-Images aus, isolierte Prozesse über Linux-Namespaces und cgroups; etwa Docker, containerd, CRI-O und Podman.
- OCI-Standards
- Namespaces & cgroups
- containerd, CRI-O, Podman
- rootless möglich (Podman)
- CRI für Kubernetes
Eine Container-Runtime ist die Softwareschicht, die Container-Images ausführt: Sie startet isolierte Prozesse über Linux-Namespaces (eigene Sicht auf PIDs, Netz, Dateisystem) und cgroups (Ressourcenlimits). Container teilen sich den Host-Kernel, anders als virtuelle Maschinen mit eigenem Gast-Kernel.
Dieser Artikel erklärt die OCI-Standards, den Unterschied zwischen High-Level- und Low-Level-Runtimes, die Architekturkette von Docker über containerd zu runc, das Container Runtime Interface von Kubernetes sowie Podman und die Abgrenzung zu echten VMs und sandboxed Runtimes.
1. OCI-Standards und Runtime-Schichten
Die Open Container Initiative (OCI) standardisiert Image-Format, Laufzeitverhalten und Registry-Protokoll, sodass Images zwischen Werkzeugen portabel sind. Man unterscheidet Low-Level-Runtimes, die einen Container direkt über Kernel-Aufrufe erzeugen (Referenz: runc, Alternative crun), und High-Level-Runtimes, die zusätzlich Images, Netzwerk und Storage verwalten (containerd, CRI-O).
2. Docker, containerd, runc
Ein docker run durchläuft eine Kette: die Docker-CLI spricht den Docker-Daemon an, dieser delegiert an containerd (Image-Pull, Lifecycle), das über einen Shim runc aufruft, welches den eigentlichen Container-Prozess erzeugt. containerd ist heute die dominante High-Level-Runtime in Kubernetes-Produktionsumgebungen, Docker baut selbst darauf auf.
3. Kubernetes und das CRI
Kubernetes spricht Runtimes über das Container Runtime Interface (CRI) an, eine gRPC-Schnittstelle. CRI-fähig sind containerd und CRI-O. Die alte Docker-Anbindung über dockershim wurde mit Kubernetes 1.24 (2022) entfernt; bestehende Docker-Images laufen dank OCI-Kompatibilität trotzdem unverändert weiter. Wer Docker Engine dennoch anbinden will, nutzt den separaten Adapter cri-dockerd.
„Docker entfernt“ heißt nicht „Images unbrauchbar“
Mit dem Wegfall von dockershim verschwand nur die Docker-Engine als Kubernetes-Runtime, nicht das Image-Format. OCI-/Docker-Images laufen auf containerd und CRI-O unverändert weiter.
4. Podman: daemonless und rootless
Podman verzichtet auf einen zentralen Daemon: Jeder Container ist ein direkter Kindprozess des Nutzers. Im rootless-Modus bildet ein User-Namespace die Container-Root auf eine unprivilegierte Host-UID ab, ein kompromittierter Container erlangt so keine Host-Root-Rechte. Die CLI ist Docker-kompatibel, Container lassen sich als Pods gruppieren und über Quadlet deklarativ als systemd-Units betreiben. Buildah und Skopeo ergänzen Image-Bau und Registry-Operationen.
5. Abgrenzung zu VMs und sandboxed Runtimes
Container teilen den Host-Kernel, das macht sie schlank und schnell, aber der gemeinsame Kernel ist auch eine größere Angriffsfläche als bei VMs mit eigenem Gast-Kernel. Wo stärkere Isolation gefordert ist, ohne den Container-Workflow aufzugeben, setzen Kata Containers (leichte MicroVMs mit eigenem Kernel) oder gVisor (User-Space-Kernel, der Syscalls abfängt) an, beide OCI-kompatibel und in Kubernetes über RuntimeClass wählbar.
6. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Schlank und schnell durch geteilten Kernel, OCI-portabel | Geteilter Kernel = größere Angriffsfläche als bei VMs |
| containerd/CRI-O als ausgereifte CRI-Runtimes für Kubernetes | Docker im Cluster abgelöst; Umstellung bei Altsetups nötig |
| Podman ermöglicht rootless und daemonless Betrieb | Stärkere Isolation (Kata/gVisor) kostet Performance/Komplexität |
Häufige Fragen zu Container-Runtime
Die Docker-Engine als Kubernetes-Runtime ja, sie wurde mit Kubernetes 1.24 entfernt. Docker bleibt aber für lokale Entwicklung verbreitet, und Docker-/OCI-Images laufen auf containerd und CRI-O unverändert weiter.
Podman braucht keinen privilegierten Hintergrund-Daemon und läuft rootless: Container sind Kindprozesse des Nutzers, eine Kompromittierung erreicht keine Host-Root-Rechte. Die CLI ist Docker-kompatibel, und mit Quadlet lassen sich Container sauber als systemd-Units betreiben.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Container-Runtime im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.