Container-Netzwerk und Container-Storage sind zwei Seiten derselben Infrastrukturmedaille. Sie definieren, wie isolierte Prozesse miteinander kommunizieren und wie ihre Daten persistieren. Podman folgt in beiden Bereichen einer klaren Architektur: Rootless-Betrieb, minimal privilegierte Komponenten und vollständig deklarierte Zustände. Für produktionsnahe Architekturen ergeben sich daraus präzise steuerbare, deterministische und auditierbare Mechanismen, die sowohl Entwicklungs- als auch Laufzeitumgebungen beeinflussen.
Podman baut Container-Netzwerke über CNI (Container Network Interface) oder – in neueren Versionen – über Netavark/Aardvark auf. Beide Systeme kapseln Netzwerklogik vollständig außerhalb eines Daemons. Die Konsequenz: keine zentralen Sockets, keine globalen Netzwerkprozesse, keine privilegierten Hintergrunddienste.
Podman unterstützte lange Zeit CNI. Mit Netavark wurde eine native, speziell für Podman entwickelte Engine eingeführt. Netavark ist kein Plugin-Ökosystem, sondern ein dediziertes Netzwerkbackend:
Netavark verwendet Aardvark für DNS-Management – ein eigenständiges User-Space-DNS-Backend, das containerlokale Namensauflösung bereitstellt.
Im Rootless-Modus sind Netzwerkoperationen per Definition eingeschränkt. Das hat konkrete Auswirkungen:
Podman emuliert daher NAT über slirp4netns – ein User-Space NAT-Layer, der Netzwerkisolation ohne Root-Rechte ermöglicht.
Ein schematisches Modell:
Der zusätzliche Userspace-Hop beeinflusst Performance, aber er hält Rootless-Netzwerke sicher und portabel.
Podman bietet dieselben Netzwerkkonzepte wie Docker – nur ohne Daemon:
In Rootless Setups ist Bridge der Standard. MACVLAN erfordert Rootrechte und ist daher nur in Root-Umgebungen sinnvoll.
Aardvark erzeugt pro Netzwerk eine DNS-Zone. Container erhalten dedizierte Namensräume, ähnlich wie in Kubernetes:
In Multi-Container-Architekturen ist dieser Mechanismus essenziell. Vor allem in Entwicklungsszenarien ermöglicht er den Verzicht auf komplexe Orchestrierung.
Podman nutzt containers/storage, eine Library, die Layer
verwaltet, Snapshots erzeugt und Dateisystem-CoW ermöglicht. Im
Gegensatz zu klassischen daemony Engines arbeitet dieser Storage nicht
global, sondern modular und benutzerbezogen.
Podman verwendet drei mögliche Storage-Treiber:
Die Wahl hängt unmittelbar vom Build- und Laufzeitkontext ab.
Ein schematischer Vergleich:
Im Rootless-Modus nutzt Podman
$HOME/.local/share/containers/storage. Das bedeutet:
In Multi-User-Systemen ist dies ein entscheidender Vorteil gegenüber Docker, das historische Probleme mit globalen Daemon-Caches hatte.
Container verfügen über zwei Speicherbereiche:
Diese writable Layer sind flüchtig. Persistenz erfordert Volumes.
Podman implementiert Volumes ähnlich zu Docker, aber mit dem Fokus auf Benutzerisolation. Ein Volume:
Mit Rootless-Podman liegen Volumes standardmäßig im Userspace. Für produktionsnahe Szenarien bedeutet das:
In Root-Setups können Volumes klassische Kernel-Mounts sein und damit etwa NFS, CephFS oder GlusterFS nutzen.
Jede Änderung im Container erzeugt CoW-Operationen. Intensive Schreibprozesse (Datenbanken, Buildprozesse, Analytics) führen schnell zu großen Container-spezifischen Layers, besonders in rootless Setups.
Die Lösung:
slirp4netns erzeugt einen spürbaren Overhead:
Für Entwicklungszwecke ist das akzeptabel, aber produktionsnahe Benchmarks sollten im Root-Modus laufen.
Speicherlecks treten fast immer durch unbenutzte Layer auf. Podman
bietet podman system prune, podman image prune
und podman volume prune, die mit containers/storage direkt
zusammenarbeiten.
Eine hochgradig effiziente Praxis:
Networking und Storage sind nicht separierbar: ein containerisiertes System muss beides kontrolliert einstellen können.
Ein typisches Drei-Komponenten-Szenario:
Diese Modellierung zeigt:
Solche Modelle sind mit Podman ohne Daemon und ohne komplexe Orchestrierungswerkzeuge möglich.
Sowohl Netzwerk als auch Storage sind Angriffsflächen:
Podman minimiert diese Risiken durch: