Ein Pod ist keine Sammlung lose gekoppelter Container, sondern eine klar definierte Ausführungseinheit, deren interne Struktur durch die gemeinsame Nutzung bestimmter Namespaces und Infrastrukturprozesse festgelegt ist. Podman übernimmt dieses Konzept direkt aus Kubernetes – jedoch ohne Control Plane, Scheduler oder Daemon. Die Struktur eines Pods ist damit präzise, leichtgewichtig und vollständig lokal reproduzierbar.
Im Zentrum jedes Pods steht der Infrastrukturcontainer. Er ist das erste Element, das Podman erzeugt, wenn ein Pod erstellt wird. Dieser Container:
Der Infrastrukturcontainer führt keine Anwendung aus – sein einziger Zweck besteht darin, eine gemeinsame Umgebung bereitzustellen. Wenn er terminiert, endet der gesamte Pod. Der Pod ist damit keine bloße Sammlung, sondern eine Namespace-bezogene Einheit, deren Konsistenz vom Infrastrukturcontainer abhängt.
Ein schematischer Überblick:
Der Pfeil symbolisiert dabei nicht eine Prozessbeziehung, sondern die hierarchische Struktur der Namespace-Vererbung.
Ein zentrales Merkmal der Pod-Struktur ist der gemeinsame Netzwerknamespace. Alle Container innerhalb eines Pods:
localhostDas macht einen Pod zu einer Art „Multi-Prozess-Netzwerkhost“. Ein
Container läuft beispielsweise auf 127.0.0.1:5000, ein
anderer auf 127.0.0.1:9000, und beide können ohne DNS, ohne
Routing und ohne NAT miteinander sprechen.
Aus Architektursicht ist das einer der größten Vorteile: Dienste müssen nicht über Netzwerkmechanismen miteinander interagieren, sondern können über rein lokale Schnittstellen kommunizieren.
Pods können – optional – auch IPC- und PID-Namespaces teilen:
Container können:
Dieses Modell eignet sich für eng gekoppelte Dienste, z. B. Adapter, Sidecars, Telemetrieprozesse.
Wenn PID-Sharing aktiviert ist:
strace, htop,
ps podweit eingesetzt werdenDas entspricht einem Host-ähnlichen Verhalten innerhalb des Pods, bleibt aber isoliert vom tatsächlichen Host.
Ein Pod besitzt genau eine Netzwerkidentität. Daher werden Ports nicht pro Container veröffentlicht, sondern podweit:
podman pod create -p 8080:80 mypodDie Port-Forwarding-Regel wird an den Infrastrukturcontainer gebunden. Alle App-Container teilen sich dieselben offenen Ports. Die Struktur ist dann:
Ports innerhalb des Pods müssen eindeutig sein – zwei Container können nicht gleichzeitig denselben Port öffnen. Das entspricht der Logik eines Multi-Prozess-Betriebssystems.
Obwohl Pods gemeinsame Namespaces nutzen, bleiben Container-Dateisysteme isoliert. Jeder Container besitzt:
Nur explizite Volumes stellen gemeinsame Speicherbereiche her.
Bedeutet: Netzwerk ist geteilt, Dateien sind isoliert – es sei denn, man entscheidet sich für gemeinsame Mounts.
Die Struktur eines Pods beeinflusst den gesamten Lebenszyklus:
Die Struktur ist streng hierarchisch:
Der Pod ist nicht ein Set von Containern, sondern eine Kapselungsebene darüber.
Pods lassen sich in typische interne Rollen gliedern:
Der Hauptdienst, oft eine Applikation oder ein Serverprozess.
Ergänzende Dienste, etwa:
Kurzlebige Prozesse oder Tools, z. B.:
Diese Rollen beruhen auf der gemeinsamen Namespace-Basis. Sie erzeugen eine engine-interne Struktur, die an Kubernetes erinnert, aber völlig ohne Clusterlogik auskommt.
Ein Pod eignet sich immer dann, wenn eine Funktionseinheit aus mehreren Prozessen besteht, aber dennoch als ein Dienst betrachtet wird. Beispiele:
Die Struktur ist dabei immer hierarchisch klar:
Diese Klarheit sorgt für Reproduzierbarkeit und macht Pods zu einem Baustein, der deutlich näher an modernen Service-Architekturen liegt als Ein-Container-Konstrukte.