59 Grenzen und typische Stolperstellen

Podman ist mächtig, flexibel und extrem nah an den grundlegenden Linux-Mechanismen gebaut. Gerade diese Nähe macht es jedoch anspruchsvoller als klassische Container-Stacks, die vieles hinter einem monolithischen Daemon verbergen. Wer produktionsnahe Multi-Container-Anwendungen ohne Orchestrator betreibt, trifft früher oder später auf Stellen, an denen das Podman-Modell bewusst Grenzen setzt — oder an denen typische Missverständnisse zu unerwartetem Verhalten führen. Diese Stolperstellen sind nicht zufällig, sondern Ausdruck eines Designs, das Sicherheit, Transparenz und Daemonlosigkeit priorisiert.

59.1 Rootless ist sicher, aber nicht identisch zu Root

Rootless-Container sind eine der größten Stärken von Podman. Sie ermöglichen Entwicklung und Betrieb ohne Root-Rechte. Gleichzeitig bringt rootless Betrieb Einschränkungen mit sich, die auf Kernel-Design und User Namespaces zurückgehen:

59.1.1 Ports unter 1024 sind tabu

Ein rootless Container kann nicht auf privilegierte Ports binden:

-p 80:80   # rootless: nicht möglich

Typische Symptome:

Workaround: Portmapping auf höhere Ports oder systemd-Socket-Aktivierung.

59.1.2 Netzwerkperformance ist geringer

slirp4netns bietet funktionale, aber nicht performante NAT-Funktionalität. Grenzen:

Für interne Tests irrelevant, für produktionsnahe Edge-Anwendungen mit hohem Traffic aber entscheidend.

59.1.3 UID/GID-Mapping kann verwirrend sein

Host-UID 100000 entspricht in Containern root. Ein klassischer Grund für:

Rootless erfordert bewusstes Arbeiten mit Ownership-Konzepten, insbesondere bei bind mounts.

59.2 Pods lösen Probleme — und erzeugen neue

Pods sind keine Containergruppen, sondern shared-namespaces-Konstrukte. Daraus ergeben sich Stolperstellen:

59.2.1 Port-Konflikte im Pod

Da alle Container denselben Netzwerknamespace nutzen, gilt:

Viele Entwickler gehen fälschlich von docker-compose-Semantik aus, bei der Ports pro Container getrennt sind.

59.2.2 Infrastrukturcontainer ist Single Point of Failure

Wenn der Infrastrukturcontainer endet, endet der Pod.

Ursachen:

Wizardry: Manchmal glauben Anwender, der Pod sei „verschwunden“, obwohl nur der Infra-Container gestorben ist.

59.2.3 PID-Sharing erzeugt Transparenz, aber auch Angriffsfläche

Bei geteiltem PID-Namespace:

PID-Sharing ist mächtig, aber nicht für jeden Anwendungsfall geeignet.

59.3 Storage-Fallen: Volumes sind kein Allheilmittel

Podman nutzt container/storage und overlayfs — ein sehr flexibles, aber anspruchsvolles System. Typische Stolperfallen:

59.3.1 Overlayfs + fuse-overlayfs im Rootless-Betrieb

Grenzen:

Für Datenbanken im rootless Betrieb ist das nicht ideal.

59.3.2 Verwaiste Volumes

Durch das Fehlen eines zentralen Daemons kann es vorkommen, dass:

Podman löscht nie automatisch persistente Daten — das ist positiv, aber erfordert Wartung.

59.3.3 Rechteprobleme mit Bind Mounts

Mischt man rootless Container mit Host-Dateien, entstehen oft unklare Rechteverhältnisse. Ein Paradebeispiel:

„Warum kann der Container nicht schreiben?“ gehört zu den häufigsten Supportanfragen.

59.4 Networking-Komplexität: Netavark und slirp4netns verstehen

59.4.1 Unklare Erwartungen aus Docker-Welt

Docker-Nutzer erwarten:

Podman unterscheidet anders:

Oft führen nicht verwendete Konzepte (z. B. --network=host rootless) zu Verwirrung.

59.4.2 Firewall-Interferenzen

Podman schreibt Regeln über Netfilter/nftables. Typische Fehler:

Wer an der Firewall schraubt, sollte verstehen, dass Podman die Regeln selbst managed.

59.5 Compose-Stolpersteine: Kompatibel, aber anders

Podman Compose ist formatkompatibel, aber nicht verhaltensidentisch zu docker-compose.

Typische Stolperfallen:

59.5.1 depends_on garantiert nicht die Startreihenfolge

Docker Compose v2 wertet depends_on.condition und Healthchecks aus. Podman Compose nicht. Anwendungen, die DB-Startzeiten voraussetzen, können ohne „Wait-for-it“-Skripte fehlschlagen.

59.5.2 Ports werden am Pod, nicht am Container exponiert

Entwickler wundern sich, warum zwei Services nicht beide denselben externen Port nutzen dürfen — die Erklärung lautet: ein Pod, ein Netzwerknamespace.

59.5.3 Logging-Optionen variieren

Docker-spezifische Logtreiber sind nicht unterstützt. Wer Logstash/Fluentd-Treiber nutzt, erlebt Überraschungen.

59.6 Limitierungen im Vergleich zu Orchestratoren

Ohne Orchestrator fehlen:

Viele Entwickler überschätzen bewusst das, was Podman leisten soll — und unterschätzen das, was Podman eigentlich lösen will.

59.7 Der Mensch als Stolperstelle: mentale Modelle der Nutzer

Die häufigste Ursache für Stolperfallen ist ein ungeklärtes mentales Modell: Viele denken noch in Docker-Kategorien („ein Container = ein Service“) oder in Kubernetes-Kategorien („der Pod wird schon von allein wieder starten“).

Podman verlangt dagegen:

Das ist kein Nachteil, sondern Transparenz — aber eine Transparenz, die man verstehen muss.