A Podman pod can share its network and PID namespaces, making it behave like a traditional Linux container orchestration system’s pod.
Let’s see this in action. We’ll create a pod with two containers: an Nginx web server and a simple busybox container that will act as a client.
First, create the pod, specifying that it should share the network and PID namespaces:
podman pod create --name my-shared-pod --share net --share pid
Now, create and run the Nginx container within this pod. We’ll expose port 80 from the container to the host.
podman run -d --pod my-shared-pod --name nginx-server -p 8080:80 docker.io/library/nginx
Next, create and run the busybox container within the same pod. This container won’t have any exposed ports as it will communicate with Nginx over the shared network namespace.
podman run -d --pod my-shared-pod --name busybox-client docker.io/library/busybox sh -c "while true; do wget -O - http://localhost:80/ || echo 'failed'; sleep 5; done"
Now, let’s inspect what’s happening. You can see both containers are part of the my-shared-pod:
podman pod ps my-shared-pod
Output will show both containers running within the pod.
The magic of the shared network namespace means nginx-server is listening on port 80 inside the pod’s network stack. The -p 8080:80 flag on the nginx-server container maps the pod’s internal port 80 to port 8080 on your host machine.
The busybox-client container, also within the same pod, can reach Nginx simply by using localhost:80. It doesn’t need to know about the host’s IP or any port mappings.
Let’s verify this. From your host machine, you can access Nginx via port 8080:
curl http://localhost:8080
And from inside the busybox-client container, you can also access Nginx using localhost:80:
podman exec busybox-client wget -O - http://localhost:80
This demonstrates that both containers are effectively on the same network interface, seeing localhost as each other.
The shared PID namespace means processes within containers in the pod can see each other’s PIDs. For example, you can see the Nginx master process (PID 1 in its container) and its worker processes from within the busybox container.
podman exec busybox-client ps aux
You’ll see processes from both Nginx and busybox, with PIDs that are unique within the pod’s shared PID namespace but might not be unique on the host. This allows for inter-process communication and debugging scenarios where processes need to signal or monitor each other directly.
When you create a pod with --share net, Podman sets up a network namespace for the pod. All containers created with --pod <pod_name> are then attached to this same network namespace. This means they share the same IP address, network interfaces, routing tables, and firewall rules. For ports, any port exposed by a container is exposed from the perspective of this shared pod network namespace. The host port mapping then translates traffic from the host to the pod’s network namespace.
With --share pid, Podman creates a shared PID namespace for the pod. All processes within containers in this pod will share a single process tree. The PID 1 for the entire pod will be the first process started in any container. Subsequent processes will have PIDs that are unique within this shared namespace. This is crucial for applications designed to run as a group, where one process might need to signal or monitor another, or where a supervisor process needs to manage children across container boundaries.
The primary benefit is resource efficiency and simplified communication. Instead of complex inter-container networking configurations (like linking or custom networks), containers within a pod can communicate as if they were on the same machine, using localhost and standard IPC mechanisms. This mirrors the behavior of Kubernetes pods, making migration and development smoother.
A subtle point often missed is how signal handling works with shared PID namespaces. While processes can see each other, signals sent to a PID might be delivered to the specific process within its container or to the process group leader, depending on the signal and how it’s handled. Not all signals are automatically propagated or handled identically across container boundaries even within a shared PID namespace.
The next logical step is exploring how to manage complex multi-container applications within these shared namespaces, perhaps involving service discovery or more advanced inter-process communication patterns.