Das Ressourcen- und Namespace-Sharing ist eines der konzeptionell anspruchsvollsten, aber fundamentalsten Prinzipien des Pod-Modells. Container sind isolierte Prozesse, die jeweils in eigenen Namespaces laufen. Ein Pod hingegen ist eine kontrolliert geteilte Ausführungsumgebung, in der mehrere Container Teile dieser Isolationsmechanismen gemeinsam nutzen. Dieses Modell ist weder ein vollständiges „Zusammenlegen“ der Ressourcen noch eine triviale Gruppierung — es ist eine fein abgestimmte, selektive Aufhebung von Isolation, die bestimmte Gemeinsamkeiten erlaubt, ohne die Gesamttrennung zum Host aufzugeben.
Der wichtigste Gedanke hinter dem Pod-Modell lautet: Container sollen sich bestimmte Ressourcen teilen können, ohne dass sie ihr Dateisystem oder ihren Code teilen müssen.
Das bedeutet konkret:
Dies schafft ein Architekturmodell, das an einen gemeinsamen „Mini-Host“ erinnert — aber ohne die Risiken ungefilterter Prozessvermischung.
Der primäre geteilte Namespace in einem Pod ist der Netzwerknamespace. Alle Container nutzen:
Der Infrastruktur-Container erzeugt und hält diesen Namespace. Jeder weitere Container betritt ihn beim Start.
Diagramm:
Innerhalb des Pods kommunizieren Container daher nicht über DNS oder Bridges, sondern über reine localhost-Kommunikation.
Das Netzwerk-Sharing ist die Basis aller Pod-Funktionalität.
Der IPC-Namespace (Shared Memory, Semaphores, Message Queues) wird ebenfalls standardmäßig geteilt. Container können dadurch:
Beispiel: ein HPC-ähnliches Szenario innerhalb eines Pods:
Das Sharing erfolgt ohne Dateisystem, ohne Netzwerk, ohne Copying — exakt wie zwei Prozesse auf demselben Linux-Host.
Podman erlaubt (analog zu Kubernetes) das Teilen des PID-Namespaces. Es ist optional, aber in einigen Szenarien hochgradig nützlich.
Wenn PID-Sharing aktiv ist:
ps zeigt podweite Prozesslistenstrace,
gdb, ltrace auf andere Container anwendenBeispiel:
Dieses Modell eignet sich besonders für:
Die Sicherheit bleibt trotzdem gewährleistet, da Dateisysteme isoliert bleiben.
Ebenfalls optional ist das Sharing des UTS-Namespaces. Wenn aktiviert, teilen die Container:
Das wirkt trivial, ist aber architekturstrategisch nützlich:
Für klassische Workloads wirkt das unscheinbar, aber es verbessert die Kohärenz podinterner Metadaten erheblich.
Im Gegensatz zu Namespaces teilen Pods nicht automatisch dieselben Cgroups – aber sie können es.
Podman ermöglicht:
Ein Pod kann also als „Budgetrahmen“ fungieren:
podman pod create \
--cpus=4 \
--memory=6g \
mypodAlle Container im Pod teilen sich dann dieses Budget. Ein Container kann durch seine Cgroup nicht mehr Ressourcen beanspruchen, als dem Pod insgesamt zugewiesen wurden.
Das ist nützlich für:
Wichtig: Mit Cgroups können Pods gezielt stabilisiert werden, insbesondere gegen runaway-Prozesse einzelner Container.
Ein Pod kann jederzeit temporär einen Debug-Container aufnehmen:
podman run --pod mypod --rm -it alpine shDieser Container hat sofort Zugriff auf:
Dies ersetzt klassische SSH-inside-container Praktiken.
Namespace-Sharing ist mächtig — aber es entfaltet seinen Wert nur, wenn der Pod als funktionale Einheit betrachtet wird, nicht als Container-Sammelbecken.
Ein Pod ist eine Komposition von Containern, die sich ein Laufzeitumfeld teilen — nicht ihren Code, nicht ihre Daten, nicht ihren Speicher, sondern ihre Sicht auf die Welt.
Ressourcen- und Namespace-Sharing ist das, was einen Pod strukturiert: eine kontrollierte gemeinsame Realität für mehrere isolierte Prozesse.