Pods sind in Podman kein Zusatzfeature, sondern ein Kernkonzept – ein strukturelles Element, das direkt aus dem Kubernetes-Modell übernommen wurde. Während Docker traditionell ausschließlich Container verwaltet, erlaubt Podman, mehrere Container als kooperierende Einheit zu betreiben. Ein Pod ist dabei eine Prozess-, Netzwerk- und Port-Isolationseinheit, in der mehrere Container gemeinsame Infrastruktur teilen, aber unterschiedliche Aufgaben erfüllen. Dieses Modell eignet sich hervorragend für Architekturen, in denen Dienste eng gekoppelt sind, aber dennoch voneinander getrennte Laufzeitumgebungen benötigen.
Ein Pod ist eine gemeinsame Ausführungsumgebung. Technisch bedeutet das:
Container in einem Pod kommunizieren, als befänden sie sich in einem gemeinsamen Prozessraum. Das ist kein Convenience-Feature, sondern ein bewusstes Architekturpattern.
Diese Architektur erlaubt es, mehrere Container zusammenzufassen, ohne ihre Prozesse miteinander zu vermischen.
Pods adressieren eine Reihe realer Probleme:
Der Pod ist damit ein logisches Äquivalent eines „Multi-Prozess-Services“.
Podman implementiert Pods über einen Infrastrukturcontainer. Das ist ein kleiner Hilfscontainer, der:
Er selbst tut nichts – aber er hält das Pod-Ökosystem stabil. Wird er beendet, endet der gesamte Pod.
Ein häufiges Missverständnis ist die Annahme, ein Pod sei ein virtueller Host. Tatsächlich ist der Infrastrukturcontainer das, was dem am nächsten kommt.
Container innerhalb eines Pods teilen sich ein Netzwerkinterface. Das bedeutet:
localhost ist für alle Pod-Container derselbe HostBeispiel:
Die Kommunikation ist extrem schnell, da sie reine Namespace-Kommunikation ist.
Pods eignen sich besonders für Sidecar Patterns – Architekturen, bei denen ein Hauptprozess von ergänzenden Prozessen unterstützt wird:
Da alle Container denselben Netzwerkstack nutzen, entfällt das übliche Cross-Container-Netzwerkgerangel.
Beispiel-Pod:
podman pod create --name webapp -p 8080:80
podman run --pod webapp --name nginx nginx
podman run --pod webapp --name app myappNginx erreicht die App über localhost. Kein Routing,
kein DNS, kein Portmapping nötig.
Pods können optional auch PID-Namespaces teilen:
podman top zeigt alle Pod-ProzesseIn produktionsnahen Architekturen ist das ein Muster, das sich bewährt hat – man erhält Transparenz, ohne einen zentralen Supervisor zu benötigen.
Pods teilen sich das Netzwerk – nicht jedoch automatisch Speicher. Jeder Pod-Container besitzt weiter seine eigenen Layers. Für gemeinsame Daten müssen Volumes genutzt werden:
podman run --pod webapp -v config:/etc/config app
podman run --pod webapp -v config:/etc/config sidecarDiese Trennung verhindert unbeabsichtigte Datenkorruption zwischen Containern.
Podman synchronisiert Container innerhalb eines Pods:
Dies macht Pods ideal für integrierte Dienste.
Der Infrastrukturcontainer bestimmt den Lebenszyklus. Schlägt er fehl, endet der gesamte Pod. Das ist ein bewusstes Design: der Pod ist eine atomare Ausführungseinheit.
Rootless-Pods funktionieren fast identisch wie Root-Pods – mit Einschränkungen:
Für Entwicklungsumgebungen oder Multi-User-Systeme sind Pods unter Rootless jedoch ein erheblicher Vorteil:
Da alle Container denselben Netzwerknamespace nutzen, können sie nicht denselben Port gleichzeitig öffnen.
Lösung: Ports koordinieren, Sidecars nutzen.
Wenn der Pod „verschwunden“ ist, liegt es meistens am Infrastrukturcontainer:
podman ps -a | grep infraReparatur: Pod neu starten oder Infrastrukturcontainer neu erzeugen.
Ursache: Container nicht mit --pod gestartet. Pods sind
kein nachträgliches Netzwerk-Feature – die Container starten im
Pod, nicht danach.
Volume-Collisions entstehen, wenn mehrere Container innerhalb eines Pods nicht abgestimmte Pfade erwarten.
Das Pod-Konzept in Podman ist eine verkleinerte, lokal nutzbare Form des Kubernetes-Pods:
Damit bildet Podman eine Art „Kubernetes light“, das ohne Cluster, ohne Control Plane, aber mit denselben Plattformmustern arbeitet. Genau das macht Pods zu einem idealen Werkzeug für Architekten und Entwickler, die lokal oder in CI mit echten Kubernetes-Mustern arbeiten wollen – ohne Kubernetes.