Der Infrastruktur-Container ist das unscheinbarste, aber entscheidendste Element eines Pods. Er führt selbst keinen Anwendungscode aus, bietet keine APIs an und erzeugt keine Logs. Dennoch hängt die Stabilität eines gesamten Pods von ihm ab. Er ist der Träger der Namespaces, der Haltepunkt für das Netzwerk, das logische Fundament, auf dem alle weiteren Container aufbauen. Technisch ist er die kleinste denkbare Ausführungsumgebung, konzeptionell eine Art „steady-state Prozess“, der die Lebensdauer des Pods definiert.
Ein Pod fasst mehrere Container zu einer gemeinsamen Ausführungseinheit zusammen. Damit diese Container miteinander kommunizieren können, benötigen sie gemeinsame Namespaces – insbesondere Netzwerk, IPC und optional PID. Da Namespaces an existierende Prozesse gebunden sind, benötigt der Pod genau einen solchen Prozess, der diese Namespaces erzeugt und hält: den Infrastruktur-Container.
Er dient als:
Er ist damit gleichzeitig Startpunkt und Stabilitätsgarant.
Der Infrastruktur-Container ist extrem schlank. Sein File-System, Prozessliste und Speicherverbrauch bewegen sich nahe des absoluten Minimums. Podman verwendet standardmäßig ein minimalistisch gehaltenes „pause“-Abbild, das im Grunde einen einzigen Prozess startet, der nichts weiter tut als:
Ein schematischer Überblick:
Dieser Minimalismus ist kein zufälliges Detail, sondern ein Architekturprinzip: der Infrastruktur-Container ist so klein wie möglich, um so stabil wie möglich zu sein.
Während normale Container ihren eigenen Netzwerknamespace besitzen, teilen alle Container eines Pods den Netzwerknamespace des Infrastruktur-Containers. Dadurch ergibt sich eine klare Zuordnung:
localhost zeigt für alle Container auf denselben
NetzwerkraumBeispiel:
podman pod create -p 8080:80 mypod
podman run --pod mypod nginx
podman run --pod mypod appBaumstruktur:
Der Infrastruktur-Container ist damit das verbindende Element zwischen Host-Networking und interner Pod-Kommunikation.
Der Pod existiert, solange der Infrastruktur-Container existiert. Wird er gestoppt, pausiert oder gelöscht, gilt dasselbe für alle Container im Pod.
Podman integriert diese Semantik direkt in die Steuerung:
podman pod start startet Infrastruktur + Kinderpodman pod stop beendet alle Prozessepodman pod rm entfernt die gesamte EinheitEin abgestürzter Infrastruktur-Container führt unweigerlich zum Ende des Pods. Ein solcher Fall ist selten – und genau das ist der Punkt. Der Infrastruktur-Container ist bewusst extrem resistent gegen Fehlverhalten, genau weil er keine komplexe Funktionalität besitzt.
Weil sämtliche Pod-Container Prozesse des gleichen Prozessbaums sind, ist der Infrastruktur-Container auch:
Das bedeutet praktisch:
SIGTERM auf den Pod wird an alle Container
vererbtpodman top können den gesamten Prozessraum
abbildenDas Verhalten ähnelt dem eines Supervisors in klassischen Unix-Diensten – jedoch ohne Logik, ohne Politik, ohne eigene Restart-Strategien. Der Pod selbst ist das Steuerungsobjekt.
Der Infrastruktur-Container definiert die Grenze zwischen dem Pod und der Außenwelt. Er hält die gemeinsamen Namespaces, aber er verwaltet nicht das Dateisystem oder die Volumes der Container. Diese Isolation ist gewollt:
Ein Pod ist daher weder ein „Mini-VM“ noch ein „Shared Filesystem“, sondern eine kooperative Prozessgruppe mit gemeinsamer Netzwerkidentität.
Das hat Auswirkungen:
Der Infrastruktur-Container bildet die strukturelle Mitte dieser Architektur.
Im Rootless-Modus unterscheiden sich Netzwerk- und Storagepfade, aber die Logik des Infrastruktur-Containers bleibt gleich. Unterschiede:
Der Infrastruktur-Container abstrahiert diese Unterschiede – Container im Pod bemerken sie nicht.
Viele Anwender bemerken den Infrastruktur-Container nie – bis sie ihn plötzlich brauchen. Ein Blick:
podman ps --filter label=io.podman.infraOder:
podman inspect mypodDort findet man:
Er ist damit kein „hidden process“, sondern ein bewusst verwaltbares Element.
Missverständnisse entstehen besonders dann, wenn man erwartet, dass der Infrastruktur-Container Funktionen bereitstellt, die nicht zu seiner Aufgabenbeschreibung gehören. Er ist:
Er ist nur das Fundament. Alles Weitere übernehmen die Applikationscontainer selbst.