Benutzerdefinierte Netzwerke gehören zu den mächtigsten, aber oft unterschätzten Werkzeugen im Podman-Ökosystem. Sie ermöglichen es, Container in logisch getrennten Kommunikationsdomänen zu gruppieren, Dienstabhängigkeiten gezielt zu modellieren und die Architektur eines Systems auf Netzwerkebene abzubilden. Während Docker lange auf ein Plugin-orientiertes CNI-System setzte, verfolgt Podman mit Netavark und Aardvark einen deterministischen und rootless-freundlichen Ansatz. Dadurch entsteht ein Netzwerkmodell, das sich sowohl für lokale Entwicklungsumgebungen als auch für komplexe Anwendungsstacks eignet – und das ohne einen zentralen Daemon.
Ein benutzerdefiniertes Netzwerk ist nicht nur ein technisches Artefakt, sondern ein eigenes Architekturobjekt. Es strukturiert:
In modernen Microservice-Systemen ersetzt ein durchdachtes Netzdesign häufig überflüssige Firewall-, Proxy- oder Routingregeln. Es schafft Klarheit, indem es Kommunikationspfade explizit und nachvollziehbar macht.
Podman verwaltet benutzerdefinierte Netzwerke über Netavark – ein dediziertes Netzwerkbackend, das Routing, NAT, IPAM und Interface-Erzeugung abbildet. Im Gegensatz zu CNI-Plugins existiert kein chaotischer Plugin-Zoo, sondern ein einheitliches Modell:
Aardvark ergänzt dies durch einen containerlokalen DNS-Server pro Netzwerk.
Ergebnis: jedes Netzwerk bildet eine abgeschlossene Zone mit eigener Namensauflösung.
Ein benutzerdefiniertes Netzwerk verhält sich wie ein virtuelles L2-/L3-Segment. Container erhalten:
Illustriert:
Container aus verschiedenen Netzwerken können sich standardmäßig nicht sehen – weder auf IP- noch auf DNS-Ebene.
Diese Isolation ist kein Bonusfeature, sondern der zentrale Zweck benutzerdefinierter Netzwerke.
Ein Container kann Mitglied in mehreren Netzwerken sein und erhält dann:
Diese Fähigkeit entspricht in der Praxis dem „Multi-Homing“ und eröffnet architektonische Muster wie Service-Mesh-ähnliche Segmentierung ohne Orchestrator.
Beispiel:
Backend fungiert hier als Gateway zwischen Frontend und Datenbank – jedoch ausschließlich auf Anwendungsebene, da kein L3-Routing zwischen Netzwerken existiert. Ein solcher Aufbau erzwingt klare Grenzen: kein Container sieht mehr als notwendig.
Bei der Erstellung eines Netzwerks können IP-Pools und Subnetze explizit angegeben werden:
podman network create \
--subnet 10.42.0.0/24 \
--gateway 10.42.0.1 \
mynetDiese Kontrolle ist essenziell, wenn Container:
Netzwerke werden so zu konfigurierbaren Bausteinen, die nicht zufällig entstehen, sondern bewusst modelliert werden.
Aardvark erzeugt pro Netzwerk eine DNS-Zone. Bedeutet:
Beispiel: Ein Container web im Netzwerk
mynet ist dort über web.mynet und
web erreichbar. In einem zweiten Netzwerk würde er als
web.othernet adressierbar sein.
Diese DNS-Trennung vermeidet klassische Fehler wie:
Benutzerdefinierte Netzwerke grenzen Container voneinander ab. Die Verbindung nach außen erfolgt über NAT:
Ein Container in einem benutzerdefinierten Netzwerk ist niemals automatisch von außen erreichbar. Diese Trennung schützt:
Nur definierte Ports am Host werden explizit freigegeben:
podman run -p 8080:80 --network mynet webappDiese bewusste Freigabe verhindert „zufällige Erreichbarkeit“.
Netzwerkprobleme in Containerlandschaften wirken zunächst unberechenbar. In benutzerdefinierten Netzwerken lässt sich die Fehleranalyse jedoch systematisch angehen.
podman network inspect mynetZeigt:
podman inspect -f '{{.NetworkSettings}}' webpodman exec web getent hosts backendpodman exec web ip routepodman network connect mynet container
podman network disconnect othernet containerViele Fehler entstehen schlicht durch falsche Netzzuordnungen.
Benutzerdefinierte Netzwerke ermöglichen Architekturen, die ohne Orchestrator erstaunlich sauber sind.
Frontend <-> Backend
Backend <-> DatabaseFrontend sieht Datenbank nicht. Backend wird zum Boundary-Service.
Jeder CI-Job erhält ein eigenes Netzwerk:
Mehrere Testmandanten laufen parallel:
Jeder Container kann mehrfach existieren, ohne sich gegenseitig zu sehen.
Zugriff erfolgt nur über explizite Service-Gateways.
Im Rootless-Modus gelten Einschränkungen:
Trotzdem bleiben die meisten Funktionen benutzerdefinierter Netzwerke erhalten – insbesondere DNS, Isolation, Multi-Network-Konfiguration und IPAM.
Für Enterprise-Umgebungen ist dies ein entscheidender Vorteil: Multi-User-Systeme können sicher Container nutzen, ohne die Gefahr globaler Interferenzen.