Container-Runtime-Shift: OCI-Standards und Podman verdrängen Docker aus Linux-Infrastrukturen

Container-Runtimes sind 2024 kein Randthema für Kubernetes-Spezialisten mehr. Wer heute Self-Hosting-Infrastrukturen betreibt, Fedora oder RHEL einsetzt oder einfach nur verstehen will, was hinter podman run passiert, kommt an OCI-Standards und dem Shift weg von Docker als Cluster-Runtime nicht mehr vorbei. Das Ökosystem hat sich strukturell verändert – und zwar schneller als viele Distributionen ihre Dokumentation angepasst haben.

Warum Docker als Kubernetes-Runtime Geschichte ist

Seit Kubernetes 1.24, veröffentlicht im Mai 2022, ist der sogenannte Dockershim aus dem Kubernetes-Kern entfernt. Das bedeutet: Docker Engine ist seitdem keine direkt unterstützte Container-Runtime mehr für Kubernetes-Cluster. Diese Entscheidung hat praktische Konsequenzen, die bis heute in vielen Homelab- und Self-Hosting-Setups noch nicht vollständig angekommen sind.

Was stattdessen dominiert, ist nüchtern. Laut CNCF-Daten aus dem Jahr 2025 laufen mittlerweile rund 95 Prozent aller Kubernetes-Cluster mit containerd als Runtime. Die Managed-Kubernetes-Angebote von AWS (EKS), Google (GKE) und Microsoft (AKS) nutzen containerd als Default. CRI-O ist die zweite große Option, vor allem im Red Hat- und OpenShift-Umfeld. Docker Engine ist im Cluster-Betrieb weitgehend irrelevant geworden.

Das ändert aber nichts daran, dass Docker als Entwicklerwerkzeug nach wie vor relevant ist. Wer lokal Images baut, compose-Dateien testet oder schnell einen Container hochzieht, nutzt in der Praxis oft noch Docker. Der entscheidende Unterschied: Was auf einem Entwickler-Laptop läuft, muss nicht dieselbe Runtime nutzen wie der Produktions-Cluster. Das war früher implizit angenommen, heute ist es explizit entkoppelt.

OCI-Standards: Die eigentliche Klammer hinter allem

Dass dieser Wechsel so reibungsarm verläuft, liegt an den Standards der Open Container Initiative (OCI), gegründet im Juni 2015. Drei Spezifikationen bilden heute die Basis aller relevanten Container-Runtimes: die Runtime-Spec definiert, wie ein Container-Prozess ausgeführt wird; die Image-Spec legt fest, wie ein Container-Image strukturiert ist; die Distribution-Spec standardisiert die API für Registry-Push- und Pull-Operationen.

Praktisch bedeutet das: Ein Image, das mit Docker gebaut wurde, lässt sich mit Podman, containerd oder CRI-O ausführen, sofern es OCI-konform ist. Das ist bei modernen Docker-Images faktisch immer der Fall. Die alte Annahme, Docker-Images seien irgendwie Docker-exklusiv, ist technisch falsch. Sie halten sich trotzdem hartnäckig in Einsteiger-Dokumentationen und älteren Tutorials.

Neu hinzugekommen ist die Nutzung von OCI-Registries als universelles Speichersystem für mehr als nur ausführbare Container. OCI-Artefakte sind Dateien – SBOMs, Security-Policies, Konfigurations-Bundles, ML-Modelle – die wie Images in einer Registry abgelegt werden, aber keinen ausführbaren Rootfs-Container darstellen. Das Prinzip „Everything-as-an-OCI-Artifact“ gewinnt Fahrt, und Podman ist dabei vorne dabei.

Podman: Mehr als ein Docker-Klon mit anderem Namen

Wer Podman bisher als Docker-Wrapper mit Red-Hat-Logo abgetan hat, liegt architektonisch daneben. Podman ist eine eigenständige Container-Engine ohne zentralen Daemon. Wo Docker einen privilegierten Background-Prozess betreibt, der alle Containervorgänge koordiniert, startet Podman Containerprozesse direkt – als Kind-Prozesse des aufrufenden Nutzers oder via systemd-Integration.

Das hat konkrete Sicherheitsimplikationen. Rootless-Container sind bei Podman kein optionaler Modus, sondern der vorgesehene Default-Workflow. Ein Container, der unter dem eigenen Benutzerkonto läuft, kann bei einem Breakout nicht auf systemweite Ressourcen zugreifen. Für Multi-Tenant-Setups oder Self-Hosting-Instanzen, bei denen mehrere Dienste auf einem Host laufen, ist das ein echter Unterschied zum klassischen Docker-Setup mit root-Daemon.

Die CLI-Kompatibilität zu Docker ist bewusst so gestaltet, dass podman run, podman stop, podman start und andere Befehle dieselbe Syntax erwarten wie ihre Docker-Pendants. Wer Docker gewohnt ist, kann Podman oft sofort produktiv nutzen. Dass darunter eine komplett andere Architektur arbeitet, merkt man erst dann, wenn man tiefer in systemd-Unit-Generierung, Netzwerk-Isolation per Netavark oder den Aufbau von Rootless-Namespaces einsteigt.

Im November 2024 hat das Podman-Team einen Antrag gestellt, Podman, Podman Desktop, Buildah und Skopeo als CNCF-Sandbox-Projekte aufzunehmen. Die Entscheidung des Technical Oversight Committee wird für etwa Mai 2025 erwartet. Das ist kein Marketing-Move. Ein CNCF-Sandbox-Status würde bedeuten, dass diese Tools als Teil des Cloud-Native-Ökosystems wahrgenommen werden – und nicht mehr nur als Red-Hat-spezifisches Tooling.

runc gegen crun: Die Runtime unter der Runtime

Sowohl Docker als auch Podman nutzen unter der Haube eine OCI-Runtime, die den eigentlichen Containerprozess startet. Die verbreitetste ist runc, in Go geschrieben und seit Jahren der Referenz-Implementierung der OCI-Runtime-Spec. Weniger bekannt, aber in Red-Hat-Umgebungen bevorzugt: crun, eine C-Implementierung derselben Spec.

Red Hat gibt in der offiziellen RHEL-Dokumentation an, dass crun ein bis zu 50-fach kleineres Binary hat und bis zu doppelt so schnell wie runc ist. Diese Zahlen stammen aus Hersteller-Messungen und sind workload-abhängig; sie sollten nicht als absolute Wahrheit für jeden Anwendungsfall übernommen werden. Aber der Trend ist real: crun hat einen deutlich geringeren Speicher-Footprint, startet schneller und ist die empfohlene Runtime in RHEL 8 und später.

Wer Podman einsetzt, kann die Runtime per --runtime-Flag wechseln oder dauerhaft in containers.conf eintragen, wahlweise systemweit unter /etc/containers/containers.conf oder nutzerspezifisch unter $HOME/.config/containers/containers.conf. Für Fedora-Nutzer ist crun längst der Default. Wer Ubuntu oder Debian nutzt und Podman aus den offiziellen Paketquellen installiert, sollte prüfen, welche Runtime aktiv ist – die Distributions-Defaults weichen hier voneinander ab.

Distribution-Ökosysteme: Wer liefert was aus der Box?

Die Frage, welche Container-Runtime auf welcher Distribution out-of-the-box verfügbar ist, ist für Self-Hosting-Setups praktisch relevant. Fedora hat Podman schon seit Jahren als vorinstalliertes Tool – kein Docker im Standard-Desktop, kein Daemon, der bei jedem Boot startet. Das spiegelt Red Hats klare Positionierung wider: Podman als Upstream-Basis, Docker als Optionalpaket für Leute, die es wollen. Wer auf Fedora als täglichem Arbeits- und Entwicklungssystem unterwegs ist, findet in unserem Vergleich von Fedora mit GNOME und KDE Plasma als Power-User-Workstation eine nützliche Einordnung, wie unterschiedlich die Desktop-Umgebungen mit diesem vorausgewählten Tooling umgehen.

Debian und Ubuntu shippen Docker nicht in ihren offiziellen Repositories in der Form, die Docker Inc. vertreibt. Wer Docker Engine auf Debian oder Ubuntu will, fügt das offizielle Docker-Repository hinzu. Was in den offiziellen Debian-Repos liegt, ist docker.io – eine ältere, von Debian gepflegte Version, die oft nicht dem aktuellen Stand entspricht. Für containerd gibt es dagegen in neueren Ubuntu- und Debian-Versionen direkte Pakete, die für Kubernetes-Setups ausreichend sind.

Meiner Einschätzung nach ist das Distributions-Splitting bei Docker-Paketen ein unterschätztes Problem. Wer ein Tutorial befolgt, das „docker.io“ und die offizielle Docker-CE-Version gleichsetzt, baut auf unterschiedlichen Ständen. Für produktive Self-Hosting-Infrastrukturen sollte man einmal grundsätzlich klären, woher die Container-Runtime kommt, und diese Entscheidung dokumentieren – nicht dem nächsten Paket-Update überlassen.

Sicherheitsaspekte: Rootless Container und Netzwerk-Isolation

Rootless-Container sind der sicherheitsrelevanteste Trend in der aktuellen Container-Praxis. Wenn ein Containerprozess als regulärer Nutzer läuft, ohne privilegierten Daemon, sind die Angriffsflächen strukturell kleiner. Kein root-Daemon, der bei einem Exploit direkt auf das Host-System durchschlägt. Für Homelab-Setups mit mehreren exponierten Diensten ist das kein akademisches Argument.

Podman setzt Rootless-Container mit User-Namespaces um. Praktisch bedeutet das: Der Prozess im Container läuft intern als root (UID 0), aber im Host-Namespace mapped auf eine reguläre User-ID. Netzwerk-Isolation läuft dabei über Netavark und Aardvark-DNS als Nachfolger des älteren CNI-Stacks. Diese Komponenten sind in neueren Podman-Versionen der Default und ersetzen das ältere slirp4netns für Rootless-Netzwerke in vielen Szenarien.

Für Kubernetes-Runtimes wie containerd und CRI-O gibt es eine ähnliche Richtung: RuntimeClass-Definitionen und gVisor oder Kata Containers als Sandboxing-Layer bieten zusätzliche Isolation. Das ist besonders für Multi-Tenant-Kubernetes-Setups relevant, bei denen Workloads aus unterschiedlichen Quellen auf demselben Cluster laufen.

Was ich dabei problematisch finde: Viele Tutorial-Anleitungen für Docker-basierte Self-Hosting-Setups laufen noch mit privilegiertem Docker-Daemon und bind-mounts auf /var/run/docker.sock. Das ist eine weitverbreitete Fehlkonfiguration, die effektiv Root-Zugriff auf den Host ermöglicht. Podman macht es strukturell schwerer, in diese Falle zu tappen, aber es ist keine Garantie.

Migration in der Praxis: Was wirklich zu tun ist

Der Umstieg von Docker auf Podman ist in vielen Szenarien weniger aufwändig als erwartet – aber er verlangt trotzdem eine strukturierte Vorgehensweise. Wer einfach den Docker-Daemon abschaltet und Podman installiert, wird in den meisten Fällen feststellen, dass einzelne Befehle sofort funktionieren. Die eigentlichen Reibungspunkte liegen woanders.

Ein typisches Praxis-Szenario: Ein Self-Hosting-Server betreibt mehrere Dienste über docker-compose.yml-Dateien, die mit docker compose up -d gestartet werden. Podman bringt mit podman-compose eine Kompatibilitätsschicht, die für einfache Compose-Definitionen funktioniert. Sobald aber Netzwerk-Aliase, Health-Checks mit Docker-spezifischen Bedingungen oder Volume-Driver-Konfigurationen ins Spiel kommen, entstehen Differenzen. Der pragmatische Weg: Dienste schrittweise auf Podman-systemd-Units umstellen, statt alle Compose-Dateien gleichzeitig zu migrieren.

Wer Buildah als Companion-Tool zu Podman nutzt, gewinnt eine weitreichende Kontrolle über den Image-Build-Prozess – ohne Dockerfile-Pflicht. Buildah kann Images schichtweise per Shell-Skript aufbauen, was in CI-Pipelines manchmal sauberer ist als ein monolithisches Dockerfile. Skopeo ergänzt das Werkzeugset für Registry-Operationen: Images zwischen Registries kopieren, Manifeste inspizieren, ohne das Image lokal zu pullen. Diese drei Tools – Podman, Buildah, Skopeo – arbeiten alle ohne gemeinsamen Daemon und können nebeneinander auf einem System koexistieren, ohne sich gegenseitig zu blockieren.

Ein Gegenargument, das in der Praxis oft kommt: Docker Compose ist ausgereifter, besser dokumentiert und hat mehr Community-Beispiele. Das stimmt. Wer komplexe Compose-Setups mit vielen Abhängigkeiten betreibt und nicht aktiv auf Kubernetes migrieren will, hat gute Gründe, Docker noch eine Weile beizubehalten. Die Entscheidung sollte aber bewusst getroffen werden – nicht weil das nächste Tutorial Docker voraussetzt, sondern weil der spezifische Anwendungsfall es rechtfertigt.

CI/CD-Pipelines: Container-Runtimes im automatisierten Build-Prozess

Ein Bereich, der in der Diskussion um Container-Runtimes oft unterbelichtet bleibt, ist der Einsatz in CI/CD-Pipelines. GitHub Actions, GitLab CI und Jenkins laufen zunehmend in containerisierten Runner-Umgebungen, die selbst keine Docker-Sockets mehr exponieren. Das Stichwort ist „Docker-in-Docker“ – ein Ansatz, der privilegierte Container voraussetzt und aus Sicherheitssicht problematisch ist.

Buildah und Podman können OCI-konforme Images bauen, ohne einen laufenden Docker-Daemon vorauszusetzen und ohne privilegierte Container zu benötigen. Für GitLab-CI-Setups mit rootless Runnern ist das ein handfester Vorteil. Kaniko, ein weiteres Tool aus dem Google-Umfeld, verfolgt denselben Ansatz und ist in Kubernetes-nativen Build-Umgebungen weit verbreitet. Die Gemeinsamkeit: Alle diese Werkzeuge bauen auf OCI-Standards, und das resultierende Image ist für jede OCI-konforme Runtime verwendbar.

Wer heute eine neue CI/CD-Pipeline aufbaut, sollte Docker-in-Docker aktiv vermeiden und stattdessen auf rootless Build-Tools setzen. Das ist kein Komfort-Verzicht, sondern eine Sicherheitsentscheidung, die in Security-Audits zunehmend verlangt wird.

OCI-Artefakte und Podman 5.x: Wohin die Entwicklung geht

Podman Desktop 1.16, die stabile Version vom Februar 2025, bringt experimentelle Features für OCI-Artefakte. Podman 5.4 war zum selben Zeitpunkt im Release-Candidate-Status; die neuen CLI-Kommandos für OCI-Artefakte sind in der Entwickler-Kommunikation explizit als „sehr früh“ und „noch nicht vollständig“ beschrieben. Die CLI kann sich noch ändern. Wer heute OCI-Artefakt-Workflows baut, baut auf Sand – das ist normale Open-Source-Entwicklung, aber man sollte es wissen.

Der Anwendungsfall dahinter ist trotzdem interessant. Volumes, die direkt aus OCI-Artefakten in eine Registry gemountet werden, würden Build-Workflows und Supply-Chain-Mechanismen vereinfachen. SBOMs, die neben dem Image in derselben Registry liegen und denselben Tag-Mechanismus nutzen, machen Signaturen und Verifikation nachvollziehbarer. Das ist kein Selbstzweck, sondern adressiert echte Probleme in der Software-Supply-Chain-Sicherheit, die seit den Ereignissen rund um SolarWinds und Log4Shell stärker im Fokus stehen.

Die DevClass-Berichterstattung zu Podman Desktop 1.16 gibt einen guten Überblick über den aktuellen Feature-Stand. Wer produktiv mit OCI-Artefakten arbeiten will, sollte zusätzlich die Red-Hat-Dokumentation zur Runtime-Auswahl kennen, die runc gegen crun einordnet und konkrete Konfigurations-Pfade nennt.

Praktische Konsequenzen für Self-Hosting-Infrastrukturen

Wer heute eine Self-Hosting-Infrastruktur neu aufbaut, steht vor einer klareren Entscheidung als noch vor drei Jahren. Für einen einzelnen Server mit ein paar Diensten ist Podman mit systemd-Units eine saubere, dauerhafte Lösung ohne laufenden Daemon. Die Dienste starten bei Boot, erhalten automatisch Neustart-Policies, und die Logs laufen über journald wie alle anderen systemd-Dienste.

Für ein Kubernetes-Cluster – auch ein kleines mit k3s oder MicroK8s – ist containerd die pragmatische Wahl. Es ist der Default, es ist getestet, und es gibt keine Kompatibilitäts-Überraschungen bei Kubernetes-Upgrades. CRI-O ist die sinnvolle Alternative, wenn man im Red-Hat-Ökosystem unterwegs ist oder OpenShift als Upstream nutzt.

Docker als Runtime ist für neue Setups schwer zu empfehlen. Als lokales Entwicklerwerkzeug auf dem Laptop bleibt Docker praktisch, vor allem wenn man Docker Compose-Workflows nutzt und nicht auf Podman Compose oder die compose-Kompatibilität von Podman wechseln will. Aber im Cluster, auf dem Server, in der CI-Pipeline: Dort hat containerd längst das Steuer übernommen. Wer das ignoriert, holt technische Schulden ins Haus, die beim nächsten Kubernetes-Upgrade fällig werden.

Die OCI-Standards halten dieses Ökosystem zusammen. Nicht als politisches Bekenntnis, sondern als technische Tatsache: Images laufen überall, Registries sind kompatibel, und der Wechsel zwischen Runtimes ist kein Migrationsproject mehr. Das ist der eigentliche Fortschritt der letzten Jahre – und ein Argument dafür, technische Entscheidungen heute nicht mehr an einen einzigen Hersteller zu ketten.

Welche Runtime läuft aktuell auf Ihrem Server – und haben Sie das bewusst entschieden oder einfach das Paket installiert, das im Tutorial stand?