Container-Netzwerke sind isolierte Kommunikationsdomänen, in denen Prozesse sicher, deterministisch und reproduzierbar miteinander interagieren. Podman implementiert Container-Netzwerke vollständig ohne Daemon, unabhängig vom Host-Netzwerksystem und ohne privilegierte Hintergrunddienste. Dadurch entstehen Netzwerkmodelle, die sich strukturell von Docker unterscheiden und näher an Kubernetes-artigen Mechanismen liegen. Die Wahl des Netzwerkmodells beeinflusst Latenz, Erreichbarkeit, Isolation, Routing und damit die gesamte Architektur eines containerisierten Systems.
Jeder Container läuft in einem eigenen Netzwerknamespace. Das ist kein Podman-spezifischer Mechanismus, sondern ein Linux-Feature. Jeder Namespace besitzt:
Alle Netzwerkmodelle bauen auf diesem Grundprinzip auf, indem sie festlegen, wie dieser Namespace an andere Namespaces oder den Host gebunden wird.
Dies erklärt auch, warum Container-Netzwerklogik grundsätzlich isoliert ist – ein Container „sieht“ das Host-Netzwerk nicht, solange man es nicht explizit verbindet.
Podman hat sich von der CNI-Welt gelöst und mit Netavark + Aardvark einen Netzwerkstack geschaffen, der rootless funktioniert, deterministisch ist und die DNS-Logik bewusst aus dem Kernel in den Userspace verlagert.
Dadurch entfällt die Komplexität großer Plugin-Systeme. Podman steuert Netzwerke konsistent, schnell und reproduzierbar – ohne Daemon, ohne iptables-Hacks und ohne unkontrolliertes Plugin-Verhalten.
Das klassische Container-Netzwerk ist ein Bridge-Netzwerk – ein virtuelles Layer-2-Segment, das mehrere Container miteinander verbindet und optional NAT zum Host bereitstellt.
Eigenschaften des Bridge-Netzes:
Für die meisten Entwicklungs- und Integrationsumgebungen ist das Bridge-Modell ideal: klar isoliert, einfach konfigurierbar, vorhersehbar.
Wenn Podman rootless läuft, kann kein Kernel-NAT oder Bridge-Interface erzeugt werden. Stattdessen wird ein Userspace-NAT genutzt: slirp4netns.
slirp4netns ist nicht so performant wie NAT im Kernel, aber es ermöglicht ein komplettes Netzwerkmodell ohne Rootrechte:
Für Laptops, Dev-Workspaces oder CI ohne Privilegien ist slirp unverzichtbar und erstaunlich robust.
Das Host-Netzwerkmodell entfernt den Netzwerknamespace vollständig. Der Container wird direkt im Host-Namespace ausgeführt:
Dieses Modell ist riskant, aber performant. Es eignet sich für:
Im Rootless-Modus ist host networking nur begrenzt möglich, da Podman ohne Root keinen Zugriff auf den Host-Netzwerknamespace erhält.
MACVLAN erlaubt es Containern, eigene MAC-Adressen zu erhalten und sich wie physische Geräte im Netzwerk zu verhalten. Das Modell:
Eigenschaften:
Einsatzgebiet: appliance-artige Container, die im LAN real existieren sollen (z. B. Monitoring-Agenten, DHCP-Server, Reverse-Proxies).
MACVLAN erfordert Rootrechte und ist daher kein Rootless-Konzept.
Ein Container kann vollständig netzlos betrieben werden:
podman run --network noneDer Container hat dann keinerlei Netzwerkgeräte außer
lo. Das ist für sicherheitssensitive Prozesse oder
Sandboxing-Szenarien ideal.
Anwendungsfälle:
Dieses Modell parodiert gewissermaßen die Idee des „Offline-Rechners“.
Benutzerdefinierte Netzwerke erlauben die Kindereigenschaft aus Kubernetes: Gruppierung.
Beispiel:
Dieses Modell erzwingt Architekturdisziplin.
Aardvark trennt DNS pro Netzwerksegment. Das bedeutet:
Das Modell ist Kubernetes-ähnlich und lässt sich hervorragend für Microservice-Architekturen nutzen.
Netzwerkfehler gehören zu den kompliziertesten Problemen in Container-Umgebungen, aber sie lassen sich systematisch strukturieren:
Namespace prüfen
podman inspect <container> | jq .NetworkSettingsDNS testen
podman exec <container> getent hosts serviceRouting prüfen
podman exec <container> ip routeNAT testen
podman exec <container> curl -v http://example.comNetzwerk-Backend prüfen
podman info | grep networkViele vermeintliche Containerfehler sind tatsächlich Host-DNS- oder Routingfehler.
Workarounds:
Rootless ist sicher, aber nicht grenzenlos.