11 Architektur von Podman

11.1 Ein Architekturmodell ohne zentrale Schaltstelle

Podman folgt einem Architekturprinzip, das sich bewusst von daemonbasierten Container-Engines unterscheidet. Statt einen permanent laufenden Hintergrundprozess zu betreiben, der Containerzustände verwaltet und als zentraler Kontrollpunkt agiert, verteilt Podman die Verantwortung auf einzelne, klar abgegrenzte Komponenten. Das Ergebnis ist ein System, das stark an klassische Unix-Prinzipien erinnert: kleine, spezialisierte Bausteine, die ineinandergreifen, ohne sich gegenseitig zu verstecken.

Diese Struktur führt zu hoher Transparenz, reproduzierbarem Verhalten und einem robusten Prozessmodell, das unabhängig von einem globalen Daemon funktioniert.

11.2 Die CLI als Steuerzentrale – jedoch ohne globale Kontrolle

Die podman-CLI ist ein reines Frontend. Sie übernimmt drei Aufgaben:

Sie steuert selbst weder die Containerprozesse noch existiert sie als zentrale Autorität. Wird die CLI beendet, laufen Container weiter. Fehler im Steuerwerkzeug haben keinen Einfluss auf bereits laufende Prozesse. Diese Entkopplung ist ein prägendes Element der Architektur.

11.3 Conmon: Ein Supervisor pro Container

Jeder Container erhält einen eigenen Conmon-Prozess. Conmon ist bewusst klein gehalten und übernimmt genau drei Funktionen:

Damit erfüllt Conmon denselben Zweck wie die Überwachungslogik klassischer Daemons – lediglich ohne die globale Abhängigkeit.

Mermaid-Darstellung:

Hängt ein Container, betrifft das nur dessen eigenen Conmon-Prozess, nicht das gesamte System.

11.4 OCI-Runtime: Ausführung nach offenem Standard

Podman nutzt Runtimes, die der OCI Runtime Specification folgen, typischerweise runc oder crun. Die Runtime ist für die eigentliche Ausführung des Containers verantwortlich:

Diese klare Trennung führt zu deterministischem Verhalten: Ein Container startet genau so, wie es die Runtime-Spezifikation beschreibt. Images und Runtimes bleiben unabhängig vom verwendeten Engine-Frontend konsistent.

11.5 Storage-Schicht: containers/storage als Fundament

Podman verwendet die Bibliothek containers/storage, um Images, Layer und Container-Dateisysteme zu verwalten. Charakteristisch:

Die Storage-Architektur folgt dem Prinzip der Isolation: unterschiedliche Workloads beeinflussen sich nicht gegenseitig, und jeder Nutzer verfügt über eigenständige, sauber trennbare Speicherbereiche.

11.6 Netzwerk-Subsystem: Netavark und Aardvark DNS

Podman nutzte ursprünglich CNI, wechselte jedoch zu einem speziell entwickelten Netzwerkstack:

Diese Komponenten sind auf daemonlose Engines zugeschnitten. Ihre zentralen Eigenschaften:

Das Netzwerkverhalten ist dadurch konsistenter und leichter nachvollziehbar als unter einem Plugin-basierten System.

11.7 Pods als logische Ausführungseinheiten

Podman unterstützt Pods gemäß OCI-Modell. Dabei teilen mehrere Container ausgewählte Namespaces:

Container im Pod kommunizieren über localhost, bleiben aber weiterhin eigenständige Prozesse. Start- und Stop-Vorgänge können gruppiert werden. Das Pod-Modell schafft eine leichte, hostlokale Gruppierung ohne Orchestrierung.

11.8 Die REST-API: Optional und nicht zentral

Podman kann bei Bedarf eine REST-API bereitstellen, die das Verhalten eines Daemons simuliert. Sie existiert ausschließlich zur Kompatibilität:

Wichtig:

Die Architektur bleibt auch mit aktiver API daemonlos.

11.9 Zusammenspiel der Komponenten

Die Podman-Architektur besteht aus lose gekoppelten Bausteinen:

Jede Komponente ist sichtbar, einzeln austauschbar und unabhängig diagnostizierbar. Dieser modulare Aufbau erhöht Nachvollziehbarkeit, erleichtert Debugging und reduziert die Komplexität einer zentralisierten Architektur.