Podman entstand nicht aus dem Bedürfnis heraus, Docker zu ersetzen, sondern aus einem völlig anderen technischen Kontext. Während Docker ursprünglich ein monolithisches Werkzeug war, das Build, Runtime und Distribution vereinte, entstand Podman aus der Arbeit an CRI-O – einer Kubernetes-kompatiblen Container-Laufzeitumgebung, die sich strikt an die Vorgaben der Open Container Initiative (OCI) hält.
Der Ursprung von Podman liegt damit in produktionsorientierten Laufzeitkonzepten für orchestrierte Umgebungen – nicht im klassischen Entwicklerfokus. Dieser Ausgangspunkt prägt das Werkzeug bis heute.
Mit der Reifung von Kubernetes wurde deutlich, dass dessen Anforderungen nicht zu Dockers Architektur passen. Kubernetes benötigt:
Docker erfüllte diese Anforderungen nur teilweise. Die Reaktion war die Entwicklung der Container Runtime Interface (CRI): eine bewusst minimal gehaltene Laufzeitschnittstelle. CRI-O wurde als Implementierung dieser Schnittstelle entwickelt – leichtgewichtig, standardkonform, basierend auf OCI.
Podman nutzt dieselben Bibliotheken wie CRI-O und ist damit eng verwandt, allerdings mit dem Ziel, Container auch außerhalb eines orchestrierten Clusters verwalten zu können.
Dieselbe technische Basis, aber zwei unterschiedliche Rollen.
Die Open Container Initiative (OCI) entstand, um proprietäre Formate und Lock-in zu verhindern. Docker dominierte die frühe Containerwelt so stark, dass gemeinsame Standards notwendig wurden, um eine unabhängige Laufzeitlandschaft zu ermöglichen.
Die OCI definierte zwei zentrale Spezifikationen:
CRI-O wurde entwickelt, um diese Spezifikationen vollständig umzusetzen, ohne zusätzliche Logikschichten oder interne Abweichungen.
Podman entstammt demselben technischen Umfeld. Das führt zu mehreren Eigenschaften:
Zentrale Komponenten aus dem CRI-O-Umfeld werden direkt auch von Podman genutzt. Besonders wichtig ist Conmon, ein kleines, stabiles C-Programm, das zwischen CLI und Runtime vermittelt.
Conmon übernimmt:
Podman nutzt Conmon auf dieselbe Weise wie CRI-O. Damit ergibt sich ein konsistentes Verhalten:
Dadurch ist das Verhalten lokal mit Podman nahezu identisch zu dem Verhalten in Kubernetes-Laufzeitumgebungen.
Ein weiteres Erbe aus dem CRI-O/OCI-Kontext ist die klare Modularisierung:
Diese Trennung verhindert die Entstehung eines Monolithen und sorgt dafür, dass jedes Werkzeug eine klar definierte technische Rolle hat. Build-Prozesse können isoliert laufen, Image-Transporte erfolgen ohne Daemon, und Podman bleibt auf seine Laufzeitaufgaben fokussiert.
CRI-O wurde zuerst entwickelt – Podman folgte später. Diese Reihenfolge erklärt mehrere Merkmale der Architektur:
Podman ist kein „CRI-O für Desktop-Nutzer“, sondern ein eigenständiges Werkzeug mit denselben strukturellen Fundamenten.
Ein Vergleich hilft:
Der Antriebsstrang ist derselbe, aber die Fahrzeuge unterscheiden sich.